There appears to be a distaste towards attack papers in the architecture and the systems community. Based on talking to a statistically insignificant sample of colleagues, we get the sense that attacks are considered brutish and not constructive. There also appears to some confusion about the how attack work should be evaluated. We have heard more than one respected researcher say things along the following lines: “They found a bug? Is this really computer science/engineering?!”
In this blog post we will discuss the importance of attack research through examples and we will also lay out a framework for thinking about attack research.
Let us begin with the obvious question: Why research and demonstrate attacks? We motivate computer architecture research by referring to technology trends and/or changes in programming models and methods. We motivate defensive work in security by referring to real and anticipated risks. Identification of risks is, thus, a key part of security research. Typically risks are assessed by conducting “attacks”, which, roughly speaking, give us a way to understand the factors influencing risk.
Now some samples of recent attack research. Consider the example of remote car hacks. Published in the early part of this decade, researchers have shown how attackers can, via the cars’ built-in Internet-connected components, take control of core vehicle functionalities such braking or opening the car doors. While the attack vector – exploiting buffer overflow to gain control (“a bug”) – is not entirely novel, the paper highlights a design principle that the car manufacturers have grossly neglected: the cars’ core control circuits should be kept separate from the Internet-connected ones. The work clearly has had significant impact in terms of improving vehicle security architectures as evidenced by cyber security improvements in newer vehicles.
Next let us consider an attack paper of a different kind: one that doesn’t exploit a latent vulnerability but shows how a vulnerability can be created in the first place. In a paper that appeared in IEEE Security and Privacy conference in 2016, researchers showed how to create an analog backdoor on a chip. This attack was demonstrated on a taped out chip, and was a call to action to investigate solutions for this dangerous type of backdoor. These type of attack papers, ones that explore new vulnerabilities are extraordinarily valuable as they allow defenders to understand future attacks, and potentially prevent them from happening by creating appropriate defenses.
Our last example is our recent work, the CLKscrew attack, that we demonstrated in USENIX Security 2017. We showed how the DVFS mechanisms on a commodity chip/architecture can be manipulated to break the root of trust in these devices. We disclosed the attack to the vendors before the publication of the paper and they are currently working towards mitigations for current and future chips. Similarly, in CCS 2015, we showed how microarchitectural side channel attacks can be carried out remotely through a web browser which resulted informing standards and mitigations in several major browsers. Notably this mitigation approach was suggested as potential fix in an earlier ISCA 12 paper. These two examples underscore the importance of attacks to getting defenses implemented and shipped: in both cases the vulnerability impacted millions of devices and users, and mitigations will reach, or have already, reached a very large number of users.
To be clear, just like regular architecture and systems papers, attack research work ranges from trite, to highly original and impactful. The more interesting papers usually score high on some of the factors below.
Novelty: A novel attack paper would expose a new class of vulnerability. Some examples of attacks that expose new classes of vulnerabilities are the exploitation of memory safety vulnerability (specifically buffer overflows) in 1988 for the Morris worm, Differential power analysis attacks on smart cards in the 90s, and the first microarchitectural side channel attacks in 00s. Discovery of a completely new vulnerability classes, or even sub classes, are obviously very rare events.
Requirements: Attacks that require little access and/or low investment (from the point of view of attackers) are likely to be more widespread. For instance, for mass attacks, attacks that can be executed remotely may be considered more desirable than attacks that need local access; similarly, attacks that can be applied quickly and with little preparation are, generally speaking, more desired. Thus, advancement in optimizing attack requirements towards reducing the amount of access, or reducing time are valuable.
Automation: An aspect closely related to access is the ability to automate vulnerability discovery and exploitation. To date, most attacks tend to be manual heroic efforts with little automation (just like computer architecture prototyping). It remains an open question if automatons can discover and deploy attacks: discovery of vulnerabilities and attack engineering requires a level of creativity that may be hard for machines to match.
Impact: Even if the attack does not meet any of the above criteria, if the attack has large scale impact and raises awareness of security issues it could be extraordinarily valuable (e.g., car hacks). On the other hand, if the attack ends up leaking information that is already publicly known, it is, obviously not interesting.
Pedagogy: A valuable security attack can also be a great educational tool to help learn about the nitty gritty engineering details of systems, and in this way it is similar to the benefits of prototyping chips in computer architecture. A good attack paper will have enough details to teach students about the attack and perhaps repeat the attack on different systems.
Ethics: Good attack papers also disclose vulnerabilities responsibly. It is important to give the affected industry vendors or developers some time to address the issue before publishing the attack. Also some (tasteless) attack papers indulge in juvenile chest-thumping; fortunately, this is not pervasive in academic security conferences but it is always good for authors of these works to explicitly ask if statements made in their papers will lead to constructive dialogue and fixes.
The above list is not meant to be comprehensive. Determination of what is really a good attack also have to take into account contextual information such as how does the specific attack compromise full-system security and usability.
We hope you are convinced that making and breaking are equally vital for securing systems and that we would do better if we supported breaking activities in our community.
About the Authors: Simha Sethumadhavan is an associate professor in the Computer Science Department at Columbia University. His research interests are in computer architecture and computer security. Adrian Tang is a PhD candidate in Computer Science at Columbia University. His research explores security as a full-system property by scrutinizing the interplay between hardware and software in the computing stack.
Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.
