Software security V.S Hardware security

Question

In theory, perfect software applications are possible but in real life, they don't exist. When attackers know the software, they can send payloads to exploit vulnerabilities and run any arbitrary code they want remotely. On the other hand, we have HSM (Hardware security modules), for example we program smart cards to execute basic codes (e.g cryptographic algorithms) which is attack free without physical access to chip. Questions:

• Is it possible to use a chip based system -as cheap as raspberrypi- and make it run complex codes -maybe a basic browser- to check emails without worrying about malicious code?
• Is it possible to create a compiler which randomizes codes -maybe a browser on netbsd- to execute functions in many different ways for each user so when attackers discover vulnerabilities on public code, they can't exploit users who have random compiled versions?

Answer 1

Hardware security modules

Running code in a physically-protected chip such as a HSM or a smartcard is not about protecting from software bugs. If there's a software bug in a HSM, it can be exploited just as any webserver, laptop, smartphone, whatever. The difference between a HSM and a PC is that with physical access to a PC, you can just boot from a USB stick or swap out the disk. With physical access to the outside of an HSM, you still have to break in, and HSMs are designed to self-destruct when you make a serious attempt at opening them.

Running a browser on a Raspberry Pi

A PC is a “chip-based system” as much as a Raspberry Pi. There's no fundamental difference between them: a Raspberry Pi isn't somehow “more secure” than a PC.

More people use PCs, so PCs are a more valuable target to exploit, so more people try to exploit PCs. PCs also have a heavy burden of historical compatibility and a large variety of software, which puts them somewhat more at risk. But if people routinely ran browsers on Pis instead of Pentiums, there'd be more exploits out there for Pis.

Moving the browser to a different machine isolates it. But what do you gain? A lot of exploits are delivered through the browser. Often the browser itself is the target. It has access to the network, so it's a valuable target to spread the infection to other machines. It's how the user interacts with a lot of things, so it's a prime target for thieves and scammers. No matter where you put your browser, if it's infected, you've lost.

Randomizing code

Randomizing code in some way is a defense technique, but it only makes exploits harder, it doesn't make them impossible.

For example, some modern operating systems practice address space layout randomization: each time a program starts, it's loaded at a different random address. This means there are things you can't do in an exploit, such as refer directly to the address of a piece of code in the original program. It doesn't make exploits impossible: there has to be a way the program can find its own pieces (for example, a short relative jump will keep working just fine), and if some piece is hard to find the exploit can search for it (it's a common issue even without ASLR because often the exploit code itself will be loaded at an unpredictable address).

Randomizing code in the compiler wouldn't buy you much, and it's expensive. All these forms of randomization make debugging harder. If you randomize before distributing the program, you have to manage the distribution and maintenance (updates) of all these different versions. And security-wise the benefit it minimal because in the end the program still has to do the same thing.

How hardware helps with security

For run-of-the-mill systems (not HSMs and the like), the role of the hardware is to enforce isolation between components. It's a hardware component, the MMU, that makes it impossible for a program to directly access another program's memory. The CPU design also makes it impossible for ordinary programs to directly access hardware peripherals, they have to go through operating systems interfaces for that. The hardware has to be used correctly: it's up to the operating system to set up the MMU tables correctly and so on.

You can't put too much intelligence into the hardware. The more you do, the more there's a risk that there'll be a bug in your design. Hardware bugs are pretty hard to fix. So the hardware provides some basic capabilities, and the complexity is handled in software as much as possible.

Answer 2

@vulner, I think you're indirectly trying to ask if a Harvard architecture is inherently more secure than a Von Neuman architecture. (A Harvard architecture has separate memory for instructions and data, while a Von Neuman machine uses shared memory for both purposes.)

One attack where a Harvard machine could be more secure is in a buffer overrun. Even if the application makes a mistake and overwrites application memory due to a buffer overrun, the app pointers may not have physical access to stack memory, and therefore it wouldn't be possible to perform a classic stack-smashing attack.

But that's not the only security problem you'll find on the web. The problem with a browser's security is not just in the machine architecture. The problems are that the browsing application processes untrustworthy information that is interpreted both as data and instructions, and that the browser is capable of retaining state.

Consider a script (untrustworthy source) that I might post here in stackexchange that places what looks like a fake advertisement for your bank in the right hand column. Your browser has no idea whether or not that's legitimate data, but if you type your bank username and password in it, you'll quickly find out.

Or consider a javascript (interpreted instructions) that steals cookie information. If I'm running a malicious WiFi access point, I could inject a javascript at the bottom of the www.google.com home page that sends me every data you post, and every cookie you receive. I could modify the cache time to say "keep this page and script in the cache for a year." (stored state) And the script could add itself to the bottom of every new page you visit through that cached google page. Only clearing your browser's cache would get rid of it.

Your chip-based-browser could stop one specific kind of attack, but you would provide a false sense of security due to all the other attacks out there.