Security Analysis of Executable Code
Motivation
Binary code is everywhere. In most situations, users only have access to code in binary (i.e., executable) form. Most common, off-the-shelf (COTS) software (e.g., Microsoft Windows, Adobe Acrobat, etc.) is only available to end-users in binary form. Malicious code (i.e., malware) created by attackers is typically only available in binary form. The ubiquity of binary code means any security techniques that only require access to the program binary are likely to be widely applicable. Further, binary code analysis allows us to argue about the security of the code that will run, not just the code that was compiled. However, there are many challenges challenges to performing accurate and faithful analysis on modern binary code. One challenge is that code analysis at the binary level is different than source code because binary code lacks many abstractions found in higher-level languages. While source code has user-defined types, functions, and buffers, binary code has no types, a single byte-addressable memory, and no functions. A second challenge is that binary code is significantly more complex than source code, which introduces new engineering challenges for binary code analysis. A typical line in source code may be a dozen instructions in binary code.Current Status
We are developing the next-generation Binary Analysis Platform). The goal of BAP is to facilitate faithful security-relevant binary program analysis by 1) reducing complex instruction sets to a single, small, and formally specified intermediate language, called BIL, that supports writing concise, easy-to-understand analyses 2) providing a set of core program analyses abstractions, and 3) being architecture independent when possible in order to support easy re-targeting.For more information, see the BAP website.
Conditional Privacy
Many modern network services have seemingly contradictory goals. On one hand, users are concerned about privacy and wish to remain anonymous for fear of their identities being misused. Service providers, on the other hand, need to have at least some form of accountability to stymie malicious and abusive users. Our work is focused on providing practical, inexpensive anonymous authentication so that both the user and the service providers know under exactly what conditions a user's identity will be revealed. We want our system to be easily applicable to general protocols and have a small trusted computing base (TCB).
Our system is based around the notion of contracts. When a user accepts a contract, their identity is placed in escrow on a server running Flicker to execute code with access to the identity in isolation on the server. Flicker allows the server to prove to both the user and service provider that the user's identity will be revealed by the server if and only if the client breaks the client. Because we avoid using computationally expensive cryptography, our system can be adapted to protocols that send messages at high rates. In addition, because the accountability server uses Flicker to attest to the conditions upon which identities will be revealed, the TCB contains only the small code that runs in isolation on the accountability server.