The 25 Most Dangerous Programming Errors 534
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."
Yeah, right. (Score:5, Insightful)
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.
Re:Yeah, right. (Score:5, Insightful)
I could lock down any system and make 100% hacker proof - i'd unplug their server.
it's a ratio of risk to reward like most things, if you want zero risk there won't be any reward.
re:zero risk (Score:5, Insightful)
"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
Re: (Score:3, Funny)
Re: (Score:3, Insightful)
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
Re: (Score:3, Interesting)
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.
Re:zero risk (Score:5, Funny)
is it me or is americans in love with absolutes?
You are 100% correct. Anything less would be un-American.
Re: (Score:3)
If simple common sense coding techniques can plug most of the avenues of attack, then any developer worth his salt SHOULD be responsible for plugging them...especially in this day and age where security holes are making headlines.
For the bridge analogy, I'd consider a buffer overflow equivalent to missing a rivet. If you know what you're doing it shouldn't be possible. Trusting user-generated input is one of the first taboos you learn about in computer science.
Re:Yeah, right. (Score:5, Interesting)
I once coded a program for my own use that downloaded images from binary newsgroups, decoded them, and inserted them into a PostgreSQL database, with keywords extracted from the message. It was a nice program, handled multipart messages, and only stored each image once, using SHA1 hashes to check for dublicates - I even took the possibility of a hash collision into account and only used them as an index. No buffer overruns, no SQL injections, no nothing. Yet it crashed. So why did it crash?
Some moron included the same image twice in a single message.
It's fine to say "don't trust user input", but it's pretty much impossible to actually make sure that you've accounted for all possible ways it can be faulty, and this becomes harder the more powerful the program is, since using that power requires more complex input.
Re:Yeah, right. (Score:5, Funny)
Re:Yeah, right. (Score:5, Insightful)
It's fine to say "don't trust user input", but it's pretty much impossible to actually make sure that you've accounted for all possible ways it can be faulty, and this becomes harder the more powerful the program is, since using that power requires more complex input.
It is nearly impossible if you want to enumerate all possible ways input can be wrong. Thus you should just enumerate all ways input is right. If you expecting for instance numerical input, don't look for ";" or ")" or anything that could have been inserted maliciously. Just throw everything away that doesn't fit [0-9]*.
You know the input your program can work with. So instead of trying to formulate rules how input may differ from the input you want to catch errors, write down the rules the input has to follow and reject everything else. This is straightforward.
Re: (Score:3, Informative)
Re:Yeah, right. (Score:4, Insightful)
I once coded a program for my own use that downloaded images from binary newsgroups, decoded them, and inserted them into a PostgreSQL database, with keywords extracted from the message.
So, I'm guessing you were building a porn search engine? For "research" purposes of course.
Re:Yeah, right. (Score:5, Funny)
Your ideas are intriguing to me and I wish to subscribe to your pr0n scraper.
Re: (Score:3, Insightful)
Ah, the ol' Reject-Known-Bad or Sanitise-All-Input paradigm. It is indeed impossible to anticipate all the bone-headed ways in which input can be botched, maliciously or not. Thus, it is then more secure to prepare a discreet list of valid input and only accept that, rejecting anything that does not conform to what you expect. This rejection is not based on a black-list of bad input to compare against, but on a sort of white-list what you assert your program can handle.
If you would have considered this a
Re:Yeah, right. (Score:5, Funny)
His code didn't expect two girls and one bucket
Re:Yeah, right. (Score:4, Insightful)
"Guess what, princess: coding is a hell of a lot easier to do, is simpler to test, and has less inherent risk than any other kind of engineering."
False, false, and true, in that order. The non-inherent risk can be pretty high though, but this is also true of other types of engineering.
"You can't put out a patch to fix a collapsed bridge" ...do you understand that the word "patch" did not originate in programming? I think the closest analogue to a collapsed bridge is unrecoverable data loss (or possibly hardware failure, which is rarely software-induced, at least on the desktop).
"or release a service pack for a unbalanced rotor shaft that destroys a generator" ...do you know what you're talking about? You also can't reinforce a bad password-negotiation algorithm with tempered steel, but that doesn't mean ANYTHING.
"You can't do destructive testing on a completed project in the real world."
Sure you can. The computer equivalent would be doing it on a live system. Stupid, in either case.
"You can't tell a client that it's going to take twice as long and he's going to have to pay you three times as much for you to do it properly."
Up until this point I could see where you were coming from, but this is divorced from reality. Cost and schedule overruns are not disproportionately present in the computer field, and anyway the GP didn't seem to be talking about overruns, he was talking about what it costs compared to the jackass who wants to use crazy glue and popsicle sticks to build his bridge. Where some of what you said before was ignorant or hyperbole, this is just a stupid statement. I realize you're trying to turn the GP's words on him, but you failed.
"You might have a program that takes two numbers and adds them together and spits out the answer. I type in a number and a letter, your program crashes because you're retarded and didn't sanitise the inputs. My bridge doesn't fall down because a bus drives over it instead of a car."
Do you realize that you just made an argument that building a bride that can support a bus is easier than input-validation? It isn't, of course. I can imagine extremely stupid ways to make a bad bridge.
"The programming errors identified are repeated, endemic errors. The attack vectors are the same every time. You have the tools to check and protect your code. Your software still breaks. That's why everyone's pissed at you. You have a mindset that any errors in the program will be trivial to correct, so you don't do it properly the first time."
True, false, inherently imperfect tools, true, true, strawman, misdirected anger.
"Your'e paid to produce software that performs a given function, not software that might work under some circumstances. Harden the fuck up, and do your job properly."
Not two paragraphs ago you argued that he should be paid the going rate for software that might work under some circumstances.
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
That day has already arrived in the form of recognised quality assurance standards (eg: ISO-9000). Such standards in both software and civil engineering are concerned with prevention, detection and remedy of faults rather than the individual's skill at bolting things together.
Re: (Score:2, Insightful)
Yep this isn't about removing vulnerabilities or improving quality - this is about making someone accountable.
Having a countract where the developer is made liable? This is management blame-storming at it's finest.
Re:Yeah, right. (Score:5, Insightful)
Anybody who honestly thinks that scary looking contracts are going to keep the engineers in line should read up on the sorts of things that happen in workplaces with real hazards: heavy machinery, toxic materials(and not the chickenshit "recognized by the state of california to cause reproductive harm" type, the "Schedule 2, Part A, per CWC" type), molten metal, exposed high voltages, and the like. Even when their lives are on the line, when the potential for imminent gruesome death is visible to even the least imaginative, people fuck up from time to time. They slip, they make the wrong motion, they get momentarily confused, some instinct that was real useful back when lions were the primary occupational hazard kicks in and the adrenalin shuts down their frontal lobe. Happens all the time, even in countries with some degree of industrial hygiene regulation.
Re:Yeah, right. (Score:5, Insightful)
y drafting contracts that hold developers responsible when bugs creep into applications.
Arguably the stupidest thing I've ever heard, and I'm old enough to have heard a lot of stupid shit.
Anybody who honestly thinks that scary looking contracts are going to keep the engineers in line
Is a moron who would have been a candidate for early-term abortion if we could only predict such things. The reality here is this: if you try to put engineers (especially software engineers) into a situation where every line of code they produce might put them in court, you're going to find yourself with a severe shortage of engineers. There are many things that creative minds can do, and if you make a particular line of work too personally dangerous nobody will enter that field.
More to the point however, only completely drain-bamaged organizations actually ship alpha code, which is obviously what we are talking about in this case. Because if we're not, if we're discussing production code that was overseen by competent management, conceived by competent designers, coded by competent software engineers and tested by competent QC engineers (you do have those, don't you?) then blaming the programmer alone is absolutely batshit insane, and will serve no legitimate purpose whatsoever.
Modern software development, much like the production of a motion picture, is a complex team effort, and singling out one sub-group of such an organization for punishment when failures occur (as it happens, the ones least responsible for such failures in shipping code) is just this side of brain-dead.
And I mean that about the programmers being the least responsible. Unless management has no functioning cerebral cortex material, they will understand and plan for bugs. You expect them, and you deal with them as part of your quality control process. Major failures can most frequently be attributed to a defective design and design review process: that sort of high-level work that happens long before a single developer writes one line of code. The reason that engineers who build bridges are not put in jail when a bridge fails and kills someone is because there are layers and layers and layers of review and error-checking that goes on before a design is approved for construction. It's no different in a well-run software team.
If your team is not well run, you have a management failure, not a programmer problem.
I had stupid people, I really do. And people that propose to punish programmers for bugs are fundamentally stupid.
Re:Yeah, right. (Score:4, Insightful)
The reality here is this: if you try to put engineers (especially software engineers) into a situation where every line of code they produce might put them in court, you're going to find yourself with a severe shortage of engineers.
I'd be happy to do the job. However, I'll probably never actually finish it, as I'll be checking it over and over for bugs until they get tired of me refusing to release it and sign off on it and fire me, at which point I'll move on to the next sucker^Wemployer and continue to collect a paycheck.
Re: (Score:3, Insightful)
The reality here is this: if you try to put engineers (especially software engineers) into a situation where every line of code they produce might put them in court, you're going to find yourself with a severe shortage of engineers.
Actually, you're going to end up paying a fortune for software in order to cover the developers' litigation insurance premiums. Most customers prefer to have cheaper software and carry the risk themselves.
Re:Yeah, right. (Score:4, Insightful)
I think the main reason we have so many bugs in software is quite simply that no one really cares. Of course everyone complains about it, but when you look past the words towards the actions, you can see it more clearly.
Everyone still buys the cheap software with tons of features. A simple bridge with a few modifications to an almost cookie cutter design costs a lot more than a very complex piece of custom business software with far more potential points of failure. And that's about right. If the bridge fails there's a good chance someone will die. If business software fails, someone might lose some money. So when you're looking at the risk of bugs in business software, paying for a lot of people to do detailed design, design reviews, code, code reviews, QA testing etc. etc. Well it just doesn't add up. The cost of getting it right is higher than the cost of dealing with the bugs.
The reason this contract is fundamentally stupid is because a vendor following it will have to increase the contract cost by an order of magnitude. Probably some more as well to cover the risk of litigation. Then the customer will have to weigh up the costs and risks, and realise their older contract might actually be more sensible in the real world.
Re:Yeah, right. (Score:5, Insightful)
Except what really happens is that American coders won't sign the documents. That's where Indian and Chinese agencies will sign "whatever", cash the check, and farm it out to low paid code monkeys. Legally, they're not in the USA so your contract is Worthless.
Re: (Score:3, Insightful)
Exactly. Why do you see that as a bad thing? Suppose instead of "contract" we say "these are the design/coding standards at this company and as an employee of this company you are required to follow them. If you don't then we will penalize you." What exactly is wrong with that?
For the last umpteen years, in all sorts of venues social and professional, I've been seeing accountability become more and more denigrated and dismissed. "Oh let's not play the blame gam
Re:Yeah, right. (Score:5, Insightful)
For "accountability" to be properly applied, it must always be connected to power. The relationship goes both ways. Nobody with power should ever lack accountability, lest their power degenerate into mere tyranny, and nobody with accountability should ever lack power, lest they merely be made the scapegoat. This is the real problem with the false "accountability" commonly found in organizational contexts:
If, for example, you have a "release engineer" who must sign off on a software product, or a team of mechanics that must get a 747 ready for passenger flight, those people must have the power to halt the release, or the flight, if they believe that there is a problem. If they do no have this power, they aren't actually "accountable" they are merely scapegoats, and the one who does have this power is truly accountable; but is dodging accountability by assigning it to subordinates. The trouble is, in real world situations, being the person proximately responsible for expensive delays is, at best, thankless. Unless the organization as a whole is invested in the importance of that role, the person filling it will be seen as an obstruction. Obstructions have a way of being circumvented. Assigning blame under those circumstances is actually the opposite of accountability; because punishing the person who didn't make the decision will mean letting the person who did off the hook(in the same way that falsely convicting the innocent isn't "tough on crime" because it implies releasing the guilty). The second issue is the belief that being made accountable will make humans behave fully responsibly. This isn't the abusive mess that the first issue is; but it is contrafactual and tends to distract attention away from the more valuable task of building systems that are (at least somewhat) resistant to human error. Even when accountability is correctly apportioned to power, humans are imperfect instruments. If you want to build systems of complexity unprecedented in human evolutionary history, you will have to learn to build systems that are tolerant of some amount of error. Checklists, automated interlocks, automated fuzz testing, etc, etc. must all be employed; because, ultimately, "accountability" and punishment, while they have their virtues, cannot remediate failure. Executing murderers doesn't resurrect their victims. Suing programmers doesn't recover data stolen in some hack attack. There isn't anything wrong with punishing the guilty; but its utility in accomplishing people's actual objectives is surprisingly tepid. People don't want to sue programmers, they want high-quality software. People don't want to fire mechanics, they want planes that don't crash. People don't want to incarcerate criminals, they want to be free of crime. "Accountability" is one tool that can be used to build the systems that people actually want(and there are arguments to be made that it is ethically obligatory in any case); but single minded focus on it will not achieve the ultimate objectives that people are actually seeking.
Re: (Score:2, Insightful)
Re:Yeah, right. (Score:5, Insightful)
Re:Yeah, right. (Score:5, Insightful)
It's laughable to equate an outright lack of security (lock-less doors) with subtle programming errors which result in security holes. It's not like a door with no locks. It's like a door with a lock which can be opened by some method that the designer of the lock did not envision. Does it mean the lock designer did a poor job? That depends on the complexity of the hack itself.
Software is designed by humans. It won't be perfect. Unfortunately, software is targeted by miscreants because of its wide deployment, homogeneity, and relative invisibility, which are concepts that are still quite new to human society. I'd be willing to take responsibility for security failures in my products, but I'm sure as hell not going to do so when I'm subjected to your every idiotic whim as a client, nor will I do so at your currently pathetic pay rates. If you want me to take the fall for security failures, then I reserve the right not to incorporate inherently unsecure technologies into my solutions. In fact, I reserve the right to veto just about any god damned thing you can come up with. After all, I'm a security expert, and that's why you hired me, right? And I'm going to charge you $350 an hour. Don't like it? Go find somebody dumber than me to employ.
Re:Yeah, right. (Score:4, Interesting)
It's laughable to equate an outright lack of security (lock-less doors) with subtle programming errors which result in security holes. It's not like a door with no locks. It's like a door with a lock which can be opened by some method that the designer of the lock did not envision. Does it mean the lock designer did a poor job? That depends on the complexity of the hack itself.
I mostly agree. My pet peeve is SQL injection attacks, because they are so frickin' easy to avoid. Any developer that leaves their code open to SQL injection attacks should be held liable (unless their employer insists they use a language that doesn't have prepared statements, in which case the company should be held liable).
Re: (Score:3, Interesting)
In my time, I have seen several instances of SQL injection-vulnerable code, and 99% of the time it comes from junior level developers, who obviously have had no security training.
Should the developer be liable, or the company that let them code without being trained?
Re: (Score:3, Funny)
even then, a decent DBA will prevent even the crappest program from being a problem.
When you find one of these elusive DBAs can you send me a reference, because so far I have yet to meet one even remotely tolerable, let alone "decent"
Re:Yeah, right. (Score:5, Interesting)
Unfortunately, many of these errors are _not_ subtle. Let's take Subversion as an example. It is filled with mishandling of user passwords, by storing them in plaintext in the svnserve "passwd" file or in the user's home directory. Given that it also provides password based SSH access, and stores those passwords in plaintext, it's clear that it was written by and is maintained by people who simply _do not care_ about security. Similarly, if you read the code, you will see numerous "case" statements that have no exception handling: they simply ignore cases that the programmer didn't think of.
This is widely spread, popular open source software, and it is _horrible_ from a security standpoint. Collabnet, the maintainers of it, simply have no excuse for this: they have been selling professional services for this software for years, and could have at least reviewed if not accepted outright the various patches for it. The primary patch would be to absolutely disable the password storage features at compilation time, by default, especially for SSH access. There was simply never an excuse to do this.
I urge anyone with an environment requiring security that doesn't have the resources to enforce only svn+ssh access to replace Subversion immediately with git, which is not only faster and more reliable but far more secure in its construction.
Re: (Score:3, Insightful)
I agree writing password to the disk is bad, but have you ever used CVS/SVN/etc. without stored passwords? You end up typing your password a thousand times a day, which is simply unusable.
So there needs to be *some* way to store passwords, or no one will use the system. On some systems there's a wallet/keychain/etc. available for secure password storage, but on most there is not, and there's certainly not a universal one among Win/Mac/linux/BSD/etc., so you pretty much have to write your own if you intend t
Re: (Score:3, Informative)
_Allow_ svn+ssh. Too many sites have managers unwilling to do so, and insistent on using HTTP with the user's own system passwords used in clear-text via HTTP, and stored in clear-text on build servers, because they cannot be bothered to allow competent managers to _enable_ svn+ssh.
The problem isn't that servers won't allow svn+ssh access, it's that managers for such sites won't allow the "svn" user to be configured and used in such circumstances. I've run into exactly that situation on several occastions:
Re:Yeah, right. (Score:5, Insightful)
There is a big difference between "not perfect" and "damn sloppy" and buffer overflows fall into the latter category. For decades we've been teaching students to make sure a buffer has enough space for a chunk of data before writing the data to the buffer. Any so-called programmer who does this is lazy or stupid, or both, and doesn't deserve the title of programmer or a job trying to do what real programmers do for a living. Good gravy, the quality of most software I encounter (and by that I mean software that I use) is so poor it's amazing! I find myself thinking with discouraging frequency "didn't anybody at Widget Co. even try this software out before shipping?"
Re: (Score:3, Insightful)
Actually, software is applied mathematics, which can be perfect to solve a discreet problem, indeed. However, there are many factors involved in the development of software, most unrelated to mathematics and algorithms, that hasten the design and implementation, and require compromising such perfect solutions.
It would then be more accurate to say Software is subject to business pressures, and as such it won't be perfect.
-dZ.
And who would buy such a car? (Score:3, Insightful)
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 specifi
Re: (Score:3, Funny)
Oh please... what's with this "Window" customer requirement? It's trivial for a thief to break it with a rock. So what exactly is the point of doors and locks????
Apparently all car makers are aiding and abetting by including windows.
Re:Yeah, right. (Score:5, Interesting)
Even a car with no locks shouldn't be responsible, you bought the car knowing full well there was no locks, if you want cars with locks, pressure those who make cars and take your business to one with locks.
Exactly. At a previous job I was in charge of maintaining a system for tracking clients' assets. By which I mean realtime GPS coordinates and telemetry of big frikkin trucks full of DVD players or plasma screens or whatever. Information which would actually be very dangerous Fast-and-the-Furious style if it were accessible by the wrong people. When I inherited this system I went to my manager and went "this could be cracked in about a hundred different ways simply by changing some numbers in the URL" and they said "why would anyone do that?" Later, the internal client who owned the data asked about security and I just said "it would basically need a rewrite, it has enough trouble not showing users each others' data let alone standing up to a deliberate attack" and so they swept it under the rug. I could probably still log on to one of their accounts today and find out where the truckload of free plasma screens was, if I was a bad person.
I almost stole a motorcycle by accident (Score:3, Interesting)
I figured it was simply a 1 in several thousand chance and was mildly amused.
Re: (Score:3, Interesting)
Re:Yeah, right. (Score:5, Informative)
Holding programmers accountable for their coding errors should happen inside of the corporation as they are working on the project. I don't remember which company had this, but if a developer broke the build it failed to pass a test a lava lamp at their cubicle would turn on, and until the developer fixed the build the lava lamp would stay on, which generally meant you had a certain amount of time to fix the issue before it would actually start bubbling. This way there is an incentive not to break the build, and a bit of competition between the various programmers to have the least amount of bugs or build breakages.
Having programmers imagine every way that their program may be attacked is impossible. There will always be new attacks that take advantage of that one that the programmer had not thought of. Just like the security systems that are in place at airports around the world. If the good guys could come up with every single scenario that an attacker could take airports would be much safer, as every single scenario had already been thought about.
I agree with you, don't put all the blame on me as a programmer.
Oh, if I had mod points, you sir would have them!
Re: (Score:3, Funny)
> Holding programmers accountable for their coding errors
We used to have a board where we would note "bozo the clown points" for anybody involved in the project, even managers ! ;-))
http://en.wikipedia.org/wiki/Bozo_the_Clown [wikipedia.org]
Re:Yeah, right. (Score:4, Funny)
We used to have the "Diaper of Shame". That started when one of the engineers said "If my code is broken, I will wear a diaper around the office all day tomorrow". Sure enough, it was broken and sure enough, some one went out and got a package of adult diapers.
We let him wear it over his pants and afterwards it would just migrate to your cubicle.
I wonder if we could still do that today....I smell a harassment suit being stirred up somewhere.
Secure software: not about imagining every attack (Score:3, Insightful)
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/ [xkcd.com]).
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,
Re:Yeah, right. (Score:5, Insightful)
Not only that, but civil/mechanical/other engineers usually know exactly what they are dealing with - a Civil engineer may specify the type of concrete used, car engineer may specify the alloy of steel.
Most of the time, software engineers don't have that luxury. Video Game consoles (and still are, mostly) used to be nice that way and it was the reason they had fewer problems than PCs.
Tell a bridge engineer that he has no absolutely control over the hardware he has to work with and that it may have a billion variations, and see if he signs his name to it.
Re:Yeah, right. (Score:4, Insightful)
Not only that, but civil/mechanical/other engineers usually know exactly what they are dealing with - a Civil engineer may specify the type of concrete used, car engineer may specify the alloy of steel.
But other engineers can't specify all the variables. They have to deal with the real world - rock mechanics, soil mechanics, wind, corrosion, etc. - so they too can never know exactly what they're dealing with. Many of the worst engineering disasters occured because some aspect of the natural world was poorly understood or not accounted for. However, it remains the engineer's responsibility to understand and mitigate those uncertainties.
Re:Yeah, right. (Score:5, Insightful)
Let's see. The top programming errors are:
Let people inject code into your website through cross site scripting.
Let people inject code into your database by improperly sanitizing your inputs.
Let people run code by not checking buffer sizes.
Granting more access than necessary.
Granting access through unreliable methods.
Geez, #7 is fricking directory traversal. DIRECTORY TRAVERSAL. In 2010! It's not like your drawbridge is getting nuked by terrorists here. Generally bridges are built to withstand certain calamaties, like small bombs, fires, hurricanes, earthquakes, etc. Being successfully assaulted through a directory traversal attack is like someone breaking into the drawbridge control room because you didn't install locks on the doors and left it open in the middle of the night. Why not leave out cookies and milk for the terrorists with a nice note saying "please don't kill us all [smiley face]" and consider that valid security for a major public-facing application.
Further down the list: Failing to encrypt sensitive data. Array index validation. Open redirects. Etc, etc, etc. These aren't super sophisticated attacks and preventative measures we're talking about here. Letting people upload and run PHP scripts! If you fall for THAT one, that's like a bridge that falls because some drunk highschooler hits it with a broken beer bottle. Forget contractual financial reprisals. If your code falls for that, the biggest reprisal should be an overwhelming sense of shame at the absolute swill that you've stunk out.
And yes, security takes longer than doing it improperly. It always does, and that has to be taken seriously. And it is still cheaper than cleaning up the costs of exposing your customer's banking information to hackers, or your research to competitors in China. Stop whining, man up, and take your shit seriously.
Re: (Score:3, Insightful)
While that (and a good many of these "bugs") sounds really really obvious, consider that many apps vulnerable to such attacks started as strictly single-user locally-running versions. Yes, you want to take basic steps to make sure your users don't accidentally overwrite system files (though any "real" OS does this for you), but for the most part, you trust a local user not to trash their own files. Permissions? If a (local) program
Re: (Score:3, Insightful)
You know, that's what modern operating systems with hardware abstraction layers and APIs, and high-level development toolkits are for.
Just because it was designed with that task doesn't mean it works as designed. Not all security issues are deterministic SQL injection prone scripts and can actually be affected by timing issues amongst other things.
Re: (Score:3, Insightful)
It's funny those nazi assholes are trying to pin all the problems on developers. A background check? Are they fucking crazy?
A lot less software bugs would exist if PHBs weren't trying to cut costs all the time, assigning to the lowest bidder, establishing stupid project timelines and disregarding training, planning, documentation and tests as useless time-wasters.
Re:Yeah, right. (Score:4, Insightful)
Software bugs are logic typos. Have you ever made a grammatical error? Reading your post, I can say yes. Bugs are like that. In projects with tens of thousands of lines of code, 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.
Security holes tend to be failures to predict the way that things might "align" as to allow unforeseen things to happen. Working to specification is in no way, shape, or form a guarantee that something is secure. It is impossible to predict new security holes - if it were, the vast majority wouldn't exist to begin with. Further, when dealing with other libraries and programs (like every application on the planet), there are variables beyond the programmer's control, which might not be totally as they should be. If you know of somebody who can write specs that compensate totally for unknowns, I think you should shut up and go ask them for lottery numbers.
Come back when you have even a marginal understanding of what is involved in programming.
Duty of care NOT perfect code (Score:3, Interesting)
...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 [wikipedia.org]. Doctors, (civil) engineers, lawye
Re: (Score:3, Interesting)
T
Re: (Score:3, Insightful)
You're probably still in school, but I'll give you a break. Allow me to quote Knuth: "Beware of bugs in the above code; I have only proved it correct, not tried it."
Anyway... back to the Ivory Tower with you. The hour is getting late, and I think your faculty advisor has a cup of warm milk and a cozy set of jammies ready for you.
Re: (Score:3, Interesting)
No. Software is like locks or cryptography. There is not a lock in the world that can _never_ be broken. There's not a crypto system ever invented that will _never_ be broken - at least not if people give a damn about getting in. That's why locks are rated based on how long it would likely take to crack them. And crypto systems are continually upgraded - because it can be practical on today's computers and secure for the next 20 years or so, or it can be secure for maybe 100 years but take three days to enc
Re: (Score:3, Interesting)
Common misconceptions. It is indeed possible to have perfect cryptography (http://en.wikipedia.org/wiki/One-time_pad [wikipedia.org]), encryption time does not scale with encryption strength as you might expect, and modern ciphers with reasonably long keys are very fast, and are not expected to be broken anytime in the near future. Brute forcing a 256bit key is impossible in this universe with the laws of physics as we know them, and DES has been around for over 30 years now with no major breakthroughs. Using AES-256 yo
Re: (Score:3, Informative)
Brute forcing a 256bit key is impossible in this universe with the laws of physics as we know them
RSA keys up to 768bit have been broken: http://en.wikipedia.org/wiki/RSA_Factoring_Challenge [wikipedia.org]
The RSA-100 challange, which had a strength of 300 bits: "It takes four hours to repeat this factorization using the program Msieve on a 2200 MHz Athlon 64 processor."
http://en.wikipedia.org/wiki/RSA_numbers#RSA-100 [wikipedia.org]
Re: (Score:3, Interesting)
Bad analogy. There are, in fact, several crypto systems which have never been broken, and aren't likely to be broken until quantum computing is practical, and maybe not even then.
Quick summary of my position: Software can be made invincible. The cost of doing so is prohibitive, especially given the amount of legacy code we have to work with. New tools like garbage-collected languages and ORMs which properly abstract SQL away can help, a lot, to reach that middle ground (instantly eliminating two of the top
Re: (Score:3, Interesting)
Look, I am not going to talk down to or insult you as most of the replies have, but you have to realize a couple of things:
Re:Yeah, right. (Score:4, Insightful)
Specification -- what specification ?
When engineers make a new airline/bridge/circuit, they model the entire thing on a computer first. The CAD model is an unambiguous model of the plane. Important subsystems in it are modelled and analysed independently and in conjunction with the components around it.
So, if writing software was similar, we would first model the software on a computer. Oh, er, wait a moment. In an important sense, software is the specification. The only unambiguous specification is the actual software [otherwise we could make whatever was used for the specification be the programming language].
When someone designs a bad aircraft, the design is modelled, flaws are found and the design is improved. Nobody builds the thing until they feel pretty sure the design is right. However, software is often bad for the same reason that an initial design of anything else is bad. If it was equivalent to an airplane, windows 95 for instance, once designed, would never have been built. However, once the design for a piece of software is complete, one has created the software. With software there is no meaningful way to separate the specification and the implementation.
So, the question boils down to: how much time/money do you want to spend ? The answer from the client is generally 'as little as we can get away with'
Comment removed (Score:5, Insightful)
Re: (Score:3, Insightful)
Formally correct software does not fail in the sense that it 'suddenly' stops working. If it has a 'bug', then the 'bug' has always been there. That's what I mean with failing, because the parent of my post made an analogy between bridges and computer programs. An
Errors, Schmerrors (Score:5, Funny)
A real programmer can do all 25 in one line of code.
Re:Errors, Schmerrors (Score:5, Funny)
#include "win32.h" /* :p */
Alanis ? (Score:5, Funny)
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.
I bookmarked this immediately (Score:3, Interesting)
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.
And Number 26 ... (Score:3, Funny)
Bad Idea (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
Re: (Score:3, Interesting)
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.
Yeah, but you can keep them from doing it again.
The reason people don't use these well-known techniques is very simple: it takes time and effort, and people are lazy. So until the customer tells them to, they won't bother.
Which brings me to my biggest objection to this proposed contract. There's lots of documentation requirements, and no assignment of liability. Documentation is expensive to produce, and much of this I really don't care about. (Exception: the document on how to secure the delivered soft
Re:Bad Idea (Score:4, Insightful)
Yeah, but you can keep them from doing it again.
The reason people don't use these well-known techniques is very simple: it takes time and effort, and people are lazy. So until the customer tells them to, they won't bother.
Which brings me to my biggest objection to this proposed contract. There's lots of documentation requirements, and no assignment of liability. Documentation is expensive to produce, and much of this I really don't care about. (Exception: the document on how to secure the delivered software, and security implications of config options, is an excellent idea.) For most of the documentation requirements, I don't really need to hear how you plan to do it: I just need to know that, if you screw up, you're going to be (at least partially) financially liable. And yet, the contract fails to specify that. What happens when there *is* a security breach, despite all the documentation saying the software is secure? If the procedures weren't followed, then that's obviously a breach of contract — but what if there was a problem anyway?
I actually like designating a single person in charge of security. Finding someone to blame after the fact is a horrible idea. However, having someone who's job it is to pay attention early, with the authority to do something about it is an excellent way to make sure it doesn't just fall through the cracks. By requiring their personal signoff on deliverables, you give them the power they need to be effective. (Of course, if management inside your vendor is so bad that they get forced into just rubber-stamping everything, that's a different problem. But if you wanted to micromanage every detail of how your vendor does things internally, why are you contracting to a vendor?)
I don't agree there re the lazy comment. The reason poor coders release insecure code is because they are lazy. For the rest of us, it is generally because we are told we MUST release X features by go-live date. Go-live date will not slip under any circumstances. X features are non-negotiable for go-live date. The project manager (not the development PM, the project owner) has assigned a certain period for testing, however this testing is never SIT or the such, it is usually UAT of a very non-technical nature and the devs time is spent on feedback from UAT. Development itself has virtually no proper regression / SIT / design time factored in. The development team are never asked how long realistically something will take, instead some non-technical person will tell them how long they have and then tells them to figure out how to make it happen. Specs will change continuously throughout the project so a design approach at the beginning will be all but useless at the end after numerous fundamental changes (got this one on a project I'm working on now - had my part finished, fully tested and ready to deploy about 3 months ago, then change after change after change and I'm still doing dev and if I mention that I need time to conduct SIT / regression testing I'm told "but I thought you fully tested it already a few months ago?"). This leads a dev with a fast approaching deadline, who doesn't have the authority to say "no, this won't give us enough time to test properly" and the emphasis on being feature complete rather than a few features down but fully tested and secure.
This of course does not even touch on the subject of what happens if a third party library or other software sourced externally has vulnerabilities. Can you in good faith sign off that you guarantee a piece of software is totally secure without knowing how third party libraries, runtime environments or whatever were developed? This is not just isolated to open source, try holding MS liable for a security vulnerability that was uncovered after you deployed and see how far you get. This then starts taking us out of the realm of absolutes and into the realm of "best practices" etc. So how good is a contract that expects the signatory to follow "best practi
and yet they do not mention COBOL (Score:2)
The obvious follow-up question... (Score:2)
Oh, you mean VENDORs, not DEVELOPERs (Score:2)
When you say "developer", I think individual employee. However, the individual employee isn't around long enough, the project validation will more than likely happen after the majority of them have finished, taken their final pay and left.
As for the actual contract? It reads like lawyer bait.
Consistent with the provisions of this Contract, the Vendor shall use the highest applicable industry standards for sound secure software development practices to resolve critical
security
They missed one (Score:2)
Just Show Me the List!! (Score:5, Informative)
So much shit. So much commentary. Just gimme the list? Here it is:
Re: (Score:3, Informative)
What's sad is that SQL injection and good old primitive buffer overflow still top the list...
Regarding #2, I'm inclined to blame PHP for that thing being so high up there. Its standard library way of handling parameters in SQL statements has long been lacking - and while it's definitely possible to get right, and there are frameworks which make it easier, too much "HOWTO" and "learn in 24 seconds" PHP code out there is written without any regard to injection possibility, and it gets blindly copied over and
Re: (Score:3, Informative)
Typically such a flaw appears in web applications. As such, the attacker does not have access to the local machine, and such an attack gives him information would could aid him in gaining access (usernames).
Sanitization is a worrying term to use. (Score:3, Informative)
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.
Re:Sanitization is a worrying term to use. (Score:4, Informative)
Use prepared statements. A prepared "INSERT INTO FOO (BAR, BAZ, BIFF) VALUES (?, ?,?)", along with parameters from the user, is safe from SQL injection attacks, no matter the parameters.
Unfortunately there are a few cases you can't do that. No way to use a prepared statement for an "IN" clause, for instance.
Lol @ Dangerous (Score:3, Informative)
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.
Actions speak louder than words (Score:3, Insightful)
"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."
What it's like to do software like that (Score:5, Interesting)
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.
The most dangerous C programming error (Score:5, Funny)
launch_missles ();
Re: (Score:3, Funny)
//Fixed.
void le_nap(void)
{
sleep 500;
}
if (alert_code = red)
{
if (le_tired) le_nap;
launch_missles ();
}
Wrong approach. (Score:3, Interesting)
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.
The 25 most dangerous programming errors (Score:3)
1. PHP. ...better stop there before I get modded into oblivion.
2. Visual BASIC.
3. Perl.
4. C.
5. C++.
Blame HTML and the browser for XSS. (Score:3, Insightful)
Re: (Score:3, Interesting)
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 dra
Re:Background checks are awful and stupid (Score:4, Insightful)
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.
Re: (Score:3)
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).
Re: (Score:3)
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.
Re:Background checks are awful and stupid (Score:4, Insightful)
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.
Re: (Score:3, Insightful)
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.
Re: (Score:3, Informative)
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 pr
Re: (Score:3, Interesting)
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