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

Linux local root exploit for CVE-2014-0038

github.com

Post reply on HN
Print view View original

21–30 of 36 posts

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

#21

Post by userbinator »

revelation wrote: post #12
smtddr wrote: post #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.

Of course, functions commonly have multiple rets, jump tables at the end, etc. I don't think theres a robust way sans symbols.

If you know the address of the function that comes immediately after it, then subtract the two. This will include padding nops at the end etc. so it might be slightly bigger than the real size but you won't be missing bytes from the tail, which is what really matters in this application.

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

#22

Post by smtddr »

userbinator wrote: post #19
smtddr wrote: post #15

Earlier quoted context omitted.

Hmm... so after looking at 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 void rightmeow() { int q;…

You 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.

Nice! For me it changed from being found at 38, to 34. I wonder why you get C3 while I get C2.

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

#24

Post by aortega »

smtddr wrote: post #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.

Maybe it is possible if you don't use any optimizations and always use the same compiler.

A function may have the RET in the middle of it. Or use a jmp instead of ret (tail optimization), etc.

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

#25

Post by aortega »

rodgerd wrote: post #18
taf2 wrote: post #8

Earlier quoted context omitted.

why is it "vastly irresponsibly-constructed" ? I mean major hosting providers like rackspace use it... so ??

Here's why the Fedora maintainers rejected request to enable it: 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!!!!".

The main problem with Fedora is that it usually doesn't work. At all.

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

#27

Post by growupkids »

aortega wrote: post #25
rodgerd wrote: post #18

Earlier quoted context omitted.

Here's why the Fedora maintainers rejected request to enable it: 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!!!!".

The main problem with Fedora is that it usually doesn't work. At all.

Is this a joke?

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

#28

Post by userbinator »

smtddr wrote: post #22
userbinator wrote: post #19

Earlier quoted context omitted.

You 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.

Nice! For me it changed from being found at 38, to 34. I wonder why you get C3 while I get C2.

C2 is RET iw, i.e. has 16-bit immediate value following the instruction, the # of bytes of parameters to pop from the stack. That should be 0 in this case so it could use C3 and save 2 bytes, but compilers aren't always really intelligent, although this is the first time I've seen that.

Then again, it could be something else and not the actual return you found.

Post reply on HN