Why Coding Is Insecure 176
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."
This discussion has been archived.
No new comments can be posted.
Why Coding Is Insecure
Related Links Top of the: day, week, month.
Intel CPUs are not defective, they just act that way. -- Henry Spencer
Coincidence ? (Score:2, Interesting)
The article states that security holes are inherent to developement. That's OK, but what about their frequency ? Have a look at, let's say, Apache vs IIS
The question isn't if the code has security flaws. It certainly has. The point is the methods you use to avoid it. I think OpenSource has a way of resolving sercurities issues. OS has an army of benevolent geeks at his disposal. Competent people that know how to write a patch or at least submit a bug report.
On the other hand, MS only proposed a bug report interface with the recent XP.Sorry but, a Bill Gates company-wide memo to write better code is a PR operation, not a method.
new era (Score:2, Interesting)
All code attacks are nothing but an attempt by people to maintain illusions of superiority: "I must be a better programmer than Linus Torvalds because I can sabotage his work." It is the vandal throwing paint on an existing painting and saying "See I am an artist too". No, if you were a better programmer than Torvalds you would have written a better kernel than he wrote.
People become 'elite crackers' because it is much easier to do destructive things than constructive things; buildings are much easier to tear down than to build in the first place. Because of the asymmetry of the effort involved they get the illusion that they are superior to the people whose code they are cracking.
There is a lot of frustration in youth; the discovery that there are people who have done
much better work than you have ever done - or will ever do - leads to an illusion of inferiority. People attempt to counter that illusion with an illusion of superiority. Not everyone can be as good a coder as Alan Cox - I know I am not even vaguely in his league - but that doesn't make me feel inferior; just different. Nor does being a better coder than most people make me feel superior to them; just different.
Knowing and understanding your limitations and weaknesses is just as important in life as knowing your abilities and strengths. Most people try to hide their limitations and weaknesses from hemselves rather than exploring them, and that is a serious error; you can only do that by lying to yourself. Lying to yourself - when you don't even have a clue that is what you are doing - is a miserable way to go through life.
Go functional? (Score:3, Interesting)
You might want to investigate functional programming languages, such as ML and Haskell, then. They do have a very different approach, one that is much more easily proven to be correct. It also has several other demonstrated advantages, including very much faster development and shorter code to achieve the same results as traditional programming methodologies, in several case studies/competitions. Try looking at the ICFP programming contests for the past few years for some very interesting reading. (A quick Google search will turn up all the homepages straight away.)
The big thing holding them back right now isn't technical merit, it's lack of "critical mass". Most managers and senior development types simply don't do enough homework to know about these things and the potential advantages they can offer. But if you're programming purely for recreational reasons, there's no reason you can't play with the best toys. Free compilers and libraries are available for many of these languages. Happy coding...
Reflections on Trusting Trust (Score:1, Interesting)
Look no further than his excellent paper "Reflections on trusting trust" that he wrote for his Turing Award Lecture in 84.
There's a copy online at http://cm.bell-labs.com/who/ken/trust.html.
Good read. Timeless!
Here's an excerpt:
"The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code."
Re:Inexperienced programmers and C/C++ (Score:1, Interesting)
Why use char* when you can use std::string (or your own string class).
I went into a big Visual C++ project this year, after an education mostly on Solaris and BSD, and found the answer to that question: because anything that comes after std:: in the Microsoft libraries, such as the STL, is likely to be riddled with bugs to the point where it becomes unusable in anything but a trivial sample program.
Of course, in retrospect, this is to be expected, because after all things like the STL are supposed to be cross platform, whereas Microsoft provides plenty of Windows-only alternatives. (Not std::string! CString!)
In the end I delayed my project by 3 or 4 weeks ripping out perfectly reasonable STL code that triggered library bugs and replacing it with my own lists and vectors that in the end relied on--yes--good old char*s, arrays, and their friends.
Re:Inexperienced programmers and C/C++ (Score:2, Interesting)
I've heard that VS.NET has much better STL support. I'll check it out later, and if it is ok I'll upgrade.
The problem with M$-only code is that it is not standard, and ugly as shit. The reason people are using it is that it was their only alternative at the moment. It is beyond my understanding why people actually are pleased with MFC. Of course there is a lot of 3rd party components which uses MFC, but don't people have portability in their minds at all when they write stuff? Ufortunately I've been modifying a MFC-based application at work, and it has not been a nice experience. I didn't have to change the ui though, but the macros and type-checking stuff was ugly :)
My point in the previous post was that writing such classes should be done by people that know what they're doing. I've written lists, arrays and string classes at work with late-copying (copy-on-write). Lists and arrays with late-copying may boost performance, readabilty and robustness in a program. Returning a large array of data from a function is done almost with no penalty now. Another reason to use such container classes is that you're 100% sure that they work and that they will report an error (suchs as array bounds write) exactly when they happen with no need to use a analyzing tool like Purify.