I was struggling to figure out how this could even be exploited. Following a trail of links led to <https://v8.dev/blog/control-flow-integrity#corrupted-syscall...>, which motivated the API. It gives the example that "if a thread calls munmap on a corrupted pointer, the attacker could unmap read-only pages and a consecutive mmap call can reuse this address, effectively adding write permissions to the page."
So, a hypotetical attack would involve 1) Corrupt a pointer passed to munmap, such that it points to some believed-executable part of the code (e.g. the MPEG decompression library code, or something like that). 2) Cause a future `mmap` to reuse that page with writable permissions, and in particular have the returned page be one that is eventually destined for being marked executable (e.g. the caller should be the JIT compiler). 3) Modify the writable page to control code you want at a known address (e.g. by having the JIT emit code you want, or by having another vulnerability that writes to this address). 4) Have the target page marked executable (e.g. by finishing the JIT compilation). 5) Finally, call the executable page (e.g. attempt to decompress an MPEG file).
In the absence of already having arbitrary code execution (which would make the whole process moot), this whole thing requires a JIT compiler (since it has to already contain a call to `mprotect` that sets a page executable), and either the JIT compiler has a bug or a separate thread performs step 3.
Are there any example of this kind of attack actually happening? Is there a simpler attack I'm not seeing?
It's crazy how much time it takes for commonplace system design properties to get adopted by the larger programming discipline. Immutability for system security has been used for at least a decade. But software development exists within its own organism, protected by an impermeable membrane. New ideas from outside its domain (software design) don't easily pass through. Yet occasionally you have a programming organism whose focus is influenced by some other discipline (e.g. OpenBSD, for security) and some new ideas get passed through the membrane. It would be neat if we could bring back the heyday of research operating systems / software, to push the cultural envelope of software development to think more outside the box.
It's 2024; the infotainment displays and UI from the major (legacy) Detroit automakers just makes my skin-crawl from the touch-latency, single-digit frame-rates, and overall lack-of-good-taste in design. And yet, we've known for decades that having smooth and fluid (60fps) UI goes a long way to reducing user stress and frustration.
(I stress that I'm not advocating huge touch-screens for everything; but yet it's a sad day when Tesla's demonstrably unsafe touch-screen UX is otherwise oftentimes better overall than the physical-ish buttons/ridges (capacitative touch?!!) from Chevrolet (and I'm still waiting for a volume-knob with detents...).
Apple CarPlay may have given automakers just barely enough of an "out" that the pressure is reduced. The only time I use the system's own interface is to update its firmware once a year, and the only time those updates have noticeably mattered was to make my car compatible with CarPlay over USB Type-C.
Given this, it's surprising to me to see reluctance to adopting second-generation CarPlay, but someone who knows more about the tradeoffs can certainly account for that better than I can.
I just got an older (2020) truck with an older generation Ford infotainment (SYNC 3) with CarPlay/Android Auto. I use AA, and its huge latency and the difficulty of use (capacitive touch, the physical buttons on the media console are useless) make it hard to use. I notice my eyes are locked on the console for much longer than necessary because it's so hard to press things and then wait for a response, or go back if the wrong thing got touched. I don't have my eyes on the road and it feels dangerous.
If they had just made the radio tuning knob into a scroll wheel for the UI, it would be so much easier, quicker, safer to navigate the screen. But I know they'll be going in the opposite direction due to tech trends. We need hackers to save us.
Yes, breakpoints will still work. Debuggers generally use POKETEXT to write breakpoints, which ignores any write protection on pages. mseal does not affect this use case.
that's an interesting point. i know at the kernel level gdb supports hardware breaks that don't need to add in the trap instruction but I'm not sure if those are available to user-mode processes.
I'm a little confused, can't you already clear the page's write flag with mprotect? i feel like I must missing some important detail because iiuc mseal doesn't bring anything new to the table.
I believe the difference is that ‘mseal’ goes further than preventing any writes to memory, it also prevents the address space itself from changing. For example: if some file had been ‘mmap’ed in before the call to ‘mseal’, it can’t then be unmapped
It does not prevent all writes, it only prevents protection flag changes, mapping over the region, and unmapping. As far as I understand it, sealed memory might even be writable. If the sealed memory is read-only, debuggers and other tools can still patch mseal'ed memory regions using ptrace and similar interfaces.
So, a hypotetical attack would involve 1) Corrupt a pointer passed to munmap, such that it points to some believed-executable part of the code (e.g. the MPEG decompression library code, or something like that). 2) Cause a future `mmap` to reuse that page with writable permissions, and in particular have the returned page be one that is eventually destined for being marked executable (e.g. the caller should be the JIT compiler). 3) Modify the writable page to control code you want at a known address (e.g. by having the JIT emit code you want, or by having another vulnerability that writes to this address). 4) Have the target page marked executable (e.g. by finishing the JIT compilation). 5) Finally, call the executable page (e.g. attempt to decompress an MPEG file).
In the absence of already having arbitrary code execution (which would make the whole process moot), this whole thing requires a JIT compiler (since it has to already contain a call to `mprotect` that sets a page executable), and either the JIT compiler has a bug or a separate thread performs step 3.
Are there any example of this kind of attack actually happening? Is there a simpler attack I'm not seeing?