Free software's not-so-eXZellent adventure
Free software's not-so-eXZellent adventure
Posted Apr 3, 2024 10:01 UTC (Wed) by khim (subscriber, #9252)In reply to: Free software's not-so-eXZellent adventure by tux3
Parent article: Free software's not-so-eXZellent adventure
> Those run after relro, so that you can't overwrite the GOT.
Of course you can! Lots of games (or, rather, their cheat-protection systems) are doing that. Just call mprotect.
Only as long as regular users don't feel the heat. Recall how long it took for people to accept SELinux and not reflexively turn it off on a new installations to reduce number of support calls.
What you are proposing is significantly more intrusive (if you would also introduce enough hoops to make simple call to mprotect syscall unfeasible) and it's unclear how hard would you need to circumvent all these hoops.
Most mitigation strategies are working on the assumption that malicious code is still severely restricted at what it may do because it vas injected in your process using very “narrow” path (few bytes of buffer overflow, heap-spraying and so on).
Library, on the other hand, is very “wide” path. Trying to make it “narrow” would introduce so many disruptions that we would get the same effects that banks with strict “security teams” are getting: they enforce protocols to dirsuptive and painful that people are just moving data outside of these protocols to ensure that some would would actually be done… and then it leaks (or worse) from there.
Posted Apr 3, 2024 10:40 UTC (Wed)
by tux3 (subscriber, #101245)
[Link] (1 responses)
Please do, that is actually my dream scenario!
If closing the ifunc vector forces attackers to use mprotect() or similar noisy syscalls, I'm counting this as a win, I'd be very happy with that result
>What you are proposing is significantly more intrusive (if you would also introduce enough hoops to make simple call to mprotect syscall unfeasible) and it's unclear how hard would you need to circumvent all these hoops.
I think we should consider separately mitigations that affect everyone (e.g. a new compile flag for a binary to opt-out of the ifunc mechanism, even in any of the libs it loads), and detection efforts.
I'm proposing that we make it hard to do things quietly for everyone, so that attackers make noise.
Then a CI system somewhere, not your computer, can do some heavy instrumentation without impacting regular users
Agree that we can't try to make libraries too 'narrow'. At some point if you run malicious code, you run malicious code. But letting malicious code run during load-time, before relro, in a process that otherwise would never have called liblzma I think is making it too easy for the attackers.
If we have an opt-in to close the really dangerous stealthy attack vectors like ifuncs in sshd, then attackers may have to make noise (e.g. mprotect), and a "run-time linter" might catch them.
Posted Apr 3, 2024 11:51 UTC (Wed)
by khim (subscriber, #9252)
[Link]
Unlikely, as I wrote already: “closing the ifunc vector” would just lead to proliferation of juicy, ready-to-exploit tables full of function pointers in the unprotected Then you would just need to pick the one you feel is most stable to exploit it. That one is 200% impractical for most apps, including That's entirely impractical: our current OOP-style paradigm relies too much on using vtables. And while function pointer tables are, very often, protected, the actual references to these tables are not. And fixing that issue is utterly impractical: that's literally the way we have been developing software for last few decades. Going back to the drawing board and switching to some other development methodology is even harder then creation of a new hardware, this may only happen if we would develop new way to doing things and then wait for a new generation of developers to grow. Unfortunately it's also something that is used for many fully legitimate purposes. Forget ifunc's! These were just a low-hanging fruit which were easy to exploit, but compared to bazillion vtables embedded everywhere… which are already numerous and which would greatly increase in numbers if you would disable I'm really glad that no one takes your ideas seriously because in your attempt to play the whack-the-mole game you are proposing solutions which would lead to multiplication of such moles… that's a losing game. Security is not achieved by replacement of standard solution with bazillion ad-hoc ones, each with its own juice security hole.
Posted Apr 3, 2024 16:33 UTC (Wed)
by aaronmdjones (subscriber, #119973)
[Link]
It wouldn't surprise me if, due to this attack, in the near future we get a linker option (-z foo) that instructs the dynamic linker to extend full RELRO by calling mseal(2) on the GOT and such before invoking any global ctors or main().
I also wouldn't be surprised if OpenBSD is considering doing exactly the same thing for all of their userspace right now; they have an mimmutable(2). If they haven't already.
Free software's not-so-eXZellent adventure
I am thinking about writing a detector for strange behavior in new Debian uploads, and an mprotect syscall on plt.got is a super cut-and-dry reason for my detector to flag a package as suspicious =)
> If closing the ifunc vector forces attackers to use mprotect() or similar noisy syscalls, I'm counting this as a win, I'd be very happy with that result
Free software's not-so-eXZellent adventure
.data segment.ssd. Before you may even contemplate that you first need to move pam mechanism into separate process.ifuncs…Free software's not-so-eXZellent adventure