,
18 tweets,
4 min read
Read on Twitter
Tweetstorm on mitigations. When we talk about mitigations we often conflate security with the economics of security. What I mean with that a secure system is one that gives guarantees on the CIA properties. Full stop.
If we talk about attacker cost we are talking about the economics of vulnerabilities. Mitigations can target one or the other or both of these types.
If mitigation is purely economic in nature (@HalvarFlake calls it raising the bar) we will see supply trying to meet demand by the development of new techniques. If new techniques are found the gains disappear. Thus, security effects are likely to be short term only.
Even worse they come with risks and long term effect might be a net negative.
So how do we recognize good mitigation? I believe it was @benhawkes suggested a model that boils down to a prioritized list: Killing bug classes, killing bugs, making exploit chains longer, ... I'm don't disagree with this model, but my thinking is different.
I think security is about the state space available to an attacker. In the remainder of this tweetstorm I'll categorize mitigations based on their effect of the state space available to an attacker.
If states, where CIA are compromised, are reachable then the system isn't secure. This is where weird machines come in. We can argue that if there are no transitions from desired states to weird states we also cannot reach states that compromise security.
The instanciated state machine is the intended state machine in @halvarflake's wonderful paper on the subject. Thus, mitigations that prevent these state changes are aimed directly at the problem and thus will benefit security long term.
An example of mitigation in this category is the deprication of unsafe string operations or automated zero'ing of structures on the stack by compilers.
Another class of mitigation is mitigation that aims at reducing the number of weird states in the hope that states with security impact become unreachable or eliminated. Consider NX mitigation. It allows developers/operating systems to clearly limit the number of weird states.
@solardiz quickly punched holes in it, yet I will argue that the mitigation has been successful, not because it made exploits more difficult, but because it limits the state space and it opens up for things like CFI which is another mitigation in this category.
In this fashion, we can slowly chip away the weird part of the state space and hopefully chip away at exploitability.
Because these mitigations are more of a shotgun approach to mitigation we should be less enthusiastic than for the previous category and consider trade-offs more carefully. My final category is mitigations that do not change the state space.
These are mitigations that don't change what is possible for an attacker but only makes things more difficult. The classic here is randomization. Things like Information hiding and (K)ASLR fall in this category. These are the security of economics mitigations.
Any exploit that was possible before the mitigations are possible after. They trigger new research and become more or less obsolete, but have remaining added complexity, etc. @fjserna's wonderful "Info-leak era on software exploitation" is horribly accurate.
Also, note the sheer number of techniques for KASLR breaks that have been developed.
@vu5ec did work on information hiding and found it horrible vulnerable etc. Every mitigation of cause comes with complexity, risks, performance implications, etc. and we must consider those too before deploying mitigations.
Some ideas are great but turn out to be impractical to implement in a strong version (see for example @josephbialek's wonderful talk from Offensive Con 2017 - especially the part about issues implementing CFI on the backward edge). </Tweetstorm>
