Slashdot Mirror
Why Coding Is Insecure
Stuart of Wapping writes "Even patches are not safe, especially if they come from a closed background (maybe) - An interesting article on why coding, is naturally insecure, from SecurityFocus."
← Back to Stories (view on slashdot.org)
The root of the problem lies in the fact that the program/product has to be released by a deadline. Causing common sense and good coding practise to be thrown out the window due to the fact that you'll lose you job if you don't do it.
Deadlines are normally imposed by companies trying to earn a living through the development of software.
Then it would be a good idea to think that the Open Source community, not faced with deadlines, would be able to code the programs in a more ideal situation, leading to code that has a higher degree of elegance and security than code developed by companies attempting to make money from it.
Then you have the flip side of that, where the software may perpetually never reach a state of stableness since it is contunually in flux. But, how you view this state is totally dependant on your point of view.
At least the code in flux has a higher chance of adapting to it's environment and thus surviving over the slower to adapt Closed Source code.
Often the designer doesn't consider the bigger picture, how this piece fits it. It can be as simple as not requiring verification on input.
Coders if rushed, inexperienced, or simple bad (like rafts of people who suddenly became "programmers" in 1998-2000 when demand was extemely high, even though the only had a couple classes and were really english, anthropology, history, or other majors, just to fill positions) will fail to see the lapses left by designers and build porous code.
Lack of review or review that so anal it's focus is spelling errors in prompts or whether there's enough documentation lines, but fails to identify where secure practices are not followed. Well, don't get me started. ;)
Last, Q/A, everyone knows Microsoft's Q/A is called ship it out and let customer support pick up the bug reports and then sometimes charge the people reporting for the fix. Q/A is often the first department cut in layoffs, because management underestimates its importance. To bad, like the Enron execs, they won't take a cut themselves to save the product and the company. Good Q/A needs to ask the unthought of questions, what happens if I do this instead of what's expected?
Perhaps somewhere in the evoltion if IT that has lowered programmers from the status of mystical wizards to grunt code jokeys, management will recognize that code, even new products, aren't just some big patch and give it the attention and personnel it really deserves.
A feeling of having made the same mistake before: Deja Foobar
To have any hope of writing secure software, a programmer first has to be aware that a problem exists. Aware of issues like safely handling user input and securely transporting data (and when it's appropriate and when it's pointless).
Once a programmer is aware of the existance of these issues he can start learning about all of the technical problems of writing secure code. In a UNIX environment, it's things like not exposing unnecessary parts of the filesystem to external users, and not blindly writing to files in /tmp, and not trusting your PATH or your IFS in privileged scripts.
Forget focus, we need education.
Suddenly design and coding style are thrown out the window in favor of down and dirty "do what works, we'll fix it later" coding. Initially some of the more idealistic (and typically youthful) coders feel that this sort of programming is wrong; this feeling usually passes quickly under the tutelage of the more experienced team members.
When code has to be done before a certain deadline (usually yesterday), this kind of shit always happens. I happen to be one of those idealistic (youthful) coders, and cringe thinking about what sometimes goes into released software. Is it any wonder why there are so many bugs in software? There is never even time to design, let alone test.
Why does this happen? No one really has perfected the art of accurately estimating projects. So you end up taking a quick look at the project's complexity, compare it to something you did before, and tell them how long that previous project took. Then when you give sales/management the time estimate (which is usually bogus anyway), they just ignore it and continue on with their own schedule.
Then you have sales/marketing types who consider software to be "magical." They don't have a clue how it's designed, written, and tested. All they see is something in a box that they have to sell. So when they ask for more features (as if you simply add them like you add flour to a recipe), and an engineer tells them that rushing it out may lead to security holes, etc. etc. they blank stare.
caused by the C libraries poor implementation of strings, and by the lack of any runtime bounds checking?
The argument that these things slow down code too much doesn't make much sense, considering that we have to do the runtime bounds checking ourself, everytime, and that we occasionally make mistakes.
I think that it is time we drop all insecure functions from the standard C library and replace the library with a bounds checking version that also was more complete and consistent.
It would also be interesting to have a taint flag on the standard C compiler like the perl compiler has to detect when people are using user input as format strings and the like, without cleaning the input first.
-- Never make a general statement.
Consider, however, software engineering. The platform you use, the language you speak, the tools you employ -- they all evolve over short time scales. None have had a century or more of Darwinian pressure applied. No one expects them to work, fully. The liability for failure rests with the company or person using the software, not with the company or person writing it. We haven't had the time to develop the technical or social methods for preventing bad software and reinforcing good software.
How many computer programmer professional societies require rigorou entrance exams and periodic proof of competency?
This will continue until the costs are brought back to the companies that write insecure code. This can happen through government regulation -- the creation of a "software building code" -- or through the dead hand of Adam Smith -- companies start to avoid purchasing insecure software.
The greatest sign that this sort of sea change might be a-coming? The fact that Microsoft feels there is enough market interest to attempt, at the very least, to jump onboard a PR train.
The Mongrel Dogs Who Teach