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."
tisement much?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Let's ask a nobody, as compared to say a full fledged AV engineer who has been in the field since day 1....nothing like getting your information from the source.... /. a story on me and my company....
oh wait, I get it now, this was just blatant publicity for this upcoming software security firm that needs to make a name for themselves....remind me next time I need to become someone, I should get someone to post on
Dont look for a sig, I aint got one...
It's been so nice watching those weekly SANS vulnerability emails get shorter and shorter over the past decade.
/sarcasm
#DeleteChrome
Claiming that C and C++ are disasters from the standpoint of security is like saying that the IP protocol is a disaster from the standpoint of reliable transmission of data streams, or that HTTP is a disaster from the standpoint of security. Arguably so, but only if you don't supplement them with any other layers or tools.
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
the disasters of beginning of this century include XML. In everything. "Agile" development. IE6 and ActiveX controls. IBM Lotus Notes. "Visual" programming, especially mixed with UML and RUP. Passing parameters from URLs directly to database layers as input without sanitation. Not checking data structure boundaries and sizes. Using root for everything, this one is especially nice when combined with a password, that is used for everything in a corporation. Especially when password is some variation of "adminpass1". Buying more and more BEA/Oracle licenses to set up more and more nodes where the real speed problem could be solved with very little code on a single machine, but obviously that's not sexy and doesn't buy perks. Having no testing cycles, never having enough testing, doing irrelevant testing (this even includes automated testing, which can be huge, but still irrelevant).
Producing huge meaningless documents that end up copied in email to everybody, but eventually don't get read by anybody who they should address, having template "Architecture", where past documents are copied, whatever names are replaced, no thought is given to the project and all the details are left over to the team for the time of implementation. This, especially when combined with time lines that give 80% time to meetings/architecture, 12% time to all of the development combined and then whatever remains is running around like chickens with heads cut off, from users to testers to admins, trying to get any of it working.
All of the above and more, much more are disasters.
But the real disaster here is that pathetic article that this story refers to.
You can't handle the truth.
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.
My only question is, why would you assume a 50/50 split for white hat vs. black hat. Certainly in the general population there are not 50/50 good vs. evil. If that was the case, people would be a whole lot worse off than they are now. I would say that a much larger percentage of hackers are white hat. That being said, even a small number of black hat hackers can do a serious amount of damage.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
The reason things like CapROS haven't caught on is inertia... it's a huge pain in the ass to move things to a different desktop, let alone a completely different operating system, where you have to rewrite things, and adjust to a whole new set of annoyances.
The IBM VM model of things is a pure capability model, you give RAM, DISK, and I/O to a virtual machine, and it can't exceed it's authority. Of course the granularity is a bit rough when you have to do it in terms of disk systems instead of specific files, folders, etc. The need to have a system admin set things up, which isn't very user friendly either, so it's clearly not the exact way things will end up when capabilities go mainstream.
I see the easiest way as looking just like Windows, Linux, etc... except the shortcut to an application also includes a list of files, resources, quotas, etc... this would allow things like Accounting Applications which can't access the internet (unless you change their settings), etc.
Eventually, people will figure it out, but it's going to be a LONG wait. In the meanwhile, the insecurity of everything will get used to sell a lot of software, firewalls, etc... and the worst part is it offers the perfect excuse for filtering and censoring the internet.
I'm glad to see you here... now there are at least 2 of us. ;-)
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.
If they persistently write such buggy code then I wouldn't consider them the "best" programmers. And that's not even consider that we're talking about Microsoft to begin with.
Rose colored glasses much? The general population is 0.01% white hat and 99.99% black hat. The cool thing about humans...they use ingenious psychological tricks on themselves so that they can ignore reality and logic when it's needed. One of the places humans need to toss objectivity and logic is when evaluating Self, close family, and close friends. Once logic and objectivity are out of the picture it's perfectly possible to believe that you, your family, and your friends are all good people; it's those OTHER assholes who are fucking things up.
The reality is that very nearly everyone is one of the assholes.
"Liechtenstein is the world's largest producer of sausage casings, potassium storage units, and false teeth."
The author clearly does not understand programming languages if he says that, or else he's one of those kinds of programmers that just needs to stay away from languages that let you do whatever you want.
C and its somewhat object oriented cousin C++ are just tools to let programmers do whatever it is they want to do. If you know the languages and how they work, you can make whatever you like. You can make insecure programs. Or you can make secure programs. Your choice. What C and C++ suffer from is the stain of blood splatters from programmers that simply do not know what they are doing. Too many programs were written insecurely, not because the language forced them to, but because these programmers didn't know how to write different code into the programs that would make them secure.
I do admit that C has a few flaws, like certain functions that fail to properly test for string overflow conditions. One example is sprintf. Use snprintf in its place so the size of the target is known and checked in the function's own logic. But these are things good C programmers already know about.
I have my doubts about any other language. If a language is flexible enough to develop a major application with, then that language is also flexible enough to let an idiot write an insecure program. However, other programming languages might be useful to C and C++ to draw away the bad programmers. Let those other languages suffer from them for a while. Java certainly has in more recent years.
now we need to go OSS in diesel cars