hardening the net: building a new platform for security

04/22/2023The Harris Institute for Assured Information

1

Hardening the net: Building a new platform for security

Dr. Richard Ford ([email protected])Dr. Marco Carvalho ([email protected])

04/22/20232 The Harris Institute for Assured Information

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???


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)


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)

04/22/2023The 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?


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


Our Imaginary Architecture Let’s play “Hack along with Richard” Features were selected based on synergy not

based on “everything we could find”!


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


Hardware support for Security In-hardware random number source

Suddenly a lot of crypto weaknesses go away… hardware RNGs are pretty inexpensive now


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


Boot Sequence

POWER ON SELF TEST – BOOT PHASE

0LOAD BIOS SUPPORT BUILD C Compiler

from PROM

Restart in Randomized Mode

BUILD RANDOMIZED MICROKERNELLOAD FRAMEWORK

LOAD CONTROL APPLICATION(S)

ENTER UTILITY RUNLEVEL

HARDWARE RNG


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 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?


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…


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


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…)


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)


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


Commercial Applications? From xkcd (source: http://xkcd.com)


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


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


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.

hardening the net: building a new platform for security

Documents

assured informationchallenges

assured informationlets

assured information5what

system system

new platform

binary architecture

modified harvard architecture

harvard architecture