|
|
|
|
|
by notaplumber1
1285 days ago
|
|
> As others have mentioned as well using ROP to jump to the syscall instructions in libc with your own arguments (it’s not special…) bypasses restrictions in the current design. ...ignoring other mitigations. > In fact I can extend it with something OpenBSD does not have a good implementation of yet, strong CFI, which would prevent jumping into the middle of a function to execute that syscall instruction. But there are more fundamental reasons why this doesn’t work. Sounds like you need to spend 5 more minutes reading about retguard. |
|
Anyways, the critical word in the thing you've quoted is "strong"–retguard falls apart if the attacker has the ability to leak the value being used to protect the stack. In almost all cases an attacker in the position to make a controlled call into libc has the ability to also leak or forge any value of their choosing in the address space. A strong implementation would typically move this value completely out of the reach of such an attacker, for example by implementing signing in hardware (e.g. PAC) or or at a higher privilege level. I don't think these things are really feasible yet for OpenBSD so I don't blame them for not doing it, but without strong CFI it's hard to actually prevent this kind of thing from happening. (And, as I mentioned, this was only a tangent anyways; even with good CFI the more fundamental issue remains.)