Hard-Object: Enforcing Object Interfaces Using Code-Range Data Protection

CS 261 - Course Project
Last Updated: October 28, 2009
Developers:
(In Class)
Kevin Klues (klueska@eecs.berkeley.edu)
Derrick Coetzee (dcoetzee@eecs.berkeley.edu)
(Not in Class)
Daniel Wilkerson
Mark Winterrowd
John Kubiatowicz

Overview

Hard-Object is a lightweight hardware/software system for enforcing code-range data protection, first described in a July 2009 white paper "Hard-Object: Enforcing Object Interfaces Using Code-Range Data Protection" by Daniel Wilkerson et al at University of California, Berkeley [1]. Programs are organized into modules, each of which provides services through a function call interface and maintains private state; common examples of modules are abstract data types in C and objects in C++ and Java. Each module is responsible for maintaining invariants of its private data; Hard-Object provides a safety guarantee for these invariants by preventing modules from reading or writing memory owned by other modules. This guarantee is enforced by a combination of hardware enhancements, which monitor every memory access to ensure that every data page is accessed only by the code range that owns it, and software checks, which ensure that inter-module calls are performed safely. Many important security scenarios are special cases of this, including sandboxing untrusted code such as plug-ins.

However, Hard-Object as described in the original white paper was incompletely implemented and as such had an unrealistic evaluation. The goal of this project is to expand on the implementation in a targeted way intended to produce a more convincing evaluation of the practical performance and security characteristics of the system on real-life applications. Specifically, we plan to (1) implement a complete backend C-compiler generating Hard-Object aware assembly code, and (2) implement a full working version of the hardware extensions required by Hard Object inside PTLSim, a cycle-accurate x86 simulator. After we have these in place we will be able to perform more realistic evaluations of Hard-Object and measure its pperformance and security benfits more accurately.

Evaluation Plan

We will identify a single mature, widely-used application with known security issues, such as the Apache web server. The application will be refactored to isolate modules and prevent excessive inter-module communication. Modules will be initially defined coarsely as subsystems that need to operate at different privilege levels, such as the core web server and server-side scripting engines. Module granularity may be one of the parameters we seek to investigate. The application will be evaluated in several different setups:
  • Run the unmodified application, compiled with gcc, on unmodified hardware (control case).
  • Compile with the Hard-Object compiler and with gcc (with optimizations) to isolate the effect of the compiler choice.
  • Run the unmodified application as a single module on the Hard-Object hardware to the cost of hardware and software components of the system.
  • Run the componentized Hard-Object application on the Hard-Object hardware.
We then plan to evaluate each setup according in terms of both its performance costs as well as how effective it was at preventing the introduction / exploitation of security bugs.
Performance will be evaluated using the following metrics for three types of applications:
  1. Benchmarks (end-to-end runtime, memory usage)
  2. Web server (throughput, latency, memory usage)
  3. Contrived examples designed to maximize/minimize the performance of applications written for hard object
It is not 100% clear how we will evaluate Hard-Objects ability to mitigate the introduction / exploitation of security bugs. Our initial plan is to run applications with known security bugs through the Hard-Object system and see if / how they are caught.
However, some unanswered questions we still have include:
  1. How does the running system actually deal with faults?
  2. To what degree were the bugs mitigated by Hard-Object?
  3. What types of things can't hard object help with?
We hope to have some set of clear answers to these and other qestions by the time we complete this project.

References

[1] Daniel Wilkerson, David Alexander Molnar, Matthew Harren, and John D. Kubiatowicz. Hard-Object: Enforcing Object Interfaces Using Code-Range Data Protection. EECS Department, University of California, Berkeley. Tech Report UCB/EECS-2009-97. July 2009.
http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-97.html

[2] Common vulnerabilities and exposures.
http://www.cve.mitre.org/

[3] United states patent and trademark office website.
http://uspto.gov/

[4] Website of Elsa, Oink, and Cqual++.
http://www.cubewano.org/oink

[5] Martin Abadi, Mihai Budiu, Ulfar Erlingsson, and Jay Ligatti. Control-flow integrity: Principles, implementations, and applications. In ACM Conference on Computer and Communications Security, November 2005.

[6] M. Accetta, R. Baron, W. Bolosky, D. Golub, R. Rashid, A. Tevanian, and M. Young. MACH: a new kernel foundation for UNIX development. In Proc. Summer USENIX, 1986.

[7] David Brumley and Dawn Xiaodong Song. Privtrans: Automatically partitioning programs for privilege separation. In USENIX Security Symposium, pages 57-72. USENIX, 2004.

[8] G. Candea and A. Fox. Recursive restartability: Turning the reboot sledgehammer into a scalpel. In Workshop on Hot Topics in Operating Systems (HotOS), 2001.

[9] G. Candea, S. Kawamoto, Y. Fujiki, G. Friedman, and A. Fox. Microreboot - a technique for cheap recovery. In Symposium on Operating Systems Design and Implementation (OSDI), 2004.

[10] S. Chen, J. Xu, E. C. Sezer, P. Gauriar, and R. K. Iyer. Non-control-data attacks are realistic threats. In Usenix Security 2005, pages 177-192, 2005.
http: //www.usenix.org/events/sec05/tech/chen.html

[11] J. R. Crandall and F.T. Chong. Minos: Control data attack prevention orthogonal to memory model. In IEEE MICRO, 2004.

[12] P. Efstathopoulos, M. Krohn, S. VanDeBogart, C. Frey, D. Ziegler, E. Kohler, D. Mazieres, F. Kaashoek, and R. Morris. Labels and event processes in the asbestos operating system. In 20th Symposium on Operating Systems Principles, 2005.

[13] P. Efstathopoulos, M. Krohn, S. VanDeBogart, C. Frey, D. Ziegler, E. Kohler, D. Mazieres, F. Kaashoek, and R. Morris. Making least privilege a right, not a privilege. In HotOS, 2005.

[14] Nozue et al. United states patent 5,890,189, Mar 30, 1999.

[15] T. Garfinkel, B. Pfaff, J. Chow, M. Rosenblum, and D. Boneh. Terra: A virtual machine-based platform for trusted computing. In Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP), 2003.

[16] S. Gorman. Overview of the protected mode operation of the intel architecture, 2005.
http://www.intel.com/design/intarch/papers/exc_ia.pdf

[16] E. Hamilton. Response to comp.sys.hp.hpux message 'SEVERE performance problems with shared libraries at HP-UX 9.05', November 1995.
http://groups.google.com/group/comp.sys.hp. hpux/msg/184b16c53b99511a?hl=en&

[17] H. Hartig, M. Hohmuth, J. Liedtke, S. Schonberg, and J. Wolter. The performance of u-kernel-based systems. In 16th Symposium on Operating Systems Principles (SOSP), 1997.

[18] Matthew Hertz and Emery D. Berger. Quantifying the performance of garbage collection vs. explicit memory management. SIGPLAN Not., 40(10):313-326, 2005.

[19] V. Kiriansky, D. Bruening, and S. Amarasinghe. Secure execution via program shepherding, 2002.

[20] E.J. Koldinger, J.S. Chase, and S.J. Eggers. Architectural support for single address space operating systems. In Architectural Support for Programming Languages and Operating Systems (ASPLOS) V, pages 175-186, 1992.

[21] G.C. Necula, J. Condit, M. Harren, S. McPeak, and W. Weimer. CCured: Type-safe retrofitting of legacy software. ACM Transactions on Programming Languages and Systems (TOPLAS), 2005.

[22] G.C. Necula, S. McPeak, S.P. Rahul, and W. Weimer. CIL: Intermediate language and tools for analysis and transformation of c programs. In Conference on Compiler Construction, 2002.

[23] T. Okamoto, H. Segawa, S. H. Shin, H. Nozue, Ken ichi Maeda, and M. Saito. A micro-kernel architecture for next generation processor. In Proceedings of the Workshop on Micro-kernels and Other Kernel Architectures, pages 83-94, Berkeley, CA, USA, 1992. USENIX Association.

[24] David Patterson, Aaron Brown, Pete Broadwell, George Candea, Mike Chen, James Cutler, Patricia Enriquez, Armando Fox, Emre Kiciman, Matthew Merzbacher, David Oppenheimer, Naveen Sastry, William Tetzlaff, and Noah Treuhaft. Recovery oriented computing (ROC): Motivation, definition, techniques, and case studies. In UC Berkeley Computer Science Technical Report UCB/CSD-02-1175, Berkeley, CA, March 2002. U.C. Berkeley.

[25] N. Provos, M. Friedl, and P. Honeyman. Preventing privilege escalation. In 12th USENIX Security Symposium, 2003.

[26] Trygve Reenskaug. Thing-model-view-editor: an example from a planningsystem, May 12, 1979. Internal document at Xerox PARC.

[27] M. I. Seltzer, Y. Endo, C. Small, and K. A. Smith. Dealing with disaster: Surviving misbehaved kernel extensions. In Proceedings of the 2nd Symposium on Operating Systems Design and Implementation, pages 213-227, Seattle, Washington, 1996.

[28] M. Swift, B. Bershad, and H. Levy. Improving the reliability of commodity operating systems, 2003.

[29] M.M. Swift, B.N. Bershad, and H.M. Levy. Improving the reliability of commodity operating systems. ACM Transactions on Computer Systems, 22(4), November 2004.

[30] MITRE Common Vulnerabilities and Exposures List. CVE-2001-0559. vixie cron vulnerability., 2001.

[31] Robert Wahbe, Steven Lucco, Thomas E. Anderson, and Susan L. Graham. Efficient software-based fault isolation. ACM SIGOPS Operating Systems Review, 27(5):203-216, December 1993.

[32] Daniel S. Wilkerson and John D. Kubiatowicz. Hard Object: Hardware protection for software objects, 2008. United States Patent Application number 12/045,542, publication number US-2008-0222397-A1.

[33] Emmett Witchel. Mondriaan Memory Protection. PhD thesis, MIT, 2004.

[34] Emmett Witchel and Krste Asanovic. Hardware works, software doesn't: Enforcing modularity with mondriaan memory protection. In 9th Workshop on Hot Topics in Operating Systems (HotOS-IX), Lihue, HI, May 2003.

[35] Emmett Witchel, Josh Cates, and Krste Asanovic. Mondrian memory protection. In ASPLOS-X: Proceedings of the 10th international conference on Architectural support for programming languages and operating systems, pages 304-316, New York, NY, USA, 2002. ACM Press.

[36] P. Zhou, W. Liu, L. Fei, S. Lu, F. Qin, Y. Zhou, S. Midkiff, and J. Torrellas. AccMon: Automatically detecting memory-related bugs via program counter-based invariants. In IEEE MICRO, 2004.

[37] P. Zhou, F. Qin, W. Liu, Y. Zhou, and J. Torrellas. iWatcher: Efficient architectural support for software debugging. In International Symposium on Computer Architecture ISCA, 2004.

[38] P. Zhou, F. Qin, W. Liu, Y. Zhou, and J. Torrellas. iWatcher: Simple and general architectural support for software debugging. IEEE Top Picks in Computer Architecture, 2004.