(I hope you don’t mind me spamming your blog ;-) )

probe kernel.function(“mem_write@fs/proc/base.c”).return {
$return = -1
}

With this the exploit-program exits/fails. Without the return-probe, the forked su enters an infinite loop ( “Please write these 88 bytes” -> “I successfully wrote 0 bytes” -> “okay, then write these remaining 88 bytes” -> and so on….)

I found this, because I wanted to log these calls and added a “println” to the call-probe:

root@host:~# cat logit.stp
probe kernel.function(“mem_write@fs/proc/base.c”).call {
println(“write attempt: ” . sprint($count) . ” bytes (“. user_string_quoted($buf) . “) at offset ” . sprint(kernel_long($ppos)))
$count = 0
}

root@host:~# stap -g logit.stp
[.....]
write attempt: 88 bytes (“Unbekannte ID: H1\377\260i1705H1\377\260j1705H1\366@\26717@\26602\260!”…) at offset 4202665
write attempt: 88 bytes (“Unbekannte ID: H1\377\260i1705H1\377\260j1705H1\366@\26717@\26602\260!”…) at offset 4202665
write attempt: 88 bytes (“Unbekannte ID: H1\377\260i1705H1\377\260j1705H1\366@\26717@\26602\260!”…) at offset 4202665
write attempt: 88 bytes (“Unbekannte ID: H1\377\260i1705H1\377\260j1705H1\366@\26717@\26602\260!”…) at offset 4202665
WARNING: Number of errors: 1, skipped probes: 0
WARNING: There were 38056 transport failures.
Warning: /usr/bin/staprun exited with status: 1
Pass 5: run failed. Try again with another ‘–vp 00001′ option.

so my “final” version of the systemtap-script has rate-limiting on the print-line:

global last = 0;
probe kernel.function(“mem_write@fs/proc/base.c”).call {
now = jiffies()
if((now HZ() )) {
println(“write attempt: ” . sprint($count) . ” bytes (“. user_string_n_quoted($buf,$count) . “) at offset ” . sprint(kernel_long($ppos)))
last = now
}
$count = 0
}
probe kernel.function(“mem_write@fs/proc/base.c”).return {
$return = -1
}

result:
tim@host:~/src/CVE$ ./correct_proc_mem_reproducer
write: Operation not permitted
not vulnerable

this also shows ASLR at work (the offset differs from call to call):
write attempt: 8 bytes (“33\b@”) at offset 140737430350128
write attempt: 8 bytes (“33\b@”) at offset 140736850297152

What is gained by using this? After creating the module in step 1, the debuginfos are no longer necessary:
tim@host:~/src/CVE$ ./correct_proc_mem_reproducer
vulnerable
tim@host:~/src/CVE$ staprun -L cve_2012_0056

Disconnecting from systemtap module.
To reconnect, type “staprun -A cve_2012_0056″
tim@host:~/src/CVE$ ./correct_proc_mem_reproducer
not vulnerable
tim@host:~/src/CVE$ dpkg-query -W -f=’${Package}\t${Status}\n’ linux-image-$(uname -r)-dbg
linux-image-3.2.0-1-amd64-dbg unknown ok not-installed

(of course you would normally NOT run the script with your normal user account, this is for demonstration only…..)
If I understand systemtap right, you could also transfer the module to other hosts running the same kernel. So this module I created should work for all hosts running linux-image-3.2.0-1-amd64, version 3.2.1-1 (current unstable).

modified since on 32-bit architectures both the original and spender’s
reproducer had reported “not vulnerable” wrongly because of a bad cast
and incorrect return value checking… ;)

Mackenzie, you’re right to be generally suspicious of people on the internet, but I trust that Kees wouldn’t do something malicious here, in his blog, to Planet Ubuntu readers ;-) And I can confirm that his QR code is in no way “a sick joke”.

Dustin

good luck @Google :)

And thanks for all your work on Ubuntu Security. You were one of the reasons I decided to use Ubuntu as our Server OS for my old company.
Hopefully, you are still be active on the Ubuntu security, ’cause I admire your work and your knowledge.

Greetings from .de,

Stephan aka \sh