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

11–20 of 36 posts

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

#11

Post by userbinator »

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.

RET 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...)

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

#12

Post by revelation »

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.

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

#14

Post by nilved »

taf2 wrote: post #8
microcolonel wrote: post #4

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

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

rackspace eats vaseline on toast

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

#15

Post by smtddr »

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

RET 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...)

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;
      for(q = 0; q

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

#18

Post by rodgerd »

taf2 wrote: post #8
microcolonel wrote: post #4

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

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!!!!".

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

#19

Post by userbinator »

smtddr wrote: post #15
userbinator wrote: post #11

Earlier quoted context omitted.

RET 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...)

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.

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

#20

Post by [deleted] »

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.

[deleted]
Post reply on HN