Slashdot Mirror
The Rise of Software Security
Gunkerty Jeb writes with an article in Threatpost. From the article: "Perhaps no segment of the security industry has evolved more in the last decade than the discipline of software security. At the start of the 2000s, software security was a small, arcane field that often was confused with security software. But several things happened in the early part of the decade that set in motion a major shift in the way people built software ... To get some perspective on how far things have come, Threatpost spoke with Gary McGraw of Cigital about the evolution of software security since 2001."
You can write secure code in almost any language.
Perhaps you want to believe that claim.
And yet, the ongoing real world persistence of privately reported array out-of-bounds errors in critical security-dependent code continues to show that apparently, even the best programmers objectively can't write secure code even if their professional reputations depended on it.
At least, they may be occasionally capable of writing secure code, but they're not capable of never writing any insecure code, or even testing for the existence of insecure code in the code they have released. Third parties have that priviledge. We don't know how many of the third parties who find these bugs are black hats, because we only hear from the white hats. But a 50/50 split between white and black security researchers seems like a good wild-ass guess. So figure one zero-day for every reported monthly security bug. Are you scared yet? You should be.
Is this ongoing security massacre the fault of the language programmers are using? Absolutely yes. The point of security is that 99% correct isn't good enough when that 1% of errors your toolchain didn't automatically detect can get your entire customer base simultaneously rooted. And array out-of-bounds errors have been a solved problem in some languages since 1970.
In 2011, insisting on using a language, or any other tool, which doesn't solve a forty-one year old already solved problem is simply an error.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
I keep watch on "security" threads like this one, hoping to find sanity in at least one answer prior to mine.... and keep getting disappointed.
You're all wrong, so far.
Why? It's simple, it's not an application programming issue, it's an Operating System design issue.
The default permit environment present in everything except IBM's VM is the root cause of 99% of our problems.
Instead of giving each PROCESS a list of resources and permissions, Linux, OS-X, Windows, and pretty much everything else, does it at the USER level. (Yes, I know about app-armor, but that's a special case)
This means that all of the defenses are pointed in the wrong direction. (Imagine building a fort with 10 foot thick perimeter wall as its sole defense in the age of paratroopers and helicopters to get an idea of the scale of the problem).
It doesn't matter how careful or professionally trained the application programmers are, nor how safe the programming language used to write the application is, when the OS isn't even designed to limit what they can do. All programs have bugs, you shouldn't have to trust them not to have them.
Now, those skills and language enhancements are useful for building the operating system, especially when constructing the micro-kernel to run everything, so it's not wasted effort.
I predict we'll see stories like this for at least 10 more years, regardless of the effort or money put in, because we haven't changed our approach yet. It's going to take a few more years until the cognitive dissonance gets loud enough in peoples heads to prompt them to find a better OS, and a few more years to actually have something reasonably solid available. Until then, buckle up... it's going to be a VERY bumpy ride.