5 ms·
Linux local root exploit for CVE-2014-0038
- sillysaurus2 13y agoIs 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 https://news.ycombinator.com/item?id=7154922 ... Any distro using the x32 ABI is vulnerable, and Ubuntu just recently enabled the x32 ABI.
- mjn 13y agoI 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.
- microcolonel 13y agoIt 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).
- akerl_ 13y agoThis 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.
- mjn 13y agoOriginal discussion of CVE-2014-0038: https://news.ycombinator.com/item?id=7154618 https://news.ycombinator.com/item?id=7154618
- microcolonel 13y agoYou should clarify that it only applies to the x32 ABI. Which is only used on the(already vastly irresponsibly-constructed) Ubuntu 13.10.
- taf2 13y agowhy is it "vastly irresponsibly-constructed" ? I mean major hosting providers like rackspace use it... so ??
- nilved 13y agorackspace eats vaseline on toast
- deleted 13y ago[deleted]
- rodgerd 13y agoHere's why the Fedora maintainers rejected request to enable it: https://bugzilla.redhat.com/show_bug.cgi?id=854317 https://bugzilla.redhat.com/show_bug.cgi?id=854317 * It's new and unanalyzed for security flaws. * It's useless without the right userland tools, which don't exist. Ubuntu switched it on either because they have no clues, or because they wanted a checkbox to say "look, we have features no-one else does!!!!".
- aortega 13y agoThe main problem with Fedora is that it usually doesn't work. At all.
- growupkids 13y agoIs this a joke?
- jjoonathan 13y agoI wish. -Someone who just spent half of a perfectly good day wrestling with their buggy installer
- smtddr 13y agoHmm... #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.
- userbinator 13y agoRET is 195 or C3 in hex which also corresponds to modrm operands "eax, ebx" or "ebx, eax" so there's a pretty good chance of say a MOV instruction e.g. 89 C3, "mov ebx, eax" or something else also having that byte inside it, not to mention constants and offsets. (If you work with x86 asm enough, you will start memorising opcodes...)
- smtddr 13y agoHmm... so after looking at http://ref.x86asm.net/coder32.html http://ref.x86asm.net/coder32.html apparently 0xC2 and 0xC3 are RET. On my 32bit Linux machine, the following code printed "Okay! c2 found @ 174" Is this code correct in any way??? I guess the fact that I'm assuming every byte is a whole instruction; not even accounting for the operands is already a problem. But am I even reading the bytes properly at all? #include <stdio.h> void rightmeow() { int q; for(q = 0; q < 10 ; q++) printf("It's new!\n"); return; } int main(int argc, char** argv) { int i; unsigned char bytecode; for(i = 0; i < 9999 ; i++) { bytecode = (unsigned char)(**(rightmeow+i));//--- does this really work? if (bytecode == 0xC2 || bytecode == 0xC3) break; } if( i == 9999) printf("No good.\n"); else printf("Okay! %x found @ %d\n",bytecode,i); return 0; }
- userbinator 13y agoYou probably mean *(((unsigned char *)rightmeow)+i) but just change the "q < 10" line to "q < 195" and you should see the output change, since that immediate constant is going to be present at least once before the final ret. For me, changing that changes the output from c3 being found at 47 to it being found at 25.
- dewyatt 13y agoManjaro has CONFIG_X86_X32=y for the kernel I'm running (3.12.8). I can't figure out PTMX_FOPS so I can't test whether it's affected by this. :/
- dewyatt 13y agoApparently affected (http://forum.manjaro.org/index.php?topic=10498.0 http://forum.manjaro.org/index.php?topic=10498.0)
- aortega 13y agoTested on ubuntu 13.10 with latest updates. Doesn't work, but DID crash the kernel, so it's vulnerable.
- digitalpig 13y agotested on Ubuntu 13.10 with kernel 3.11.0-15-generic. CONFIG_X86_X32=y the program did not get the root privilege. Kernel did not crash either. Strange.
- seletskiy 13y agoTo make it work you need to patch exploit to your platform, like this (see defines section): https://github.com/seletskiy/cve-2014-0038/commit/d8daf0ff41dfad72a0d59dcac4a61e8c2e291772 https://github.com/seletskiy/cve-2014-0038/commit/d8daf0ff41... Just patched it to 3.8 kernel and it works.