Abstract not found

Many remote attacks against computer systems inject binary code into the execution path of a running program, gaining control of the program's behavior. If each defended system or program could use a machine instruction set that was both unique and private, such binary code injection attacks would become extremely difficult if not impossible. A binary-to-binary translator provides an economic and flexible implementation path for realizing that idea. As a proof of concept, we describe a randomized instruction set emulator (RISE) based on the open-source Valgrind x86-to-x86 binary translator. Although currently very slow and memory-intensive, our prototype RISE can indeed disrupt binary code injection attacks against a program without requiring its recompilation, linking, or access to source code. We describe the RISE implementation, give evidence demonstrating that RISE defeats common attacks, consider consequences of the dense x86 instruction set on the method's effects, and discuss limitations of the RISE prototype as well as design tradeoffs and extensions of the underlying idea.

We present a practical protection mechanism against SQL injection attacks. Such attacks target databases that are accessible through a web frontend, and take advantage of flaws in the input validation logic of Web components such as CGI scripts. We apply the concept of instruction-set randomization to SQL, creating instances of the language that are unpredictable to the attacker.

Defcon's Capture the Flag (CtF) game is the largest open computer security hacking game. This year's CtF hat rules that made it particularly difficult to be a successful defender. We entered an Immunix server, comprised of five years of IA&S, OASIS, FTN, and CHATS technologies, to see whether this system could survive sustained attack from determined experts. We describe our experience surviving Defcon CtF.

Fixing software bugs has always been an important and timeconsuming process in software development. Fixing concurrency bugs has become especially critical in the multicore era. However, fixing concurrency bugs is challenging, in part due to nondeterministic failures and tricky parallel reasoning. Beyond correctly fixing the original problem in the software, a good patch should also avoid introducing new bugs, degrading performance unnecessarily, or damaging software readability. Existing tools cannot automate the whole fixing process and provide good-quality patches. We present AFix, a tool that automates the whole process of fixing one common type of concurrency bug: single-variable atomicity violations. AFix starts from the bug reports of existing bugdetection tools. It augments these with static analysis to construct a suitable patch for each bug report. It further tries to combine the patches of multiple bugs for better performance and code readability. Finally, AFix’s run-time component provides testing customized for each patch. Our evaluation shows that patches automatically generated by AFix correctly eliminate six out of eight real-world bugs and significantly decrease the failure probability in the other two cases. AFix patches never introduce new bugs and usually have similar performance to manually-designed patches.

The purpose of this research paper is to illustrate the industrial and federal need for Information Systems Security Engineering (ISSE) in order to build Information Assurance (IA) into a system rather than the current costly practice of fixing systems after production. Extensive research was performed by collecting information from throughout the World Wide Web to include sites such as the National Security Agency’s Homepage, the Information Assurance Technical Framework Homepage, the

This panel addressed the use of computer diversity as a strategy for computer security. It is our view that there are significant knowledge gaps in the science underlying diversity as a computer defense mechanism which hinders its usefulness. These gaps include the true cost of diversity, a lack of metrics for diversity and the trade offs between diversity and other defensive strategies. We also wanted to highlight on-going diversity research from other disciplines which could potentially be applied to diversity for computer security. Four panelists were selected based on their experience with diversity within the context of computer security or other research areas. The panelists ' backgrounds include biology, software reliability, security and dependable systems. Each panelist presented a statement which was discussed by NSPW participants. The discussion was lively and informative both during and after the panelists ' statements and is reported in a later section of this summary. 1.