A new version of the 2.4 Linux kernel was released overnight that addresses a serious security hole that could...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
enable any user to escalate his privileges on a machine and run code.
The flaw lies in the memory management code in the mremap system call in versions up to and including 2.4.23. Mremap resizes and moves processes into virtual memory areas (VMAs). An incorrect bounds check could lead to a malicious VMA that could disrupt other areas of the kernel's memory management subroutines, according to an alert released by Polish research firm iSEC Security Research Inc.
"Since the 2.6 branch is much more complex than, let's say 2.4, it is imaginable that there are more exploitation paths in 2.6 than in 2.4," Starzetz said in an e-mail exchange. "We didn't study every detail about 2.2, 2.4 and 2.6 and concentrated onto 2.4."
Starzetz said he did come up with a working exploit on a 2.4.23 machine with a KDB patch, conditions that may have contributed to the exploit's success. He estimated that gaining root should take about an hour on a low-end Pentium 3 and maybe 10 to 15 minutes on a high-end Pentium 4 machine.
"Nevertheless, after some discussion, we have found a 'general-purpose' attack vector working for whatever the kernel may be, and we believe that there are numerous other ways to exploit the bug," he said.
Several distributors, including Red Hat Inc., SuSE Linux AG, Guardian Digital Inc. and Turbolinux Inc., released patches Monday afternoon. Starzetz said he was unaware of interim workarounds and urged administrators to patch their machines.
Starzetz said the flaw may be difficult to exploit, however. The problem with the bounds check in the do-mremap code that remaps a VMA could lead to a VMA of 0 bytes, he said.
"The [exploit] difficulty arises from the fact that, with the 0-sized VMA, we can only modify the behavior of other MM subroutines -- it is not an overflow or similar [problem] directly corrupting the flow of execution," Starzetz said. "And, as not mentioned in the advisory, 0-sized VMAs are not found by the main helper function find_vma. If they [were], we could very simply bypass VMA protections."
A second kernel vulnerability surfaced Monday as well in the real-time clock (rtc) routines. The flaw in the device driver could leak memory information.
FOR MORE INFORMATION: