Jann HornMar 3

I find stack overflow security bugs fascinating; and on Linux, compilers still don't protect against stack overflows by default when stack frames are bigger than stack guard pages.

So I went looking around in Android, and thanks to how Android's RPC mechanism allows recursive synchronous callbacks in some cases, I managed to find a way to jump a thread guard page in system_server from shell context and (with very low success rate) get instruction pointer control:
https://project-zero.issues.chromium.org/issues/465827985

Project Zero

Show threadlj·rkMar 3
@jann Lovely research! Underpins why one shouldn't underestimate compiler hardening flags!
Show threadJann HornMar 3
@ljrk Yeah, stack overflows in particular feel to me like the programmer isn't really making a particular mistake that can be called a security bug, it just randomly happens in legitimate code... and the only thing that can reliably stop it is the compiler. So it kinda feels wrong to me to call it a hardening flag, it feels more like a... correctness flag?
Show threadjannicMar 5
@jann @ljrk I wonder why it is still necessary to employ imperfect mechanisms like guard pages to avoid stack overflows. Shouldn't it be possible to have a stack pointer limit checked by hardware? Like https://interrupt.memfault.com/blog/using-psp-msp-limit-registers-for-stack-overflow on some ARM chips?
A Guide to Using ARM Stack Limit Registers

A community and blog for embedded software makers

Interrupt
Show threadlj·rk

@jannic @jann Yes, but turning this one is trickier in two ways:

1. Some of these features still require compiler hardening flags to work/wiring
2. It's sometimes harder to selectively enable, which can pose problems if programs suddenly stop working, especially 3rd party apps.

Generally though yes, this would be a good approach. GrapheneOS makes use of such hardware features much more aggressively for example!

Mar 5 at 8:25amWeb