Activity log for bug #414177

Date Who What changed Old value New value Message
2009-08-15 19:13:56 Xaweryz bug added bug
2009-08-15 19:15:46 Xaweryz description Copy from: http://blog.cr0.org/2009/08/linux-null-pointer-dereference-due-to.html EDIT1: this has been featured on Slashdot, OSNews, TheRegister, ZDNet and others EDIT2: Here is RedHat's official mitigation recommendation EDIT3: Brad Spengler also wrote an exploit for this and published it. http://grsecurity.net/%7Espender/wunderbar_emporium.tgz The bug triggering is based on our exploit which leaked to Brad though the private vendor-sec mailing list. He implements the personality trick Tavis and I published in June to bypass mmap_min_addr and also makes use of a feature that allows any unconfined user to gain the right to map at address zero in Redhat's default SELinux policy. Tavis Ormandy and myself have recently found and investigated a Linux kernel vulnerability. It affects all 2.4 and 2.6 kernels since 2001 on all architectures. We believe this is the public vulnerability affecting the greatest number of kernel versions. The issue lies in how Linux deals with unavailable operations for some protocols. sock_sendpage and others don't check for NULL pointers before dereferencing operations in the ops structure. Instead the kernel relies on correct initialization of those proto_ops structures with stubs (such as sock_no_sendpage) instead of NULL pointers. At first sight, the code in af_ipx.c looks correct and seems to initialize .sendpage properly. However, due to a bug in the SOCKOPS_WRAP macro, sock_sendpage will not be initialized. This code is very fragile and there are many other protocols where proto_ops are not correctly initialized at all (vulnerable even without the bug in SOCKOPS_WRAP), see bluetooth for instance. So it was decided that instead of patching all those protocols and continue to rely on this very fragile code, sock_sendpage would get patched to check against NULL. This was already the way sock_splice_read and others were handled. Since it leads to the kernel executing code at NULL, the vulnerability is as trivial as it can get to exploit: an attacker can just put code in the first page that will get executed with kernel privileges. Our exploit took a few minutes to adapt from a previous one: $ ./leeches // ------------------------------------------------------ // sendpage linux local ring0 // ---------------- taviso@sdf.lonestar.org, julien@cr0.org // leeches.c:Aug 11 2009 // GreetZ: LiquidK, lcamtuf, Spoonm, novocainated, asiraP, ScaryBeasts, spender, pipacs, stealth, jagger, redpig, Neel and all the other leeches we forgot to mention! Enjoy some photography while at ring0 @ http://flickr.com/meder For our webapp friends, here is an XSS executing at ring 0: javascript:alert(1); shellcode now executing chmod("/bin/sh", 04755), welcome to ring0 Killed $ sh # id uid=1000(julien) gid=1000(julien) euid=0(root) On x86/x86_64, this issue could be mitigated by three things: * the recent mmap_min_addr feature. Note that this feature has known issues until at least 2.6.30.2. See also this LWN article. * on IA32 with PaX/GrSecurity, the KERNEXEC feature (x86 only) * not implementing affected protocols (a.k.a., reducing your attack surface by disabling what you don't need): PF_APPLETALK, PF_IPX, PF_IRDA, PF_X25, PF_AX25, PF_BLUETOOTH, PF_IUCV, IPPROTO_SCTP/PF_INET6, PF_PPPOX, PF_ISDN, but there may be more. (Update: See RedHat's mitigation) This patch should be applied to fix this issue. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e694958388c50148389b0e9b9e9e8945cf0f1b98 You can read the advisory here. Copy from: http://blog.cr0.org/2009/08/linux-null-pointer-dereference-due-to.html EDIT1: this has been featured on Slashdot, OSNews, TheRegister, ZDNet and others EDIT2: Here is RedHat's official mitigation recommendation EDIT3: Brad Spengler also wrote an exploit for this and published it. http://grsecurity.net/%7Espender/wunderbar_emporium.tgz The bug triggering is based on our exploit which leaked to Brad though the private vendor-sec mailing list. He implements the personality trick Tavis and I published in June to bypass mmap_min_addr and also makes use of a feature that allows any unconfined user to gain the right to map at address zero in Redhat's default SELinux policy. Tavis Ormandy and myself have recently found and investigated a Linux kernel vulnerability. It affects all 2.4 and 2.6 kernels since 2001 on all architectures. We believe this is the public vulnerability affecting the greatest number of kernel versions. The issue lies in how Linux deals with unavailable operations for some protocols. sock_sendpage and others don't check for NULL pointers before dereferencing operations in the ops structure. Instead the kernel relies on correct initialization of those proto_ops structures with stubs (such as sock_no_sendpage) instead of NULL pointers. At first sight, the code in af_ipx.c looks correct and seems to initialize .sendpage properly. However, due to a bug in the SOCKOPS_WRAP macro, sock_sendpage will not be initialized. This code is very fragile and there are many other protocols where proto_ops are not correctly initialized at all (vulnerable even without the bug in SOCKOPS_WRAP), see bluetooth for instance. So it was decided that instead of patching all those protocols and continue to rely on this very fragile code, sock_sendpage would get patched to check against NULL. This was already the way sock_splice_read and others were handled. Since it leads to the kernel executing code at NULL, the vulnerability is as trivial as it can get to exploit: an attacker can just put code in the first page that will get executed with kernel privileges. Our exploit took a few minutes to adapt from a previous one: $ ./leeches // ------------------------------------------------------ // sendpage linux local ring0 // ---------------- taviso@sdf.lonestar.org, julien@cr0.org // leeches.c:Aug 11 2009 // GreetZ: LiquidK, lcamtuf, Spoonm, novocainated, asiraP, ScaryBeasts, spender, pipacs, stealth, jagger, redpig, Neel and all the other leeches we forgot to mention! Enjoy some photography while at ring0 @ http://flickr.com/meder For our webapp friends, here is an XSS executing at ring 0: javascript:alert(1); shellcode now executing chmod("/bin/sh", 04755), welcome to ring0 Killed $ sh # id uid=1000(julien) gid=1000(julien) euid=0(root) On x86/x86_64, this issue could be mitigated by three things: * the recent mmap_min_addr feature. Note that this feature has known issues until at least 2.6.30.2. See also this LWN article. * on IA32 with PaX/GrSecurity, the KERNEXEC feature (x86 only) * not implementing affected protocols (a.k.a., reducing your attack surface by disabling what you don't need): PF_APPLETALK, PF_IPX, PF_IRDA, PF_X25, PF_AX25, PF_BLUETOOTH, PF_IUCV, IPPROTO_SCTP/PF_INET6, PF_PPPOX, PF_ISDN, but there may be more. (Update: See RedHat's mitigation) This patch should be applied to fix this issue. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e694958388c50148389b0e9b9e9e8945cf0f1b98 You can read the advisory here. http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html
2009-08-15 19:18:50 Xaweryz cve linked 2009-2692
2009-08-15 20:36:08 Kees Cook visibility private public
2009-08-15 20:36:18 Kees Cook marked as duplicate 413656
2012-02-28 18:15:19 Kai Kasurinen removed subscriber Kai Kasurinen