Are security exploits a fatality? [closed]

Question

I'm asking this here and not on the security related site because this one is a question about "software architecture" and "development methodologies", which are both covered by the FAQ.

EDIT: I'm talking about purely remote root / admin software exploits. Not about insider physically breaking into labs / companies / houses / networks / machines.

Everytime there's a blog entry or article about a new security exploit there are lots and lots of people basically writing that: "No software shall ever be secure, every single software out there can be exploited. Give any pirate sufficient time and he'll eventually exploit any high-target software." This is a constant. These type of comments always get modded like crazy and most people seems to accept it as a fact.

And it really gets me wondering: can any software architecture and development methodologies be used to ever come up with secure software or is there something technical that prevents us from writing secure systems/programs/OSes/servers?

The more I think about it, the more I don't understand why we couldn't, technically, build 100% secure software. All the way down from the OS and then up: browsers, plugins...

Note that I'm not interested in a discussion here: I want to know if technically there is something or not that can prevent, say, an OS, to be written in a 100% secure way and why it's that way.

Now if there's nothing technically that prevents us from writing a 100% secure OS and from then writing a 100% secure server, why hasn't it been done? Does it means our architecture and development methodologies (and tools?) are deeply flawed?

Answer 1

No, it means that the world isn't secure. Software, like any other human endeavor, can be breached, circumvented, or otherwise done in. The question is not whether we can make it 100% but whether the security in place will slow the aggressor down/annoy him enough to make it temporally or economically unfeasible for him to bother whilst not making it economically or temporally unfeasible for us.

Software is not perfect because humans are not perfect.

Answer 2

It's the complexity that gets you: it's pretty easy to build a simple system that is 100% error-proof. The problem is, such system would not be very useful. As soon as you start piling up complexity, you start creating trouble.

Even the simplest web application requires interaction of many parts. Here is an oversimplified list:

• The OS of the client
• The browser on the client
• The network I/O library on the client
• The networking infrastructure of the client Internet provider
• The networking infrastructure on the way to your server's internet provider
• The networking infrastructure of the server's Internet provider
• The OS of the server
• The application server
• The network I/O library on the server
• Your server application

If you go deeper, you get more components: XML parsers, HTML renderers, image processing libraries, encryption libraries, database client libraries, RDBMS servers, disk I/O libraries, regular expression libraries, libraries for interacting with third-party components, and so on.

Now comes the bad part: a security problem in any of your multiple layer makes the overall system insecure. Let one component break - and the whole system comes down. Let's say each of your many components is 99.9% reliable - that's between "very good" and "incredible". Let's suppose that your system is composed of thirty such very reliable components. The overall reliability of your system is then 0.999 ^ 30, or about 97%. A good attacker would take these odds in a heartbeat!

So the answer to your question is that a sufficiently complex system contains its own undoing. You can greatly reduce the risk by lowering the complexity, but the usefulness of your system would come down as well.

Answer 3

90% of unauthorized access comes from people within the network. Disgruntled accountants, bored secretaries, overly ambitious middle management... Even if you make the technology 100% secure, there's still people to worry about.

Answer 4

I did more reading and realized that there is actually some hope. I edited the question to point out that I was talking only about purely software exploits, not about people pointing a gun to your head and forcing you to give your data.

There's actually right now, in production (and apparently already used in many devices: tens of millions if not hundreds of millions), a micro-kernel that has been formally proofed as being immune to:

• buffer overflows / overruns
• memory leaks
• no null pointer exceptions
• no arithmetic overflows

In other words: it is impossible for a security exploits to happen by using any of the above because it has been mathematically prooved (by using an automated theorem prover) that it its, for example, impossible to trigger a buffer overflow in that microkernel.

That's the first of its kind and it shows that there's a way out. It is apparently a very active area of research and I'm willing to bet we're going to see more of this in the future.

The implication are huge: no userland process can do privilege escalation leading to control of the microkernel.

There can of course still exist other ways to pirate the system as of now: right now it's just the micro-kernel (and, partially, the compiler) that have been proved to be resilient to these attack vectors. There may be other attack vectors which haven't been tested yet but still...

It shows that, technically, it is totally possible to not only create an OS that is immune to software exploits but that, moreover, it is possible to mathematically prove that the protection in place aren't exploitable.

I expect this area of research to gain more and more traction.

(*) The Isabelle / HOL theorem prover uncovered 160 bugs (which have been all fixed) in the 7500 lines of C and 600 lines of assembly in the seL4 microkernel, which is now guaranteed to make it impossible, for example, to have a buffer overflow (a typical attack vector) or a null pointer exception in the seL4 microkernel.