Hardening the net: Building a new platform for security

1. Hardening the net: Building a new platform for security Dr. Richard Ford (rford@fit.edu)Dr. Marco Carvalho (mcarvalho@ihmc.us) The Harris Institute for Assured Information

2. My talk: The Point • Let’s play a thought game: how could we build a new platform that is dramatically more secure. What might we learn in the process? • Doing this has led me to the following conclusion: • We know how to “do” security fairly well, but operational considerations get in the way • I’m NOT saying we should build this platform, I’m suggesting we examine it and think in the “big picture” • However, if we’re going to talk about hardening the ‘net let’s talk about what CAN be done, so we can decide what we WANT to do • The Big Question is why can we revisit the current problem in the context of optimization??? The Harris Institute for Assured Information

3. Challenges to Security • Multi-faceted – different solutions based on the levels of the system • Attacker wishes to: • Disrupt the process being executed • Take over an individual node for another attack • Exfiltrate information about the node or the user • Two foundational issues • Exploit low-level vulnerabilities (i.e. run code on the system) • Exploit design flaws on the system (system is working as designed… but it’s a bad design) The Harris Institute for Assured Information

4. Low-level vulnerabilities • Typically rely on understanding the binary architecture of the machine • Use the static nature of computing to their advantage • Buffer overruns on the stack • Buffer overruns on the heap • Malware (user mode) • Botnets/rootkits (subversion) The Harris Institute for Assured Information

5. Let’s Build a System From Scratch! • What would a system need to look like to provide considerably more security than today’s systems? The Harris Institute for Assured Information

6. Enabling capabilities • Can we create a machine that we can “trust” at the low level for certain functions, even if we do not trust individual processes? • i.e. Can we build a foundation that has known properties from which we can develop a framework? • Our intuition is yes, based on lessons learned from 30 years of security research • Why was MULTICS so secure? • What forces caused the erosion of this model? • Fixing the low-level vulnerabilities lets you reason about the higher-level issues safely • Essentially, we are trying to create a safe environment for monitoring/introspection The Harris Institute for Assured Information

7. Our Imaginary Architecture • Let’s play “Hack along with Richard” • Features were selected based on synergy not based on “everything we could find”! The Harris Institute for Assured Information

8. Harvard Architecture • Harvard Architecture • Dual stack – one for code, one for data • Stack grows upward • Reminder: a Harvard Architecture isn’t that weird. The Intel chipset is basically a modified Harvard Architecture – it’s all about a firm separation between code and data The Harris Institute for Assured Information

9. Hardware support for Security • In-hardware random number source • Suddenly a lot of crypto weaknesses go away… hardware RNGs are pretty inexpensive now The Harris Institute for Assured Information

10. Instruction Selection • Instruction set randomization at boot time • This might be new to some of you • Basic idea is machine boots into a mode where it dynamically reassigns opcodes to instructions. • Microkernel is cross-compiled for the new architecture and the system then changes state to the new platform • Removal of instructions that allow for code introspection The Harris Institute for Assured Information

11. Boot Sequence The Harris Institute for Assured Information

12. Microkernel Design • Registration of Function Pointers • The equivalent of “call eax” runs through the kernel • Highly-granular memory protection • malloc provides “gated” memory • Address space layout randomization • Higher-level analysis/interoception of behaviors • Defeats the “try every combination” attack • Process isolation • “The cake is a lie” – think about privileges and do them as a matrix not a ring series The Harris Institute for Assured Information

13. The trick is the combination • Alone, each of these technologies doesn’t help much • But combined, the approach begins to become quite robust to attacks • How can you inject code on a system you don’t know the opcodes for? • Consider worst-case scenario: attacker convinces us to compile “bad” source code… where do we go from here? • Aside: anyone notice how parts of this look like some of the malware packers around? The Harris Institute for Assured Information

14. Two exploits… • Return Oriented Programming • Nope, won’t work, as the platform breaks many assumptions • 1: You don’t know the location of anything • II: You can’t modify the control flow stack • III: You can’t jump to random code locations using a call (function registration) • Format String Attack • Nope, won’t work… • I: Control flow is separated from data • II: Even if you modify data, you don’t know where it is (unless it’s on the stack) • III: To modify control flow, you need to modify a function pointer, but these are all registered… The Harris Institute for Assured Information

15. Questions about the Platform • Can you run “normal” code? • Yes! • Our compiler compiles standard C and (bugs aside!) programs execute perfectly well • Can you actually make on of these things? • Yes – and we have! (Emulated – quote for “in silicon” is pricey) • Why a Harvard Architecture? • It’s not that different from the modern Intel architecture, actually • Probably we’ll end up with something similar to what we have… could go all the way if needed The Harris Institute for Assured Information

16. Weaknesses I • Primarily, this system imposes a large overhead for security… at which point it becomes an optimization problem! • Requires custom silicon plus a hardware RNG (cost) • Hard to prove there are no vectors to attack (formal methods may help) • Though our claim isn’t that it is hack-proof… at a minimum, an attacker could conceivably guess right on the first try • Requires software to be distributed in p-code (at a minimum… or source code) • This is a horrible scalability issue, though remember, Java is essentially p-code, so this can be done • However, this is also a strength, as we can implement the memory controls we want (think of ROP with gadgets…) The Harris Institute for Assured Information

17. Weaknesses II • Clearly, the compiler “knows” the magic mapping of opcodes • However, generating an attack that gets this out of the compiler is non-trivial (remember, the compiler is in the randomized architecture) The Harris Institute for Assured Information

18. Oh, and you can DO this too… • System up and running in emulated environment • Currently working on trap handling and higher level architecture • Created “end to end” proof of concept, with Linux/Emulated cross compiler • Working on designing experiments and getting informal red teaming from collaborators • Currently, we have no working code injection exploits (and we don’t know how to make one!) • Working hard to integrate at the higher levels • Exploring if you can “virtualize” such a machine on an Intel platform for “high security” applications The Harris Institute for Assured Information

19. Commercial Applications? • From xkcd (source: http://xkcd.com)  The Harris Institute for Assured Information

20. Why Not Use It? • Three cardinal laws: • Rule 1: Functionality always wins • Rule II: Functionality always wins… • Rule III: … • Clearly this isn’t a general purpose platform • We can have pretty robust security, and this provides guarantees from which we can develop resilience… • … but functionality issues (speed, function, looks (!), usability) get in the way • The way forward is to think hard about how to optimize the delivery of security information The Harris Institute for Assured Information

21. Hardening the ‘net, Redux • I think we have illustrated that we can have pretty secure computers • How to deploy the lessons learned when looking at next gen issues? • Even if we did deploy this, the challenge moves toward badly-designed software… but at least we can observe it safely • Think of the hardware/kernel as the “crumple zone” that protects the user from bad code • Not general purpose, but targeted to critical infrastructure The Harris Institute for Assured Information

22. Acknowledgement • Acknowledgments: This material is based upon work supported by the Department of Energy National Energy Technology Laboratory under Award Number(s) DE-OE0000511. • This paper was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor any agency thereof, nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights.  Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or any agency thereof.  The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or any agency thereof. The Harris Institute for Assured Information