Hacker News Reader

Comment by sargun | Hacker News Reader

How does this use-after-free turn into an arbitrary code execution vuln? I don't see any jmp to the pointer?

It depends on manipulating/knowing what gets allocated in the same region. If you know what gets written to the freed space or you can try to force the right allocations to happen, you get almost-arbitrary write.

For a made up example, imagine something allocates a structure with a pointer to a function struct->foo, then frees it, but still holds a reference. Now you call a function which allocates a buffer in the same place and copies your arguments into it. When you make the original code try to call struct->foo again, you can any function you want.

Are there practical attacks for write-after-free?

Controlling where the OS allocates an important structure seems very difficult and mistakes would likely result in corrupting unrelated data and a crash later on.

Sure there are. Kernel makes this a bit easier since you have heaps for objects of a given size (which means it's much easier to overlap old structure when you know the size). Browsers (for JS -> native escape) make it a bit easier by allowing you to allocate lots of objects and having pointers everywhere. In many cases you can also spam all over the heap and hope for the best, since allocations are almost always aligned.

I think most browser exploits are actually use-after-free. Check out how simple they can be: https://www.exploit-db.com/exploits/40946

What is the kernel-space equivalent of a root shell? presumably you wouldn't try to load your full payload into the kernel space, just try to give yourself root access somehow?

  current->cred->uid = 0;

It’s not difficult. Most modern allocators are pretty similar, and quite predictable. They keep a cache (usually per-thread or per-CPU) of free allocations for each allocation size[1], in the form of a stack. malloc() pops the last allocation from the stack, and free() pushes onto it. If you malloc() when the stack is empty, there’s some more logic to obtain a new chunk of allocations, but that’s not relevant here. Once the target (kernel in this case) frees an object, the allocation will be at the top of the stack, and whatever object it allocates next with the same size, on the same thread/CPU, will likely take its place. In the case of a kernel, most allocations are in response to syscalls or other requests from userland, so you can usually control what gets allocated next.

There usually is some risk of the allocator not doing what you expect, e.g. because of intervening mallocs/frees from other threads, which indeed is likely to lead to a crash. However, most exploits don’t need to be 100% reliable anyway. And there are various ways to increase reliability.

Caveat: Not all allocators work this way, and even among the ones that do, each has its unique quirks. However, the basic “first in, first out” behavior is quite common across a multitude of implementations. IIRC, the default Linux allocator (it has three to choose from!) is one of them.

[1] Actually range of allocation sizes. Such allocators will usually have a fixed list of “size classes”, which are just specific allocation sizes they support; allocation requests that fall between size classes will just be rounded up to the next highest one. Large allocations (e.g. 4kb+) are handled with a different path.

Not sure, but here's some data from Matt Miller at MSFT:

Fellow data nerds: here's a snapshot of the vulnerability root cause trends for Microsoft Remote Code Execution (RCE) CVEs, 2006 through 2017. A few callouts: heap corruption, type confusion, and uninit increased in 2017. Use after free steady y/y but proportionally declined. https://twitter.com/epakskape/status/984481101937651713

Followed by "focusing on C#, Rust and constrained C++ for future development at MSFT", on the slides from his last presentation.

Maybe it can be used to write a "0" into a useful kernel structure such as a forked process' effective uid (thus escalating to uid0)

Wouldn't that just be a privilege escalation though, not arbitrary code execution?

Well if you are root then you can usually load random kernel modules and in general do whatever you want on the system.

Does that mean then, that every privilege escalation be arbitrary code execution?

I'd say so, yes, assuming that you can then execute arbitrary code with the elevated privileges.

I'd say no, because to be able to make a privilege escalation attack useful, you'd have to already have arbitrary code execution.

Not necessarily. You could, for instance, elevate the privileges of a process you can't completely control, which might allow you to read sensitive files or disrupt a system, but not perform arbitrary actions with those privileges.

I concede that privesc without code execution can be useful, but my original claim that privesc is not necessarily code execution still stands.

I think we agree then? I said "assuming you can execute arbitrary code with the elevated privileges".

No, in some cases code execution is not the goal at all. A privesc can mean admin access to a system you didn't previously have access to, it can mean access to logs or a direct tap into network data in some systems. You often don't need arbitrary code exec for that since its features built into the apps or the systems hosting them.

No, since privilege escalation can also mean that you are able to take specific actions that you wouldn't otherwise be able to take. It does not always mean code execution.

Right...but that doesn't mean it's correct to refer to a privesc exploit as arbitrary code execution. For a privesc exploit to be valuable, you typically need to already have code execution.

EDIT: I concede in another comment that privesc without code execution can still be useful, but my original claim that privesc does not imply arbitrary code execution still stands.

Maybe it's shorthand for "arbitrary code execution in the kernel mode context".

That is not true for all systems, a lot of attacks in most systems do not need code execution but do need privilege escalation.

Getting privilege escalation by definition means that _you are allowed to do stuff you couldn't_ which in itself is an attack vector.

But privilege escalation does not imply "being root", it only means "ability to perform operation as root" (or whatever the role is can can be compromised). If your distribution accidentally packaged a suid root /bin/cat, that would allow a normal user to perform (read) operations on all files on the system, so it would be a privilege escalation, but it would not necessarily lead to arbitrary code execution as root (unless that allowed you to read a file with the root password, say).

Going off topic, but did you use a password generator to create your username or something? Or does it have a meaning?

It's the payload for a browser exploit

Overwrite the return address or a function pointer instead. Then when the address/pointer is used you can execute whatever you want. Loop up Return Oriented Programming.

I urge the mods to correct the title. Maybe: Linux<4.20.10 af_alg_release use-after-free vulnerability[CVE-2019-8912]

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

See line 126-127 and compared to the patch at the bottom of: http://patchwork.ozlabs.org/patch/1042902/

Patch is not yet merged into 5.0.0rc7 either. Whereas it is in linux-next. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...

Update: I expect all of the longterm kernels listed on kernel.org will get a backport.

That's too complicated. If someone can distill this to a simple, clear, neutral title, we'll happily change it.

Reply on news.ycombinator.com