4 ms·
Blocking 15 out of 16 exploit attempts sounds great, but you have to ask yourself how many shots you get, and since most people don't think "this program crashe
by saurik 6y ago
Blocking 15 out of 16 exploit attempts sounds great, but you have to ask yourself how many shots you get, and since most people don't think "this program crashed: I should never run it ever again", this isn't anywhere near as helpful as it seems. If you crash my webserver, I spawn a new one. You might even already have 16 webservers running right now! If the user clicks a link and their tab crashes, they might hit reload a few times before giving up. If you receive a text message or an email that crashes a parser on your phone, the retry might seriously happen in a tight loop. Like, I hear about this sort of thing being a good idea constantly, but I have never once heard of it actually blocking an attack against any "normal" target (I say "normal", as some super hardened military target might be configured to go into complete lockdown immediately upon a single unexpected event, with a protocol to call in a forensics expert to analyze logs to see if it is safe to restart the service before ending the outage).
- eyalitki 6y agoWe can detect corruption in 15/16 times. In our tests, when we didn't detect a corruption, the program still crashed, but without a proper error message. One should remember that the pointer is masked, so an attacker without the secret mask won't be able to control the reveal()ed pointer. And using a garbled pointer won't give the attacker anything useful, and most probably it will crash the target program.
- mywittyname 6y agoAre you saying the technique is effective at preventing a successful attack nearly every time, but that pointer modification are detected (thus logged) 15 out of 16 times?
- eyalitki 6y agoYes. We have 12 bits masking just the lower page, in addition to more than 10 bit above that. Chances to guess that correctly are VERY slim.