A second serious vulnerability in the Linux kernel's mremap system call was discovered Wednesday, and enterprises are urged to immediately update to new versions of the kernel or to apply patches from their distributors.

The flaw was discovered in the 2.4 version of the kernel, but new 2.4 and 2.6 kernels were released yesterday to mitigate the problem. Attackers exploiting this problem could gain root system privileges and cause a denial of service on a flawed system.

Why is this a recurring problem?

Researcher Paul Starzetz was asked why the Linux kernel provides for the possibility of this kind of privilege escalation so easily? What follows was his answer, provided in an e-mail exchange with SearchEnterpriseLinux.com this morning: "We think that there are various reasons. First the problem [with] Linux is that there are too many people 'hacking' the code. It has reached a complexity where the 'I-hack-quickly-some-code' approach doesn't work anymore. "Second it is its design. If there is a bug in the kernel it is probably very serious. There is no protection between processes as soon as they run in kernel mode. Linux has been developed to be very portable -- but that also means that it simply cannot use all architectural details of something like the Intel processor, which offers much more protection than

Linux actually uses."

"On a scale from zero to 10 where zero means no danger at all and 10 the most dangerous hole -- all in the case of a local attacker; that means a person with local shell access -- this hole can be scored as 10," said Paul Starzetz, a researcher with Polish security firm iSEC Security.

Starzetz also discovered a critical flaw in the same kernel function in January; this week's flaw is unrelated, according to Starzetz. He said the new flaw is a missing function return value check in the memory management code inside mremap; the value check is called "do_munmap."

"The first mremap bug was a 'boundary condition error' -- that means the mremap code failed to work well if certain unusual arguments were provided," Starzetz said. "The second hole [is based] on an unchecked function invocation -- that means the code tries to do something but doesn't check if the do_munmap subfunction did its job or not."

Red Hat Inc. and other vendors have issued patches for their distributions.

"Since no special privileges are required to use the mremap system call, any process may use its unexpected behavior to disrupt the kernel memory management subsystem," said an alert from iSEC.

Mremap resizes and moves processes into virtual memory areas (VMAs). When processes are moved to new locations, new VMA descriptors must be created, and page table entries must be copied by implementing the do_munmap kernel function. Do_munmap removes old memory mapping in the new process location and removes the old mapping in the previous location.

The flaw occurs in do_munmap because it does not test the return value of the function. If the maximum number of VMA descriptors has been exceeded, the function may fail. Do_munmap will then refuse to create a new VMA hole, the iSEC alert said.

Starzetz said his team was able to create a robust piece of proof-of-concept exploit code, which gives full super-user privileges on all vulnerable kernel versions. He added that his team would release that code next week.

"With the necessary knowledge, it isn't [difficult to exploit]. However, one must dig very deeply into the Linux memory management [to do so]," Starzetz said.

0 comments

E-Mail

Username / Password

Password

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy