6 ms·
Are there practical attacks for write-after-free? Controlling where the OS allocates an important structure seems very difficult and mistakes would likely resu
by kanox 8y ago
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.
- viraptor 8y agoSure 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 https://www.exploit-db.com/exploits/40946
- mediocrejoker 8y agoWhat 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?
- monocasa 8y agocurrent->cred->uid = 0;
- comex 8y agoIt’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.
- cjarrett 8y agoNot 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 https://twitter.com/epakskape/status/984481101937651713
- pjmlp 8y agoFollowed by "focusing on C#, Rust and constrained C++ for future development at MSFT", on the slides from his last presentation.