Topic : | Linux Kernel 64bit Personality Handling Local Denial of Service Vulnerability
|
SecurityAlert : 7025
CVE : CVE-2010-0307
CWE : CWE-Other
SecurityRisk : Medium (About)
Remote Exploit : No
Local Exploit : Yes
Victim interaction required : No
Exploit Available : No
Credit : Mathias Krause
Published : 19.02.2010
Affected Software : | linux:kernel:2.6.24.7
linux:kernel:2.6.25.15
intel:e1000:7.4.27
intel:e1000:7.4.35 and previous versions
intel:e1000:7.3.20
intel:e1000:7.3.15
intel:e1000:7.2.9
intel:e1000:7.2.7
intel:e1000:7.1.9
intel:e1000:7.0.41
intel:e1000:7.0.33
intel:e1000:6.3.9
intel:e1000:6.2.15
intel:e1000:6.1.16
intel:e1000:6.0.60
intel:e1000:6.0.54
intel:e1000:5.7.6
intel:e1000:5.6.10
intel:e1000:5.6.10.1
intel:e1000:5.5.4
intel:e1000:5.4.11
intel:e1000:5.3.19
intel:e1000:5.2.52
intel:e1000:5.2.30.1
intel:e1000:5.2.22 |
 Advisory Content : I found by accident an reliable way to panic the kernel on an x86_64
system. Since this one can be triggered by an unprivileged user I
CCed security@kernel.org. I also haven't found a corresponding bug on
bugzilla.kernel.org. So, what to do to trigger the bug:
1. Enable core dumps
2. Start an 32 bit program that tries to execve() an 64 bit program
3. The 64 bit program cannot be started by the kernel because it
can't find the interpreter, i.e. execve returns with an error
4. Generate a segmentation fault
5. panic
The problem seams to be located in fs/binfmt_elf.c:load_elf_binary().
It calls SET_PERSONALITY() prior checking that the ELF interpreter is
available. This in turn makes the previously 32 bit process a 64 bit
one which would be fine if execve() would succeed. But after the
SET_PERSONALITY() the open_exec() call fails (because it cannot find
the interpreter) and execve() almost instantly returns with an error.
If you now look at /proc/PID/maps you'll see, that it has the
vsyscall page mapped which shouldn't be. But the process is not dead
yet, it's still running. By now generating a segmentation fault and
in turn trying to generate a core dump the kernel just dies. I
haven't yet looked into this code but maybe you guys are much faster
than me and just can fix this problem :)
Test case for this bug is attached. It was tested on a 2.6.26.7 and
2.6.30.10, but I may affect even older kernels. So it may be
interesting for stable, too.
Greetings,
Mathias Krause
References :
https://bugzilla.redhat.com/show_bug.cgi?id=560547
http://www.securityfocus.com/bid/38027
http://www.openwall.com/lists/oss-security/2010/02/04/9
http://www.openwall.com/lists/oss-security/2010/02/04/1
http://www.openwall.com/lists/oss-security/2010/02/01/5
http://www.openwall.com/lists/oss-security/2010/02/01/1
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32.8
http://www.globalsecuritymag.com/Vigil-nce-Linux-kernel-denial-of,20100202,15754.html
http://marc.info/?t=126466700200002&r=1&w=2
http://marc.info/?l=linux-mm&m=126466407724382&w=2
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=221af7f87b97431e3ee21ce4b0e77d5411cf1549
Feedback :
If you have additional information or notice any errors regarding this security advisory, please use contact form or email us at info()securityreason()com.
|