Slashdot Mirror
The 25 Most Dangerous Programming Errors
Hugh Pickens writes "The Register reports that experts from some 30 organizations worldwide have compiled 2010's list of the 25 most dangerous programming errors along with a novel way to prevent them: by drafting contracts that hold developers responsible when bugs creep into applications. The 25 flaws are the cause of almost every major cyber attack in recent history, including the ones that recently struck Google and 33 other large companies, as well as breaches suffered by military systems and millions of small business and home users. The top 25 entries are prioritized using inputs from over 20 different organizations, who evaluated each weakness based on prevalence and importance. Interestingly enough the classic buffer overflow ranked 3rd in the list while Cross-site Scripting and SQL Injection are considered the 1-2 punch of security weaknesses in 2010. Security experts say business customers have the means to foster safer products by demanding that vendors follow common-sense safety measures such as verifying that all team members successfully clear a background investigation and be trained in secure programming techniques. 'As a customer, you have the power to influence vendors to provide more secure products by letting them know that security is important to you,' the introduction to the list states and includes a draft contract with the terms customers should request to enable buyers of custom software to make code writers responsible for checking the code and for fixing security flaws before software is delivered."
I'll sign such a contract, but the project will take twice as long and my hourly rate will go up 300%.
People like to draw the comparison with civil engineering, where an engineer may be liable (even criminally) if, say, a bridge collapsed. But this isn't really the same thing. We're not talking about software that simply fails and causes damage. We're talking about software that fails when people deliberately attack it. This would be like holding a civil engineer responsible when a terrorist blows up a bridge -- he should have planned for a bomb being placed in just such-and-such location and made the bridge more resistant to attack.
The fault lies with two parties -- those who wrote the insecure code, and those who are attacking it. I'll start taking responsibility for my own software failures when the justice system starts tracking down these criminals and prosecuting them. Until then, I'll be damned if you're going to lay all the blame on me.
A real programmer can do all 25 in one line of code.
Kind of ironic the report is a PDF file, when another report stated that PDF accounts for 9/10 (or something like that) exploits last year.
Some of the errors are not relevant, mainly having my code in a managed (i.e. .NET) environment. The SQL injection and XSS potential vulnerabilities are still very relavent to me. Although most of my responsibility lies in code which is only reached via a https authenticated connection, as with any other web programmer, a "trusted" user can still -especially- find exploits.
This is even more true in inherited code. If you inherited code from a previous employee, I recommend a rigorous audit of the input and output validation. You just don't know what was missed in something you didn't write.
... letting me try assembler with my level of dyslexia.
Holding a gun to somebody's head won't make them a better developer.
I don't understand why well-known and tested techniques can't be used to catch these bugs. There are many ways to help ensure code quality stays high, from good automated and manual testing to full-on code reviews. The problem is that most companies aren't willing to spend the money on them and most open source projects don't have the manpower to dedicate to testing and review.
TFA seems like it's just looking for somebody to blame when the axe falls. If your method of preventing bugs is to fire everybody that makes a programming mistake pretty soon you won't have any developers left.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
So much shit. So much commentary. Just gimme the list? Here it is:
How we know is more important than what we know.
"Insisting on absolute safety is for people who don't have the balls to live in the real world."
- Mary Shafer, NASA Dryden Flight Research Center
Improper Sanitization of Special Elements used in an OS Command
The best solution is not "sanitization" (which people usually perform by blocking or editing out what THEY think are dangerous metacharacters) but proper encapsulation. In addition, there's a misleading section here:
Execl() is not a "C" API, it's a UNIX API. It doesn't involve quoting. On a UNIX system, you can safely take advantage of this mechanism to pass parameters and bypass either shell or application quoting inconsistencies. On Windows, even if your program is in Perl and you pass system() an array of arguments, Perl is still at the mercy of the called program to correctly parse the quoted string it gets from CreateProcess()... *unless* you are operating under the POSIX subsystem or a derivitive like Interix.
In addition, whether you quote your arguments, use execl(), or use a smart wrapper like Perl's system(), you still need to ensure that COMMAND level metacharacters (like the leading dash (on UNIX) or slash (on Windows) of an option string) are properly handled.
This latter problem may remain even if you pass the command arguments through a configuration file to avoid the possibility of shell metacharacters being exploited.
Whitelists can't be simplistic. You can't ban the use of "-" in email addresses, for example. Encoding is better.
So, I clicked the link expecting something similar to the slashdot description and was shocked to find a real and relevant list!
Cross site scripting? sql injection? buffer overflow errors? Those are real problems and issues that any programmers would do well to learn about.
Really, presenting that information almost makes Slashdot seem, well ... responsible and informative.
I wonder if I just went to the wrong site...
As much as we might like to think otherwise, software development is a business. And like all businesses the goal is to generate profit by increasing revenue and decreasing cost. As such an inherent bargain is struck between consumers and software shops as to proper ratio of cost to quality. High volume consumer applications get a lot of attention to quality though less to security. It's all a matter of threat assessment verse the cost of securing against such threats. Sure we all want perfect software where the software engineer is held accountable for every bug. But we also want software whose cost is comparable to a 20 dollar an hour sweet shop programmer. The software that results is really an economic compromise between the two. Running a space shuttle or saving patients lives? You probably are willing to shell out for the high cost software engineer. Putting up your hello kitty fan club blog? You might settle for something a little bit less... high class. I've been in this business for awhile now and as much as we like to wax poetic about quality we are still just trying to have our cake and eat it too. Better, faster, cheaper. Pick two.
She's not a guy. As for her balls, she might have ripped them off the guy named Sue for all I know.
In the case of XSS I'd say fix (X)HTML and the browsers. By default scripting should not work in the body of a page. Force a meta tag to enable it in the head part of the page or by end-user override if they really must have it. There is really no reason scripting needs to be included in the body of a web page. Trying to completely block scripting, especially in IE which just executes damn near anything, is a real pain and often ends up excluding valid data such as comments including source code. If someone uses an unsafe browser it's their problem.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
I work as a software developer in the avionics industry.
This list is ridiculous.
There's nothing any website programmer could do that is even remotely dangerous compared to what we could screw up yet all I see in the list are website programming bugs.
"As a customer, you have the power to influence vendors to provide more secure products by letting them know that security is important to you,"
And, as a consumer, you have the power to influence vendors to provide better employment and buying practices by letting them know that they are important to you.
Meanwhile, the vast majority of America continues to shop at Walmart whilst every competitor goes out of business.
"Does it get the job done? Now what's the cheapest I can get it for?" is most people's primary motivation.
Sellers, who listen to them saying, "I want security!" and deliver that, at the expense of greater cost, are then left wondering why the competitor who did just enough to avoid standing out on security but otherwise kept their product slightly cheaper is selling many times more copies.
So, yes, people can influence sellers with their actions. The problem is, it needs to be their actions, not their words. Even worse, they're already successfully doing just that - unfortunately, their actions are screaming something quite different to any words about, "Security is truly important to me."
Been there, done that, in an aerospace company. Here's what it's like.
First, the security clearance. There's the background check before hiring, which doesn't mean much. Then, there's the real background check. The one where the FBI visits your neighbors. The one where, one day, you're sent to an unmarked office in an anonymous building for a lie detector test.
Programming is waterfall model. There are requirements documents, and, especially, there are interface documents. In the aerospace world, interface documents define the interface. If a part doesn't conform to the interface document, the part is broken, not the document. The part gets fixed, not the documentation. (This is why you can take a Rolls Royce engine off a 747, put on a GE engine, and go fly.)
Memory-safe languages are preferred. The Air Force used to use Jovial. Ada is still widely used in flight software. Key telephony software uses Erlang.
Changes require change orders, and are billable to the customer as additional work. Code changes are tied back to change orders, just like drawing changes on metal parts.
In some security applications, the customer (usually a 3-letter agency) has their own "tiger teams" who attack the software. Failure is expensive for the contractor. NSA once had the policy that two successive failures meant vendor disqualification. (Sadly, they had to lighten up, except for some very critical systems.)
So that's what it's like to do it right.
A real problem today is that we need a few rock-solid components built to those standards. DNS servers and Border Gateway Protocol nodes would be a good example. They perform a well-defined security-critical function that doesn't change much. Somebody should be selling one that meets high security standards (EAL-6, at least.) It should be running on an EAL-6 operating system, like Green Hills Integrity.
We're not seeing those trusted boxes.
Child molesters are really a special case; they have a mental disorder. However, even there the system is fucked. A guy who screws a 16-year-old girl when he's 18 is NOT a child molester. The only people who should be guilty of true child molestation are those who molest pro-pubescent children, like 12 and under. That's where you someone is truly sick in the head, because no normal man would ever be attracted to a pre-pubescent child. But lots of men will admit to being attracted to a 17-year-old girl. Lots of female movie stars aren't much older than this.
Actually, I have to say I can't blame the guy. There's some freaks on this site who think it's funny to "out" someone. Someone did it to me a while ago, calling me by my real name, even though there's no references I know of in my profile to my real identity. I have no idea how he did it. It's why I never say much specifically about my employment here, or if I say a little too much, I post anonymously, even though I hate doing that because it makes it impossible for me to read any responses.
So if Mr. Anonymous gives enough information about his crime, some freak could very well go to the trouble of spending a day digging through government websites to try to find his real identity and post it here.
"But, no matter what you do, it will never be perfectly, 100% risk-free to fly. Or to drive, or to walk, or to do anything." I find that very appropriate given the current topics so often discussed here.
There's another problem here which we seem to be forgetting: The user.
Users continue to buy systems with inferior security -- every dollar spent on Windows is a dollar telling Microsoft that you're OK with them taking months to fix known security bugs, and Apple is no better. Maybe this "contract" would help, though it will kill Easter Eggs, among other things, and that makes me sad.
But even if you design the most secure system ever, it's useless if the users aren't educated about security. This was specifically a list of programming errors, but put it into perspective. There's really nothing I can do to keep people from reading your email, modifying it, or impersonating you entirely and undetectably in an email sent to someone else (which you'll never see), if you aren't willing to at least learn the basics of something like PGP. If you learn PGP and use it properly, and convince all your friends to do the same, and people still do nasty things to your email, that is the point it becomes the programmers' fault, but you have to meet them halfway.
Don't thank God, thank a doctor!
Click on your post number, then bookmark that page. Works great for keeping track of troll^W posts.
Sorry, no, because then that would require criminalizing relationships between 60-year-old men and 30-year-old women, and that's just wrong. Or, it would create a harsher sentence for a 60-year-old raping a 30-year old than a 20-year-old raping a 12-year-old, and that's very wrong (one's a prepubescent child, and the other is not).
if (alert_code = red)
launch_missles ();
Even there, I don't think anyone should be considered a child molester if the victim is 17. There's no significant difference between a 17-year-old and an 18-year-old, yet one is adult and the other isn't.
The dividing line should be at 12 or 13, which is pubescence. Child molesters aren't even interested in 17-year-old girls, they're too old for them. They'd rather rape someone who's 5.
Thank you for an enjoyable half hour wandering through your website. You're a total nutter, but it pleased me to see that my Internet Kook detectors are properly calibrated.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
And lets not forget to put some blame on the OS. If the OS would provided a framework to properly isolate applications from each other most exploids would simply turn into a harmless denial of service. I couldn't care less if a broken PDF crashes the PDF reader, but I if that broken PDF can get access to my whole system something is seriously wrong with the underlying OS. There is no reason why a PDF reader, webbrowser or most other tools should ever need access to my whole system. Access to a window to draw their stuff, access to the data they need (i.e. just the byte-stream, not the filesystem) and to a location to store their config data would be enough for most applications, yet instead they get access to everything that a user account can reach.
There is happening some slow progress in that area with AppArmor and such, but we are still quite far away from having a native application be as secure a Flash app or a Java Applet by default. And yes, those aren't 100% safe either, but there is a different between being secure and having an exploid every now and then and providing no security whatsoever from the start.
Yes and no. The problem was that the software could get into an inconsistent state - this shouldn't happen, but it shouldn't be a problem. And it wasn't, because the first generation had hardware interlocks that made it fail safely (beam wouldn't activate).
Cutting corners was the biggest problem. Had they not removed the interlocks for cost reasons, nothing bad could have happened. It would have been physically impossible.
Another couple of deaths due to the profit motive. I don't mean to suggest that the profit motive is always bad, but I don't want the company making my radiation machine to be concerned exclusively with making money.
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
Only a Sith deals in absolutes.
PlusFive Slashdot reader for Android. Can post comments.
Having programmers imagine every way that their program may be attacked is impossible.
Fortunately, that's typically not required for software security. In a lot of cases, you can prove that for all inputs, the software does the intended thing.
For instance, if you know that the username variable will always be properly escaped, you don't care whether the user is called "bobby" or "bobby tables" (http://xkcd.com/327/).
It takes a lot of discipline, though, to always consider who the origin of a particular piece of data is, to decide (based on that) exactly what amount of trust to place in it, and how to handle semi- or untrusted data.
I have mod points so I would mod you up.
However you're an AC, and lots of people browse /. with all AC's automatically downmodded to -1 so there's probably not much point. But I agree with much of what you say - with more to add.
Most of the arguments against this article boil down to one single thing.
"It's too hard."
You know something? That's a lousy argument. If "It's too hard" was a real argument against reliable software, the airline industry would never have developed modern autopilots without planes crashing out of the sky because of software faults on a daily basis.
If "It's too hard" was a real argument, NASA wouldn't have a reputation for developing almost bug-free software.
If "It's too hard" was a real argument, OpenBSD would have had a lot more than just two remote holes in the default install in over 10 years.
Frankly, as an industry IT (and I'm referring to all IT here, not just software development. Sysadmins are just as guilty) needs to grow up and start developing and implementing some real good-practise processes industry-wide. The engineering industry seems to have mostly managed that, and when was the last time you heard of a properly maintained car exploding for no good reason?
Sometimes. But that is maybe a pretty good observation. Whatever.
once. It was a Kawasaki 350 like mine, a couple of years older and parked next to my bike. With apparently, an identical lock cylinder. I was in the process of starting it when I looked down and saw that the shape of the instrument cluster had changed. At that point, I noticed I was starting the wrong motorcycle, stopped, moved to my own bike and took off.
I figured it was simply a 1 in several thousand chance and was mildly amused.
Tech Public Policy stuff
More to the point, the astronauts explicitly agreed to the risk. They knew what they were doing.
It's really not the same thing as bridge building at all. xD
I think most here agree to a certain point. Writing software is impossible without errors. I also feel that holding a gun at the head of a developer in order to 'persuade' him or her to write better code is not going to help. We are after all humans, we need motivation and stimulation in order to get better at what it is we need to do.
However, what is more important is that the processes surrounding the software that needs to be produced, whether result of a client requirement or as part of a new idea, is sound and helps to avoid and remove errors.
Developers have an obligation to take note of known exploits, known attack vectors, and make sure to avoid these pitfalls. But it is impossible to predict all types of attacks, so the processes that govern the requirement gathering, designing, development, testing and the continued maintenance on the software once released are equally important. The whole organisation is part of that quality and security process, not just the developer. Plus, the cost of the production of the software is a very important consideration.
In light of this I found the old article about the space shuttle software development extremely interesting. It clearly shows that it IS possible to write near-perfect software, but that has its price. But a well-driven development organisation is in principle capable to produce solid, error-free code. By adjusting the mindset of people and modifying the processes that introduced errors.
Read it if you don't know it yet, it is a very nice article that I keep in my bookmarks...
http://www.fastcompany.com/node/28121/print
By all means, accountability is great.
But saying the developer is at fault is ridiculous. It opens the door for companies to mismanage projects as per usual, and clueless HR departments to hire people who don't know what they're doing, and fire people arbitrarily every time they have a complaint from someone that the software doesn't work.
Start the responsibility with the company. If the company sends a flawed product and are to be made accountable, then the organisation needs to prove:
* It has proper QA processes in place to test the product, and that the staff are suitably qualified.
* The project management was performed to allow for proper specification, design and development within the normal working hours of a day, taking holidays and time lost due to usual unforeseen circumstances.
* Training, or self learning time is allocated to enable staff to keep current with developments and issues with languages/compilers/methods they use.
If you're going to hold a developer responsible, then it should be absolutely certain that everyone in the dependancy chain for that person is responsible. Did HR hire someone who wasn't fit for purpose? Their job is to ensure that doesn't happen. They're the start of the problem chain.
Did management provide the logistics necessary to complete the job to a quality? If not, they should be liable.
Did the sales team (if it's bespoke software) make impossible promises (if so, and developer opinion was overturned such that a 'broken' system was arrived at from spec, then the salesman should be accountable).
Did the producer of the spec introduce a design flaw that resulted in the error? If it wasn't the developer, then the specifier/designer was at fault.
Pretty much whichever way you look at it, management and HR should carry the can first, leaking down to the developer, if you're going to be sensible about it. If a place is well run, well managed then sure, have developer liability, but expect to have raised costs to cover developer's professional liability insurance.
is it me or is americans in love with absolutes?
You are 100% correct. Anything less would be un-American.
Tequila: It's not just for breakfast anymore!
Yes, but they were betrayed by petty office politics that resulted in the warnings of experts being ignored by people that got their jobs by having the right drinking buddies.
They wanted Feynman's name on the cover up but he wasn't going to go along with it after NASA engineers went around management and the rigged enquiry procedure and showed him the evidence.
...it is unreasonable and completely unrealistic to expect every line to be a pinnacle of perfection, just like it is unreasonable to expect that every sentence in a book is completely without error.
And every lawyer you ever talk to will agree with you AND then tell you that what you just said is irrelevant. Nobody really cares if the code is perfect. What they care about is if the code failed and someone got hurt (financially, physically, etc) as a result. If the code is designed and/or implemented such that a reasonably common and foreseeable attack (say a buffer overflow) can and does occur and harm results, then the programmer has failed in their duty of care. Doctors, (civil) engineers, lawyers, accountants and even tradesmen (electricians, etc) who engage in professional services all have this obligation to perform high quality work. When they fail in their duties they get sued and rightly so. They also carry liability insurance because nobody is perfect. Software engineers are not and should not be an exception. Just because your job is hard sometimes does not excuse you to do shoddy work that will cause harm to others.
I think that companies (management) should be held liable for poor quality of the software they produce. How each individual company distributes that liability internally is completely up to them. So whether you want to work for a company that holds its developers financially and legally liable is completely up to you. My guess is that that such companies would quickly go out of business.
I work in the telecommunications industry managing (first line - still a pawn) a sizable team of software designers. If one of my designers creates a security hole which is subsequently successfully hacked, it could mean that 911 services go down somewhere and someone unnecessarily dies. That being said, a bug in our software typically means that someone somewhere can't download their porn.
Here's how the process (for me) works:
1) Customer sees a need for new functionality and communicates that to the company
2) Request goes to Product Line Management and they get R&D involved for some preliminary time and cost estimates
3) PLM then squeezes the timeline and passes on the date to management
4) Management squeezes the timeline again and passes it back to the customer
5) Customer then requests a reduced cost and an even earlier delivery date
6) Management agrees to terms
7) R&D is stuck developing a release in 1/3 time it takes to develop properly
Also, the code base is millions of lines of disjointed code that are very difficult to manage effectively.
In order to devliver software under these conditions, we depend on heroics from our developers... they're definitely overworked, but not underpayed. We also have to cut corners by only performing specific targeted testing. In the end, our products have their fair share of bugs, and some of those bugs could be catastrophic. However, that's what the customer negotiated and paid for, so that's what they got!
Everyone of my designers would like to produce better software (not perfect - that's impossible). They're just not afforded that privilege by management and customers. So do I think software developers should held responsible? Hell no... they should learn from their mistakes, but holding them financially and legally responsible means it will take 10 times longer to develop software.
1. PHP. ...better stop there before I get modded into oblivion.
2. Visual BASIC.
3. Perl.
4. C.
5. C++.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
There are plenty of places to assign blame, and it is always suspicious when someone jumps right beyond their own borders when doing so. There are rarely any clear lines, and while a bug might originate with the programmer, it is just as much your fault for not catching it and switching to something without that flaw. It is like people who complain when they get a virus on Windows, or complain when their webcam doesn't work on Linux: at some point, you have to choose to be responsible for your own choices. Saying, "let's sue that developer!" does not fix a single problem in software security. Not one. Microsoft will move on the way they always have under the protection of their lawyers, shady international companies will keep being shady, and buggy programs made by people you should never have trusted in the first place will still exist. You got blood, but did you solve anything?
Now, this line is my favorite, but it is getting a little worn out in this discussion: good luck with that. I'll try to mix it up next time.
There's that meaningless term again. What is "foreseeable and preventable?" Does Mary Westington, juror at your trial, have even the slightest clue what is "foreseeable and preventable" when it comes to C++ buffer overflows? Does the judge? The majority of programmers would have a hard time nailing down what that means in the context of security, especially when you get into the more complicated aspects of it.
In programming, everything is conceptual. When you write your program, it probably isn't going to change. If we're building a skyscraper, and it falls down at some point, there is always the question of the material quality, stability of the ground, and any possible damage it may have withstood. In software, when something does go wrong- and give it time, it WILL- nothing has changed but the world around it. How do you determine if an error was "foreseeable and preventable?" There was a time when most security errors were unknown, no matter how simple. SQL injection was, for a time, a completely unprepared for issue. If you come back to software I wrote 10 years ago, run it on your computer, and happen to be attacked, is it my fault you used something 10 years old?
There is a very good reason for that: programmers tend to be the little guy. When laws get abused, and they will be, we're the ones who get them used against us. You, the corporate executive (derived from your previous comment - may be incorrect), have far more resources to defend yourself, and a totally different social standing. Programmers are the strange guys who talk in codes and smell. You are the pinnacle of capitalist society. Who do you think is going to have the law misused against them?
We also tend to be fairly logical, and see things for what they are. A good number of p
Great Intellect...
I believe that most buffer overrun exploits work by overwriting a function's return address on the stack. These could be largely avoided by the compiler using either of two techniques. First, it could grow the stack into higher numbered addresses and store the return address first. Now if the code allows a buffer overrun, it will overrun the local variables and spill into the available stack space. In both cases, the chances of finding a function pointer are small. In contrast, if you grow the stack into smaller numbered addresses, then a buffer overrun has pretty much 100% chance to overwrite a code pointer (the return address).
The other technique is to use two stacks, one for the return addresses and another for the parameters/return values. Same idea though: move the return address out of the way of the overflowed buffer.