> iOS is execute-only; Android tried a few years ago (abandoned)
Wonder if the author is aware of the reasons why this was disabled (it's functionally gone on both platforms). On iOS newer processors have PAC which provides much stronger guarantees against ROP and Linux disabled it because execute-only mappings bypass PAN: https://blog.siguza.net/PAN/.
> Dumb applications that invent their own ABI (very few)
I mean I know this is meant to be bait but I'll take it, applications that use their own internal ABI are valid programs.
> On every kernel entry, if the RPKU register has been changed kill the process
> When a process does a system call, the SP register MUST point to stack memory!
> Stack and Syscall Protection detect a variety of easier exploit patterns, pushing the ROP programmer to explore more challenging schemes, which may not be viable
> Increasing exploitation difficulty is a valid strategy
Ok so this is the actual interesting part of the paper, because it seems like they are trying to shore up their syscall-origin protections which are not very strong in the presence on ROP, except trying to do so on hardware that doesn't really have CFI protections.
As far as I can tell, this Xonly protection only attempts to disrupt blind ROP ("you can't read the code anymore"), rather than construction of a full ROP chain. There are some attempts to validate things on entry to the kernel (pc, sp) but they are under control of userspace so what probably will happen here is that they get switched back to sane values prior to kernel entry and then adjusted to attacker-controlled values again. I expect this to require some cleverness on the side of attackers but this is typically how such checks are bypassed, assuming that there is not some other overlooked way to get around it.
This brings us to OpenBSD's strategy for exploit mitigation, which is in my eyes has far too much tunnel vision: it tries to match on individual exploit strategies, rather than trying to protect against more general problems. The policy of "let's make exploitation harder" is actually very close to something I'm working on right now and it has a number of important caveats that I don't see addressed here.
These things are true:
* Reducing the reliability of an exploit makes it far less attractive.
* Adding non-perfect mitigations against common exploitation strategies makes it so that people can't just throw a proof-of-concept against another platform against your system.
However, these are also true:
* Attackers are very, very good at turning "we made this 99% secure!" into "this will basically never work".
* Attackers will construct new strategies that you didn't think of to attack the same underlying problem if you don't fix it, if given adequate time.
I am not an exploit author, so take this with a grain of salt, but I would guess that an experienced team could probably come up with a way to do either of the above in maybe a year. And at that point, once it's broken, the cost from the OpenBSD side to improve upon this protection is high, because they will break the entire design of this thing, which requires a human to revisit this and create a new clever design to keep attackers at bay. In that way it will become just a routine step in an exploit to evade the protection, as opposed to say NX, which completely killed the ability to ever do shellcode execution from the stack, necessitating the development of ROP over multiple years. Good mitigations are highly asymmetric in terms of effort required to design them versus how long an attacker needs to take to fully bypass them. Usually this means that if you're spending significant time designing something it will probably want to be sound rather than reducing the window of opportunity for an exploit.
> Wonder if the author is aware of the reasons why this was disabled (it's functionally gone on both platforms). On iOS newer processors have PAC which provides much stronger guarantees against ROP and Linux disabled it because execute-only mappings bypass PAN: https://blog.siguza.net/PAN/.
Yes, of course he is. He even mentions PAN being broken in the recording. What doesn't make sense is the Android/Linux decision to entirely abandon execute-only. Let PAN be broken, newer chips will eventually fix it in hardware (EPAN) and older chips without PAN (notably, the Raspberry Pis) still get full protection.
The Xonly stuff they talk about is so weird to me, because almost no one cares about exfiltrating assembly for dynamic ROP creation or whatever? Even if you are doing fingerprinting of binaries to pick an exploit version, you do that with a stack leak for return addresses to get relative offsets for a ROP or figure out a version. If someone is doing a ROP for an exploit they probably already have a built ROP chain to use with it!
Execute-only makes more sense for kernel exploits, and especially for the BSDs that do extremely aggressive per-codeunit kASLR at startup, but the fact Android dropped it should make you double think how worthwhile it is.
> This brings us to OpenBSD's strategy for exploit mitigation, which is in my eyes has far too much tunnel vision
While I understand where that comes from, I'd argue that OpenBSD does both. There is quite a few more general approaches in the system.
In my opinion (which might be wrong, please disagree!) you need both, because one tends to have that issue that layers and layers of general mitigation are added, but when someone takes a look the issues tend to arise where the specific setup and general context is exploited which is harder to protect against.
There is a great talk that I can't find right now, that is about a company network that was pretty securely set up, but taking a look at the constellation (including specifications of standard protocols) is abused to still compromise it.
I am not sure if that's the best approach, but while I agree it's overall better to completely rule out a whole class of bugs/attacks go for it, however it's usually with exceptions which is why these these things are even still a topic.
I think OpenBSD has tunnel vision on the wrong part of an exploit. Like they'll read a blog post on how to construct a ROP chain and instead of figuring out how you might prevent someone from subverting control flow they look at the tool used to find gadgets and try to make that harder. Or if they see exploits that spray syscall instructions they will block them in JIT regions. The problem here is that these aren't actually the hard parts that need significant effort to change for an attacker, they're really just whatever happened to be convenient. You can do a very specific mitigation that e.g. hardens a problematic API but you really want to make sure an attacker goes "hmm, I am not really sure what I would do if you blocked this, I guess I'll have to think for a while about how I might even get started" versus "sigh, this is annoying, guess I need to try the other way that is a little more work".
I hope so! There’s not much to share yet because I’m still working on evaluating how well it would work, but the aim is to make n-day exploits infeasible to deploy to devices that are still vulnerable. It’s difficult because we are have very little we can work with when dealing with an attacker who can fully compromise the device, but some preliminary analysis of the strategy against recent exploits and approximations of how they might change if we ship are promising. The key point is that we expect our strategies to “expire” on a given timeline and need to explicitly design in a way to respond to changing techniques in a way that is highly asymmetric. We’ve found that the closer to the actual bug you place a mitigation the harder it becomes to work around, and we think we have a new way to get very close cheaply.
Wonder if the author is aware of the reasons why this was disabled (it's functionally gone on both platforms). On iOS newer processors have PAC which provides much stronger guarantees against ROP and Linux disabled it because execute-only mappings bypass PAN: https://blog.siguza.net/PAN/.
> Dumb applications that invent their own ABI (very few)
I mean I know this is meant to be bait but I'll take it, applications that use their own internal ABI are valid programs.
> On every kernel entry, if the RPKU register has been changed kill the process
> When a process does a system call, the SP register MUST point to stack memory!
Has https://xerub.github.io/ios/kpp/2017/04/13/tick-tock.html vibes
> Stack and Syscall Protection detect a variety of easier exploit patterns, pushing the ROP programmer to explore more challenging schemes, which may not be viable
> Increasing exploitation difficulty is a valid strategy
Ok so this is the actual interesting part of the paper, because it seems like they are trying to shore up their syscall-origin protections which are not very strong in the presence on ROP, except trying to do so on hardware that doesn't really have CFI protections.
As far as I can tell, this Xonly protection only attempts to disrupt blind ROP ("you can't read the code anymore"), rather than construction of a full ROP chain. There are some attempts to validate things on entry to the kernel (pc, sp) but they are under control of userspace so what probably will happen here is that they get switched back to sane values prior to kernel entry and then adjusted to attacker-controlled values again. I expect this to require some cleverness on the side of attackers but this is typically how such checks are bypassed, assuming that there is not some other overlooked way to get around it.
This brings us to OpenBSD's strategy for exploit mitigation, which is in my eyes has far too much tunnel vision: it tries to match on individual exploit strategies, rather than trying to protect against more general problems. The policy of "let's make exploitation harder" is actually very close to something I'm working on right now and it has a number of important caveats that I don't see addressed here.
These things are true:
* Reducing the reliability of an exploit makes it far less attractive.
* Adding non-perfect mitigations against common exploitation strategies makes it so that people can't just throw a proof-of-concept against another platform against your system.
However, these are also true:
* Attackers are very, very good at turning "we made this 99% secure!" into "this will basically never work".
* Attackers will construct new strategies that you didn't think of to attack the same underlying problem if you don't fix it, if given adequate time.
I am not an exploit author, so take this with a grain of salt, but I would guess that an experienced team could probably come up with a way to do either of the above in maybe a year. And at that point, once it's broken, the cost from the OpenBSD side to improve upon this protection is high, because they will break the entire design of this thing, which requires a human to revisit this and create a new clever design to keep attackers at bay. In that way it will become just a routine step in an exploit to evade the protection, as opposed to say NX, which completely killed the ability to ever do shellcode execution from the stack, necessitating the development of ROP over multiple years. Good mitigations are highly asymmetric in terms of effort required to design them versus how long an attacker needs to take to fully bypass them. Usually this means that if you're spending significant time designing something it will probably want to be sound rather than reducing the window of opportunity for an exploit.