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."

Comments

Root of the problem

[dezwart]

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.

Wrong conclusion

[Ben Jackson]

The author's conclusion is that insecure software is a result of a lack of focus on security. The real problem is programmer ignorance about the fundamental issues and the technical details of writing secure software.

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.

He nailed it.

[Anonymous Coward]

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.

Aren't most security holes

[buckrogers]

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.

Software Engineering not yet Engineering

[gilroy]

Software often blows up. Bridges tend not to fall down. Why? Because the field of civil engineering has matured greatly. We know a lot about why bridges falls down and how to avoid it. There are standard tools, standard analyses, and standard, well, standards. We also have some regulatory oversight over construction projects -- construction code and occupancy code. These don't guarantee success, but they usually throw a spotlight onto cost-cutting and corner-cutting as causes for failure.

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.