4 ms·

> Building the ROP chain itself is pretty straightforward. There are enough gadgets in libc to perform it and all the symbols are in libc as well, and we alread

> Building the ROP chain itself is pretty straightforward. There are enough gadgets in libc to perform it and all the symbols are in libc as well, and we already have libc’s address. Can't we somehow escape/eliminate these ROP gadgets when building libc? BSD implemented a "RETGUARD" in clang for x86. IIRC, a lot of protection was offered by just tweaking register allocations. Don't/can't we have something similar for ARM?

saagarjha 8y ago
ARM 8.3’s pointer authentication might be what you’re looking for. Certain processors, notably Apple’s A12 chips, already implement this as a preventive measure against ROP.
- wyldfire 8y ago
  It's not [what I'm looking for], but it's a great step forward, for sure. It should reduce/eliminate the buffer overflows/use-after-frees that could be used to kick off ROP, but AFAIK it doesn't eliminate the gadgets themselves.
  - saagarjha 8y ago
    The point of pointer authentication is to make it impossible to actually user gadgets because you would be hard-pressed to find a signed pointer that is necessary to actually jump to a arbitrary location, since you’d be missing the one that was handed out to you in the prologue had you gone the correct way through the function. I guess in a way it’s a type of CFI check. With regards to actually stopping buffer overflows or double frees, it’s not going to help much. But we have other mitigation techniques, such as stack cookies, to help in these cases.
    - wyldfire 8y ago
      Oh I confused pointer auth with the newer ARM MTE [1]. That (nearly) eliminates use-after-free/buffer-overflow. [1] https://community.arm.com/processors/b/blog/posts/arm-a-profile-architecture-2018-developments-armv85a https://community.arm.com/processors/b/blog/posts/arm-a-prof...
- pjmlp 8y ago
  As an additional note, SPARC supports a similar feature for pointer validation and bounds checking in hardware. Intel apparently is going in the opposite direction by removing MPX from their future CUPs.
  - pcwalton 8y ago
    Because MPX is a terrible feature that no compiler vendor knows how to make use of. By contrast, ARM PAC is relatively simple and obvious in operation. Killing MPX is the right decision.
    - pjmlp 8y ago
      I trust your experience, having only read papers about it. But then I would expect the feature to be replaced by something else instead of being dropped as such. Solaris with SPARC pointer validation turned on is a much secure platform in spite of being written in C.

saagarjha 8y ago

ARM 8.3’s pointer authentication might be what you’re looking for. Certain processors, notably Apple’s A12 chips, already implement this as a preventive measure against ROP.

wyldfire 8y ago
It's not [what I'm looking for], but it's a great step forward, for sure. It should reduce/eliminate the buffer overflows/use-after-frees that could be used to kick off ROP, but AFAIK it doesn't eliminate the gadgets themselves.
- saagarjha 8y ago
  The point of pointer authentication is to make it impossible to actually user gadgets because you would be hard-pressed to find a signed pointer that is necessary to actually jump to a arbitrary location, since you’d be missing the one that was handed out to you in the prologue had you gone the correct way through the function. I guess in a way it’s a type of CFI check. With regards to actually stopping buffer overflows or double frees, it’s not going to help much. But we have other mitigation techniques, such as stack cookies, to help in these cases.
  - wyldfire 8y ago
    Oh I confused pointer auth with the newer ARM MTE [1]. That (nearly) eliminates use-after-free/buffer-overflow. [1] https://community.arm.com/processors/b/blog/posts/arm-a-profile-architecture-2018-developments-armv85a https://community.arm.com/processors/b/blog/posts/arm-a-prof...
pjmlp 8y ago
As an additional note, SPARC supports a similar feature for pointer validation and bounds checking in hardware. Intel apparently is going in the opposite direction by removing MPX from their future CUPs.
- pcwalton 8y ago
  Because MPX is a terrible feature that no compiler vendor knows how to make use of. By contrast, ARM PAC is relatively simple and obvious in operation. Killing MPX is the right decision.
  - pjmlp 8y ago
    I trust your experience, having only read papers about it. But then I would expect the feature to be replaced by something else instead of being dropped as such. Solaris with SPARC pointer validation turned on is a much secure platform in spite of being written in C.