In spite of being central to everything that is going on in IT security, the concept of “exploit” is surprisingly poorly formalized and understood only on an intuitive level by security practitioners. This lack of clear definition has all sorts of negative side-effects: From ineffictive teaching to muddled thinking about mitigations. In this talk, I will make an attempt to more clearly define what it is that attackers do when they write an exploit – and then talk about what this means for mitigations and secure coding.

The concept of exploit is central to computer security, particularly in the context of memory corruptions. Yet, in spite of the centrality of the concept and voluminous descriptions of various exploitation techniques or countermeasures, a good theoretical framework for describing and reasoning about exploitation has not yet been put forward. A body of concepts and folk theorems exists in the community of exploitation practitioners; unfortunately, these concepts are rarely written down or made sufficiently precise for people outside of this community to benefit from them. This paper clarifies a number of these concepts, provides a clear definition of exploit, a clear definition of the concept of a weird machine, and how programming of a weird machine leads to exploitation. The paper also shows, somewhat counterintuitively, that it is feasible to design some software in a way that even powerful attackers - with the ability to corrupt memory once - cannot gain an advantage. The approach in this paper is focused on memory corruptions. While it can be applied to many security vulnerabilities introduced by other programming mistakes, it does not address side channel attacks, protocol weaknesses, or security problems that are present by design.