51–60 of 100 posts
Earlier quoted context omitted.
> I'm counting myself as proficient in Linux for many years That's the difference between a power user and a hacker. A power user RTFM, a hacker RTFS.
The problem is you might be a Windows/Java/ASM/Lisp hacker, and you would be able to understand the general principles, but not the specific (and unfamiliar) source code.
Earlier quoted context omitted.
Try dmesg.
I checked dmesg. It's clear that something bad happened, but I didn't get root. I don't really know what I'm looking at, I just ran arbitrary code on my least valuable machine trying to learn something. Want me to pastebin it? edit: It starts out [318258.327110] BUG: unable to handle kernel paging request at 0000001781ef7788 [318258.328251] IP: [ ] atomic_dec_and_mutex_lock+0x15/0x90 [318258.328251] PGD 2b18b067 PUD…
Linux (redacted) 3.2.0-41-virtual #66-Ubuntu SMP Thu Apr 25 03:47:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[ 413.309308] BUG: unable to handle kernel paging request at 0000001781eef4e8
[ 413.310359] IP: [] atomic_dec_and_mutex_lock+0x15/0xa0
[ 413.311025] PGD 1c4ec067 PUD 0
[ 413.311680] Oops: 0000 [#6] SMP
[ 413.312007] CPU 0
Earlier quoted context omitted.
I mean, the fix consists in making sure that attr.config has all the 64 bits cleared - on the 64 bit machines, int is 64bit, so u64 == int, and all the bits are correctly handled. on 32 bit machines, int is 32bit, and the top 32 bit of attr.config is not cleared. I may be wrong though, as I didn't scan through all the affected code.
It's not that hard to port it to 32 bits, just hang on week or two. I'm just too lazy. IGjDf1e4eQxWyBFArYM8HgvCuns6p+GbfHoE3SPxYV59kXnA12BWdMr6D5eAAFgtBSX+/Yi+vLxMmEiszkwHLCA=
Earlier quoted context omitted.
I checked dmesg. It's clear that something bad happened, but I didn't get root. I don't really know what I'm looking at, I just ran arbitrary code on my least valuable machine trying to learn something. Want me to pastebin it? edit: It starts out [318258.327110] BUG: unable to handle kernel paging request at 0000001781ef7788 [318258.328251] IP: [ ] atomic_dec_and_mutex_lock+0x15/0x90 [318258.328251] PGD 2b18b067 PUD…
Same here: Linux (redacted) 3.2.0-41-virtual #66-Ubuntu SMP Thu Apr 25 03:47:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [ 413.309308] BUG: unable to handle kernel paging request at 0000001781eef4e8 [ 413.310359] IP: [ ] atomic_dec_and_mutex_lock+0x15/0xa0 [ 413.311025] PGD 1c4ec067 PUD 0 [ 413.311680] Oops: 0000 [#6] SMP [ 413.312007] CPU 0 Edit: disregard the timestamp above, VM has not synced with NTP for some time…
Earlier quoted context omitted.
I checked dmesg. It's clear that something bad happened, but I didn't get root. I don't really know what I'm looking at, I just ran arbitrary code on my least valuable machine trying to learn something. Want me to pastebin it? edit: It starts out [318258.327110] BUG: unable to handle kernel paging request at 0000001781ef7788 [318258.328251] IP: [ ] atomic_dec_and_mutex_lock+0x15/0x90 [318258.328251] PGD 2b18b067 PUD…
Same here: Linux (redacted) 3.2.0-41-virtual #66-Ubuntu SMP Thu Apr 25 03:47:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [ 413.309308] BUG: unable to handle kernel paging request at 0000001781eef4e8 [ 413.310359] IP: [ ] atomic_dec_and_mutex_lock+0x15/0xa0 [ 413.311025] PGD 1c4ec067 PUD 0 [ 413.311680] Oops: 0000 [#6] SMP [ 413.312007] CPU 0 Edit: disregard the timestamp above, VM has not synced with NTP for some time…
Can we please stop posts like that without a proper introduction? I'm counting myself as proficient in Linux for many years and all i get is that it's some C code and apparently some 0day. What? I'm certainly not starting to decipher that or compile and run it. p.s.: same should go for all the "x anounces y" where the posted link neither explains what x is nor what y is.
assert(!setuid(0));
return execl("/bin/bash", "-sh", NULL);
Tested the exploit on CentOS: Linux 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue Apr 23 19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux (latest CentOS kernel): [user@centos ~]$ gcc -O2 exploit.c [user@centos ~]$ ./a.out 2.6.37-3.x x86_64 sd@fucksheep.org 2010 -sh-4.1#
[test@libros-dev tmp]$ ./a.out
Killed
This is in dmesg:
[2112052.363397] Oops: 0000 [#1] PREEMPT SMP
[2112052.363890] CPU 0
[2112052.363969] Pid: 3775, comm: a.out Not tainted 3.8.5-1-ARCH #1 innotek GmbH VirtualBox/VirtualBox
Earlier quoted context omitted.
It's not that hard to port it to 32 bits, just hang on week or two. I'm just too lazy. IGjDf1e4eQxWyBFArYM8HgvCuns6p+GbfHoE3SPxYV59kXnA12BWdMr6D5eAAFgtBSX+/Yi+vLxMmEiszkwHLCA=
The goto and labels stick out like coal in a pile of gold.
Earlier quoted context omitted.
Can you back that up? The exploit states x86_64, and even if there is only an x86 exploit published, it's likely the same vulnerability is present on an x86_64 kernel (in general). Lack of exploit code doesn't imply a lack of vulnerability :)
I mean, the fix consists in making sure that attr.config has all the 64 bits cleared - on the 64 bit machines, int is 64bit, so u64 == int, and all the bits are correctly handled. on 32 bit machines, int is 32bit, and the top 32 bit of attr.config is not cleared. I may be wrong though, as I didn't scan through all the affected code.
gunther> gcc -O2 semtex.c
gunther> ./a.out
a.out: semtex.c:63: main: Assertion `(map = mmap((void*)0x380000000, 0x010000000, 3, 0x32, 0,0)) == (void*)0x380000000' failed.
Aborted
gunther> uname -r
3.4.2-x86_64-linode25