[HN Gopher] Memory sealing for the GNU C Library
___________________________________________________________________
Memory sealing for the GNU C Library
Author : todsacerdoti
Score : 144 points
Date : 2024-06-20 18:42 UTC (2 days ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| saagarjha wrote:
| I'm curious if a msealed region can have breakpoints placed in
| it.
| snickerbockers wrote:
| 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.
| bonzini wrote:
| Yes, gdb sets them with ptrace when debugging other user mode
| processes.
| ilammy wrote:
| 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.
| CGamesPlay wrote:
| 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?
| htthbjk wrote:
| Sometimes you do get arbitrary code execution, but you are in a
| Chrome sandbox.
|
| One use of mseal is for defense in depth, where you try making
| it as hard as possible to un-sandbox the sandbox.
| saagarjha wrote:
| mseal is not designed to protect against sandbox escapes
| snickerbockers wrote:
| 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.
| winternewt wrote:
| The detail is that mprotect also lets you add the writable flag
| back. With mseal the kernel will refuse future changes to the
| protection flags.
| superb_dev wrote:
| 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
| fweimer wrote:
| 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.
| saagarjha wrote:
| mseal prevents you from doing that in reverse.
| 0xbadcafebee wrote:
| 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.
| robertlagrant wrote:
| Where do we see this outside of software development?
| DaiPlusPlus wrote:
| Automotive.
|
| 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...).
| fl0ki wrote:
| 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.
| MaxBarraclough wrote:
| > we've known for decades that having smooth and fluid
| (60fps) UI goes a long way to reducing user stress and
| frustration
|
| This hasn't stopped appalling bloat becoming the norm on
| the web, either.
| DaiPlusPlus wrote:
| Bloat on the web generally doesn't impact frame-rate,
| though - just memory usage.
| MaxBarraclough wrote:
| It harms loading times, which harms smoothness/fluidity.
|
| _edit_ On second thought, it can harm framerates too.
| There are plenty of webdev discussion threads about
| achieving 60fps.
| kvemkon wrote:
| Recently discussed: https://news.ycombinator.com/item?id=40660034
| 36 points by chmaynard 10 days ago
___________________________________________________________________
(page generated 2024-06-22 23:01 UTC)