Would ISRG consider funding "Sanitized Linux" which makes Linux memory safe using Google's Address Sanitizer? Here's my proposal: justine.lol/asanlinux/inde
Conversation
The main issue with ASan for bounds checking is that while it prevents a linear overflow such as with memcpy or strcpy, it doesn't prevent a non-linear overflow from reading or writing from another valid allocation. As you point out, it's based on tracking accessible memory.
1
For use-after-free, double-free, etc. it depends on a quarantine with a limited size. This can be scaled based on the amount of memory that you're able to accept using. The same kind of protection can be protected via a malloc implementation without the same kind of overhead too.
1
An attacker that's exploiting a vulnerability couldn't exploit a linear overflow. However they can still exploit a non-linear overflow and could often still exploit a use-after-free, which are the main 2 sources of memory corruption bugs. Linear overflows are way less common now.
Memory tagging is an alternative approach available via arm64 MTE or via HWAsan which uses arm64 TBI (Top Byte Ignore) which has been available for a long time on arm64 unlike the bleeding edge MTE not available in practice:
source.android.com/devices/tech/d
This catches non-linear too.
2
1
Memory tagging has a 1/256 chance not to catch a generic heap memory corruption bug. Could still use redzones to catch 100% of linear overflows. Normal ASan won't catch intentional non-linear overflows, i.e. actual exploits, because they'll target a valid allocation.
1
Show replies