Live data from Hacker News

Linux local root exploit for CVE-2014-0038

github.com

1–10 of 36 posts

Re: Linux local root exploit for CVE-2014-0038

#2
Is this a universal exploit? Which distros are unaffected?

If it's non-universal, why is it? E.g. if it only affects Ubuntu, then what is it about Ubuntu that allows this to work?

EDIT: This seems to be the answer: https://news.ycombinator.com/item?id=7154922 ... Any distro using the x32 ABI is vulnerable, and Ubuntu just recently enabled the x32 ABI.

Re: Linux local root exploit for CVE-2014-0038

#5

Is this a universal exploit? Which distros are unaffected? If it's non-universal, why is it? E.g. if it only affects Ubuntu, then what is it about Ubuntu that allows this to work? EDIT: This seems to be the answer: https://news.ycombinator.com/item?id=7154922 ... Any distro using the x32 ABI is vulnerable, and Ubuntu just recently enabled the x32 ABI.

I believe only Ubuntu is affected, of the major distros. The bug affects kernels compiled with CONFIG_X86_X32, which enables the new-ish x32 ABI, a way for processes to use x86-64 features like the extended register set, while retaining the 32-bit pointer size. The more conventional approach to 32/64-bit code mixing (e.g. in Debian) is that 32-bit processes use the old x86 ABI, while 64-bit processes use the new x86-64 ABI. The x32 ABI was borne out of people noticing that the x86-64 architecture's improvements weren't all about 64-bitness, and that some of them were relevant to 32-bit programs too. So it keeps 32-bit pointers, but otherwise uses x86-64 features, so even 32-bit processes can take advantage of running on x86-64 chips (everything except the 64-bit part). Nothing inherently wrong with the idea, but it introduces some new critical codepaths into the kernel that have to be thoroughly tested.

Re: Linux local root exploit for CVE-2014-0038

#6

Is this a universal exploit? Which distros are unaffected? If it's non-universal, why is it? E.g. if it only affects Ubuntu, then what is it about Ubuntu that allows this to work? EDIT: This seems to be the answer: https://news.ycombinator.com/item?id=7154922 ... Any distro using the x32 ABI is vulnerable, and Ubuntu just recently enabled the x32 ABI.

It only applies to one very new alternative ABI for 64-bit x86 machines called x32, I'm not sure how widely deployed this ABI is, but I'm pretty sure it's not the default on anything.

Edit: turns out that 13.10 is released with the CONFIG_X86_X32 option enabled, just the usual negligent excessive differentiation that Canonical loves to impose on its customers(see Mir and moving forward with Upstart for recent examples).

Re: Linux local root exploit for CVE-2014-0038

#7

Is this a universal exploit? Which distros are unaffected? If it's non-universal, why is it? E.g. if it only affects Ubuntu, then what is it about Ubuntu that allows this to work? EDIT: This seems to be the answer: https://news.ycombinator.com/item?id=7154922 ... Any distro using the x32 ABI is vulnerable, and Ubuntu just recently enabled the x32 ABI.

This exploit affects systems with CONFIG_x86_X32 enabled. As it was a point of confusion on the previous post, this refers to the x32 ABI on 64 bit systems.

Essentially, if this option is enabled, someone can use the linked code to exploit an x32 syscall and escalate privileges.

Ubuntu specifically is a target because they recently enabled this option; I'm not aware of any other distros that have done so.

Re: Linux local root exploit for CVE-2014-0038

#9

You should clarify that it only applies to the x32 ABI. Which is only used on the(already vastly irresponsibly-constructed) Ubuntu 13.10.

There was a new deb package hitting the repos a few hours after the CVE, so it doesn't seem that they are sleeping on the job...

Re: Linux local root exploit for CVE-2014-0038

#10
Hmm...

  #define PAYLOADSIZE 0x2000
  code += PAYLOADSIZE - 1024;
  memcpy((void*)code, &kernel_payload, 1024);
Does anybody know if it's possible to find out the size of a function during run time? Could you like say, put a return at the end of the function then do a for-loop with memcpy() for each byte until you run into the OPCODE for RET? I guess I could do a test.
Post reply on HN