Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

closed as not a real question by Jim G., GlenH7, Glenn Nelson, Martijn Pieters, Caleb Jan 26 '13 at 17:17

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

By better methodologies, maybe for example that in the future a team / company could maybe use formal verification to prove that a microkernel is 100% bug-free, failure-free and resilient to security issues, a bit like here: Would this be science-fiction? – Cedric Martin Jan 26 '13 at 1:41
Have you looked at Propellerheads's Reason 6? Is it cracked? – Cole Johnson Jan 26 '13 at 2:16
What keeps us from writing 100% secure code? The same thing that prevents 100% secure prisons, or 100% secure fortresses, or 100% secure bank vaults, or ... Software isn't unique in this respect. – Eric King Jan 26 '13 at 4:33
We haven't even bothered using memory-safe languages to [practically] remove memory corruption vulnerabilities. Similarly we know how to [practically] eradicate injection vulnerabilities. We are well away from needing formal methods to improve security. – Tom Hawtin - tackline Jan 26 '13 at 5:00
To argue why something should exist, one only needs a positive example. To argue why something doesn't exist, one needs a theorem that can prove that it couldn't. Thus, question of this type requires argumentation, which is subject to discussion. – rwong Jan 26 '13 at 8:20

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.

share|improve this answer
enlightening read: microkernel seL4 on top of which Linux can be run. – Cedric Martin Jan 28 '13 at 13:35
It still won't be enough.… – World Engineer Jan 28 '13 at 19:03

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.

share|improve this answer

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.

share|improve this answer
+1: This begs the question of where authorization comes from. A fraction of software exploits come from software overstepping their authorization, but then software can only imperfectly model the idea of authorization in their human owners' mind. – rwong Jan 26 '13 at 8:52

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.

share|improve this answer
Guaranteed by whom? Also, how was the correctness of the theorem prover verified? – Caleb Jan 26 '13 at 17:14
@Caleb: the point is: it's a very active field of research and instead of saying "This is impossible" there are people who are thinking outside the box, trying to make our (computer) science go forward. Of course there are going to be nay-sayers and people seeing only the obstacles, instead of the goal. "The reasonable man adapts himself to the world while the unreasonable tries to adapt the world to himself, therefore all progress depends on unreasonable man". But I understand that post-fact rationalization makes some accept insecurity as a fatality ; ) – Cedric Martin Jan 28 '13 at 13:34
I never said it was impossible. I'm just pointing out that "guaranteed" is a pretty strong word. Unless somebody really did guarantee the correctness of some program, you shouldn't use that word. And if someone did offer a guarantee, I'd like to know more about its terms and what makes them so confident. – Caleb Jan 28 '13 at 14:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.