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 am a competent and trustworthy programmer in his late 30s who will fail a background check because I was convicted of something in my mid 30s, something I did when I was a teenager (and still a minor).
I have, over the years, been given many responsibilities and opportunity to abuse the authority required to discharge those responsibilities. I never once have abused that authority. If you ask previous co-workers if they consider me honest and trustworthy they will unanimously tell you that I'm one of the most trustworthy people they know.
I strongly resent the growing prevalence of background checks. I wasn't convicted of any sort of fraud or theft, but I am rejected anyway. The sad part is half the time I end up having to tell someone exactly what I was convicted of and why, and they wring their hands over their policy being so stupid but follow it anyway.
Background checks lead to stupid behavior. The criminal justice system is only a mediocre to poor arbiter of who is and isn't trustworthy. Like lie detector tests, you can never pass, only fail.
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!
cat
So much shit. So much commentary. Just gimme the list? Here it is:
How we know is more important than what we know.
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.
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.
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.
I don't get why CVS/SVN/etc even should deal with security. They're source control/management systems. For public pull/fetch/get-only servers, no password is required. For situations where security, is required, set up SSH access, or some other secure access (and use an ssh keyagent if you don't like typing your password in heaps).
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.
_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: I've set up git->svn translation systems for use in such locations, because such sites are usually so stupid they do all their work in "trunk", anyway, and the gateway works fine there.
Since at least 1.6, Subversion uses the relevant keystore sub-system on all major OSs - e.g. KWallet on KDE, GNOME Keyring on GNOME, etc. Prior to 1.6 I believe only Windows and OSX used native keystores. Regardless, the password was stored in the user's home directory - which, with proper/normal permissions is inaccessible to anyone other than the user and root.
This article is Linux-focussed, but discusses Subversion's use of Linux keystores.
Incidentally, CollabNet aren't the maintainers. They originally developed it, continue to provide devs for the project, but Subversion is an Apache project. Even before coming under the ASF umbrella it was its own project. Describing it as a CollabNet project is like describing Linux as a project of Linus' current employer.
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
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
I agree with this, but in practice I have found that it can lead to a lot of bug fixing if you don't have a complete understanding of what valid input looks like. For instance, in one project I was validating some input that should've been user names. I initially allowed for two groups of letters separated by space characters. Later I found out that some people had multi-part first names or last names that had spaces in them, so I had to account for multiple groups of letters. Later, I found out that some names have punctuation in them like . or ' or -. Eventually it got to the point where I was even allowing () because the name field was being used to distinguish between different people with the same name.
The lesson I learned from this is that if you don't have to interpret the data, you are better off just escaping any special characters and working with it that way. Aside from limiting the maintenance you may have to go through, it allows the users to enter whatever they want without arbitrary restrictions on characters.
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.