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

31–36 of 36 posts

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

#31

Post by emillon »

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.

As others said, you can't really do it without disassembling the function (bonus problem: the general case is undecidable). A solution is to have your linker insert a "end of function" symbol in the ELF object (using a linker script), and import it in your C code a pointer. Then the size of f is "f_end - (void\*) f".

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

#32

Post by Daviey »

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.

What a ridiculous comment, a non-LTS release introducing new features are one of its core features. A security issue being introduced via upstream code is not something that should be an opportunity to berate Ubuntu. The way Ubuntu responded with a super quick turnaround should be praised.

Note, that Kees who raised it to linux-distro’s is a member of the Ubuntu Technical Board, Ubuntu provided a fixed kernel as part of the embargoed security window of a mere 2 days(!) and Kamal Mostafa (Canonical) provided a rebased patch back to upstream Linux 3.8.

Ubuntu was even praised on the disclosure thread [0], for this super-fast turnaround. This only cements my confidence in the Ubuntu product.. and has helped sow the seeds for an exciting Ubuntu 14.04 LTS release.

Seems the whole process worked as a well-oiled machine, making the whole Linux ecosystem safer. Note, these types of issues only tend to get discovered when they are enabled in the wild.

[0] http://seclists.org/oss-sec/2014/q1/201

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

#33

Post by rodgerd »

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.

I guess I'm imagining all these working installs then.

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

#34

Post by revelation »

userbinator wrote: post #21
revelation wrote: post #12

Earlier quoted context omitted.

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.

Hence why I mention symbols, that would have been exactly the way I'd do it. But without symbols, you can't know what the next function is, thats entirely upon the compiler (linker even) to decide.

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

#35

Post by userbinator »

revelation wrote: post #34
userbinator wrote: post #21

Earlier quoted context omitted.

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.

Hence why I mention symbols, that would have been exactly the way I'd do it. But without symbols, you can't know what the next function is, thats entirely upon the compiler (linker even) to decide.

Usually they'll be in the same order as they were in the source code.

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

#36

Post by microcolonel »

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

What a ridiculous comment, a non-LTS release introducing new features are one of its core features. A security issue being introduced via upstream code is not something that should be an opportunity to berate Ubuntu. The way Ubuntu responded with a super quick turnaround should be praised. Note, that Kees who raised it to linux-distro’s is a member of the Ubuntu Technical Board, Ubuntu provided a fixed kernel as part…

Fedora and Archlinux are both bleeding-edge upstream releases, and neither of them were comfortable enabling X32.
Post reply on HN