Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux local privilege escalation 0day, 2.6.37 - 3.8.10

fucksheep.org

Post reply on HN
Print view View original

11–20 of 100 posts

Re: Linux local privilege escalation 0day, 2.6.37 - 3.8.10

#11

Post by mooism2 »

rdl wrote: post #7
buster wrote: post #4

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.

I wish HN would allow both text and links in the same article. Otherwise you basically have to write a blog entry.

HN encourages you to write a blog post and submit that, yes.

Re: Linux local privilege escalation 0day, 2.6.37 - 3.8.10

#12

Post by [deleted] »

reiche wrote: post #3

Hm, doubtful. PS1/ $ w 12:17:27 up 38 days, 17:18, 1 user, load average: 0.44, 0.11, 0.04 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT user pts/0 Narnia 07:11 0.00s 0.25s 0.11s w PS1/ $ uname -a Linux Rivendell 2.6.32-358.2.1.el6.x86_64 #1 SMP Wed Mar 13 00:26:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux PS1/ $ cat /etc/redhat\-release CentOS release 6.4 (Final) PS1/ $ ./a.out 2.6.37-3.x x86_64 sd@fucksheep.org 2010 a.out:…

[deleted]

Re: Linux local privilege escalation 0day, 2.6.37 - 3.8.10

#15

Post by calinet6 »

theon144 wrote: post #13

Wait, so let me get this right: This is a Linux local privilege escalation 0day that works on (most) kernels ver. 2.6.37 to 3.8.10?

Well... [2.6.37, 3.8.10) -- non-inclusive on the upper bound.

Fixed in 3.8.10 so that one's good.

Otherwise, yes, yes it is.

*Edit: Actually it looks like it's fixed in 3.8.9 (made it in 3.8.9rc8) based on the patch at: https://patchwork.kernel.org/patch/2441281/ -- Someone with more knowledge of kernel dev should double-check.

Re: Linux local privilege escalation 0day, 2.6.37 - 3.8.10

#16

Post by 0x0 »

ddalex_ro wrote: post #14

Just from looking at the code, this exploit works only for 32 bit machines, all 64 bit installations should be fine.

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 :)

Re: Linux local privilege escalation 0day, 2.6.37 - 3.8.10

#18

Post by calinet6 »

ezdiy wrote: post #2

Silent patched a while ago: Kernel must be compiled with PERF_EVENTS (default on most modern distros). Bug fixed in 3.8.10. This is the kill log: http://lkml.indiana.edu/hypermail/linux/kernel/1304.1/04302.... This bug got apparently backported from 2.6.37 into centos6 2.6.32 kernels. patch here: https://patchwork.kernel.org/patch/2441281/

The patch looks like it's present in 3.8.9 also, correct? (someone double-check)

Re: Linux local privilege escalation 0day, 2.6.37 - 3.8.10

#19

Post by ezdiy »

calinet6 wrote: post #18
ezdiy wrote: post #2

Silent patched a while ago: Kernel must be compiled with PERF_EVENTS (default on most modern distros). Bug fixed in 3.8.10. This is the kill log: http://lkml.indiana.edu/hypermail/linux/kernel/1304.1/04302.... This bug got apparently backported from 2.6.37 into centos6 2.6.32 kernels. patch here: https://patchwork.kernel.org/patch/2441281/

The patch looks like it's present in 3.8.9 also, correct? (someone double-check)

You're correct.

Bug is in 2.6.37-3.8.8, fixed in 3.8.9.

http://lxr.linux.no/linux+v3.8.9/kernel/events/core.c#L5331

Re: Linux local privilege escalation 0day, 2.6.37 - 3.8.10

#20

Post by ddalex_ro »

0x0 wrote: post #16
ddalex_ro wrote: post #14

Just from looking at the code, this exploit works only for 32 bit machines, all 64 bit installations should be fine.

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.

Post reply on HN