They can't be exploited remotely and they don't affect Windows systems, but security experts say there are at least...
two good reasons for IT administrators to worry about flaws in version 2.6 of the Linux Kernel:
First, a vulnerability researcher has released exploit code that could be fashioned into potent attacks against Linux-based environments. Second, a malicious insider could use the flaws to expose sensitive company data.
Multiple security organizations have released advisories for the kernel flaw since the weekend, including the French Security Response Team (FrSIRT) and Danish vulnerability clearinghouse Secunia. FrSIRT advisory 2008-0487 describes the flaw as a moderate risk, while Secunia advisory SA28835 describes it as less critical and exploitable from local systems only.
According to Debian Security Advisory DSA-1494-1, the specific problem is that parameters within the "vmsplice_to_user()," "copy_from_user_mmap_sem()" and "get_iovec_page_array()" functions aren't properly verified before being used to perform certain memory operations. Local attackers could exploit this to read or write to arbitrary kernel memory via a specially crafted "vmsplice()" system call. From there, the attacker could gain root system privileges.
The Debian advisory noted that certain versions of Linux have been fixed. For the stable distribution, the problem is fixed in version 2.6.18.dfsg.1-18etch1. The unstable and testing distributions will be fixed soon, and the old stable distribution is not affected by the problem, Debian said. As for the Linux Kernel itself, the Linux Kernel Web site says the most stable version to date is 22.214.171.124.
Two researchers have been credited with finding the issues -- Wojciech Purczynskiof iSEC Security Research and a researcher using the online name Qaaz. The latter researcher has released exploit code for the kernel via the MilwOrm.com site. At the time of writing, neither researcher had responded to emailed requests for comment.
Mari Kirby Nichols, a handler for the Bethesda, Md.-based SANS Internet Storm Center, said the issues are potentially serious, despite low threat ratings given by the likes of Secunia.
"I believe Secunia has correctly identified this vulnerability as a local system vulnerability, but given that every server with a vulnerable kernel can be exploited to get elevated privilege, any unprivileged remote exploit can combine with it to form a remote root-level exploit," she said. "Additionally, a problem with not ranking it higher is that the servers that run this kernel may contain critical data."
She added that kernel-level access is the best there is, so it doesn't make sense to take this vulnerability lightly on mission critical or sensitive data systems.
Secunia typically reserves "less critical" status to flaws with a limited attack surface. But it is often applied to cross-site scripting and privilege escalation vulnerabilities, including flaws that allow the exposure of sensitive data to local users. Secunia Chief Technology Officer Thomas Kristensen said that under his company's rating system, purely local issues will never be rated anything more than "less critical."
"This is simply because either you need to be a trusted local user (if you aren't trusted, you shouldn't have physical access to a console) or you must have gained access in an illegitimate manner such as exploiting a vulnerability with a remote vector [to exploit something like this]," he said.
That said, he agreed there is always reason to be concerned about purely local issues, and that only the most security aware administrators will give proper priority to local issues.
"In our opinion it is important to ensure that local users can't gain escalated privileges," he said. "If a user successfully exploits local vulnerabilities and gains higher privileges then they are essentially in charge of the system and not the administrator."
Ferndale, Wash.-based security consultant Jim Reavis noted that locally-exploitable flaws can be as serious as remotely-exploitable flaws, especially if it's exploited by a user from within the affected company.
"I would definitely want to fix this, since it sounds like a normal user with shell access could exploit it," Reavis said. "At this point it is a good idea to make sure you audit who has shell access to your systems, even inside an organization it should only be a small number of sysadmins and developers."
Meanwhile, he said managing shell access rights will reduce the number of potential attackers. The good news, he said, is that this presents a smaller threat vector "than attacking a daemon across the net."