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)
Most code can be de-complied or unassembled, if people have enough time / money on their hands.
Cruise TT
It's damn good that bridges and high rise buildings are not built the same way as software...
The owls are not what they seem
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.
The article is surely right about their comment about the throw-away mentality with assignment. But there are exceptions: at my University there is a so called "Software Engineering" degree, where the emphasis is on good code with good documentation and many test-cases. Correct code only amounts to 50% of the final mark; the other half comes from documentation, comments, testcases and how well you followed the style-guide. I quite like it, because the assumption is that basically all software in todays world simply sucks.
-- The plural of 'anecdote' is not 'data'.
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
Just to be on the safe side, we should probably outlaw compilers too. There's no telling what a malicious hacker might be able to do when he has hacking tools like gcc to write deliberately insecure code and run it on machines.
Is your company running tools written by ma
Security Focus is redirecting to google. Which has a cache of the page, please use that instead.
w C: www.securityfocus.com/infocus/1541+&hl=en
http://www.google.com/search?q=cache:M13ch6-wvb
Strange but this article, albeit raising some intersting issues, seems to focus on excusing Microsoft flaws in developpement.
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.
The day that Management stops counting beans will be the day that the US stops being a Capitalist economy.
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.
i believe the key to having good code is to have multiple people write and critique it. (hint: open source)
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.
From the end of the article:
:)
"However, there may be a light at the end of the tunnel. Recently, Bill Gates issued a company-wide memo to all Microsoft employees dictating that from this moment forward, security will be a programming priority"
Oh, that's all right then
yes, we have no bananas
I am a network engineer in a large manufacturing firm, and I can tell you that the cook is only as good as his ingredients - if the patches are, well, patchy, then the network and higher-end systems architecture will be insecure, no matter how many patches are installed. There is only so much that a network or systems guy can do before (or unless) he sees the actual code and can address the issue from there. Remember that not-so-famous patch that Microsoft put out last summer, only to release a patch for that patch? That was where the dam finally burst for me.
Where I work there are people, people who're responsible for an important part in a project, who can't understand why returning pointers to variables on the stack (from functions in c/c++) is bad. When this happened to one guy, he blamed the library he was using (an in-house library we're currently developing). When a colleague checked out the code he was horrified that the guy did just that, returned a pointer to this local variable.
But how do you differentiate between good and bad programmers? First of all I think a good programmers have to really enjoy programming. When I went to college (software development degree), I coded a lot of stuff in my spare time (I'm not saying that I'm a particulary good programmer, but at least I'm better than some of the other guys at work :). Not everyone does that, some hardly complete their programming assignments. This means that after some years of college, they will get their degree but they can't write a good program. But they will still get a job.
When writing software, especially in C, C++, you have to have a good knowledge of how stuff actually works. How virtual functions work, the difference between the stack and the heap, what happends when objects get out of scope and stuff like that. This stuff may be a boring part of the programming course, but it is actually very important. One problem is that in some places people don't learn C or C++ at all, only Java, and thus they don't need to learn most of this stuff. (Although they maybe have to learn a lot of java-specific stuff, such as how the garbage collector works etc).
The problem, as I see it, isn't that there are too many inexperienced programmers, just too few of the good ones. Another problem is the tool. Many projects is written in C or C++, which pretty much allows you to do everything. It is possible to write robust programs in C++. If I should manage a large C++ project, one of the first thing I would to is to ban almost all use of pointers and C-style arrays. Smart pointers with reference counting, array-classes with optional boundschecking and things like that. Why use char* when you can use std::string (or your own string class). Another solution is to not use C/C++ at all, but in many cases this is just not an option. And I think that C++ is a really powerful language, which with a tiny bit of effort by the programmer(s) can be a robust language, even for "newbies".
The article pinpointed some of the main causes behind insecurity well: bloat (integration of unrelated functions) in single programs exacerbating insecurity which is in turn exacerbated by integrating several bloated programs with each other.
I feel we need to return to the old Unix model of one program, one function. Small programs that do one thing well are a lot easier to debug and make secure.
"Integration" could be attained by making several small programs collaborate according to open standards. It's got to be possible somehow to do this *and* attain the level of user friendliness today's lusers expect.
[Before you all yell "UNIX pipe", it actually has to be usable by the average mouse-clicking Joe. The challenge is making this work well with a GUI. Nobody has managed this so far, but I believe it's got to be possible.]
For example, a GUI-based word processor would by itself include only the bare-bones functionality, such as text editing and basic layouting. It would not include a spell checker; the spell checker would be a separate GUI program which can collaborate with the word processor using an open protocol that would regulate permission to insert a menu item to invoke the spell checker and edit the text directly in the document, without the need to save it to disk first. (MacOS users might recognize Word Services in this description.)
Another obvious advantage, beyond security, is that power users could construct their own working environments from such applications - e.g. using a different spell checker or text editor. Using the different basic programs in various combinations would in turn expose more bugs, improving security.
To keep this user-friendly, collaborating programs could be bundled into application folders, much like Mac OS X does already with the files belonging to one application. Opening the folder would launch all the contained programs at once. (Or perhaps the user could define a "master" program that is launched in the front, with the "slave" programs launched in the background and invoked as needed.)
If open, GUI-based collaboration protocols exist for every imaginable type of functionality, you could combine ("integrate") as many small, well-tested and well-functioning programs of different manufacturers as you want, to give the impression of a big integrated package, without compromising security.
Of course, fat chance that such an idea would go mainstream in the near future, as it would mean the end of the Micro$oft business model. (Imagine! No need to upgrade the entire package and take loads of unwanted extra junk just to get that one function you want!)
Apple tried something rather like this once with OpenDoc, but it was not as open as the name suggested, plus it was bloated, plus the user was not ready for its extremely document-centric model (which is not part of my idea above), so it failed. I think this model deserves a second chance, done right this time - the Open Source way.
"Well, duh."
In my opinion, the article is extremely badly written. Also, it is nonsense, as is easily proven by giving a link to another operating system:
Open BSD: Four years without a remote hole in the default install!
If the Open BSD team can make a secure operating system as volunteers, Microsoft, with a reported $33 billion in the bank, could take one of those billions and clean up their code.
Microsoft's security problems come partly from feeling that they don't have to care, apparently.
Also, maybe there is some secret U.S. government surveillance agency that requires that Microsoft operating systems not be secure. For years the U.S. government tried to prevent cryptography. For example, see these notes from the Center for Democracy and Technology: An overview of Clinton Administration Encryption Policy Initiatives. The notes say, "The long-standing goal of every major encryption plan by the [U.S. government] has been to guarantee government access to all encrypted communications and stored data."
It is not impossible that software insecurity is secret U.S. government policy. The U.S. government is involved in many hidden activities, as this collection of links and explanation shows: What should be the Response to Violence?
Bush's education improvements were
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.
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.
This article is really about why coding on deadlines is insecure. It overlooks developer-controlled projects that are done when they are done.
Coding Blog
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
This article says nothing whatsoever about why coding is naturally insecure. It says that Microsoft is unable to write secure code. Well, duh!
Actually, coding is not inherently insecure. There are a couple of good counter examples (qmail and djbdns, for example).
Microsoft's code is insecure because this way customers can be made more dependent on them. And each time they download a patch, they get a big Microsoft logo in their face. Talk to a PR specialist if you don't see why this is good for them. Besides, there is no incentive to make bug-free code. Nowadays customers are so used to broken code that they actually believe that it can't be any different.
After considering policies like the one below, it is not difficult to imagine that there may be a U.S. government agency that wants Microsoft software to be insecure.
Page obtained as a result of the Freedom of Information Act.
It says, "I am here as a special envoy appointed by the president and reporting to the special Deputies Committee of the NSC."
"Our goal is a world in which key recovery encryption systems are the dominant form of technology in the commercial market."
At the time, there was no public discussion that the U.S. government was doing this.
Bush's education improvements were
Note that "local" is NOT "remote".
It is assumed that you can trust your own staff more than you can trust all the hackers on the entire Internet.
Bush's education improvements were
I am only a recreational programmer. But recently I have been writing code, and in the middle of the night, I suddenly think of a security hole. I write in C, and it is just too easy for buffer overflows and such like to slip through, even if you are thinking about them as you program. In the end, it was not that hard for me to batten down the hatches in my code, but it was a small program, and I had no time pressure.
It seems to me that we need a new approach to designing code - an approach where things like checks for buffer overflows are automatic in the program design. I have heard of an approach (I heard this maybe 20 years ago) where you "prove" the correctness of the program as you go along. The approach of "proving" the program cannot work for all programs, because of Turing's halting theorem. But most programming tasks could be written in such a way that they could be proven.
As applications become more and more complicated, it seems to me that some very clever person needs to rethink the whole way in which we designed programs. Possibly a very creative breakthrough approach is required.
Although nobody can prove that one OpenSource OS is more secure than the other. OpenBSD has had its share of security flaws just like every other system. FreeBSD 4.3 & Linux 2.2.15 came to mind.
Linux 2.4 hasn't had a serious security flaw yet. And it is at a 2.4.18 (patch) level. Which is a better record than the 2.2.x series.
Any program ftp/httpd/smtp, that has a security flaw, effects ANY UNIX based system that uses it. Unless the flaw is OS specific.
--------------------------
Is this a sig?
--------------------------
There are only three causes of insecure code:
1. Developers' ignorance.
2. Developers' stupidity.
3. Selling underdeveloped software.
Contrary to the popular belief, there indeed is no God.
Two points:
1. Software is still a lot better, and a lot more secure, than the alternatives. Imagine running an insurance company without it.
2. Most of the trouble with software is just overarching ambition. There's no way that millions and millions of lines of interconnected code will ever work consistently, reliably, and securely. But it's just too tempting to add more features, more chrome and tail fins, than to concentrate on the problem to be solved and remove everything that doesn't help solve it.
Yes, and that's why we have C#.
Your argument that you have to do your own bounds checking, every time, is wrong. If you have a good grasp of the C language, you should be able to code perfectly secure programs that only perform bounds-checking on external (e.g. user-input) strings.
C is a lot like X: the people who criticise it are exactly the people who don't understand it. If you want bounds-checking, use bounds-checking. If you want garbage collection, use garbage collection. If you want the specific warnings that you've mentioned, use lint. ALL OF THESE TOOLS ALREADY EXIST AND ARE IN COMMON USE. It's alright if you're ignorant of these tools, but for heaven's sakes don't blame the C language for them.
... is gonna get it at meta-mod time.
I am also one of those young, idealistic coders. I work in a team of seven people, with two senior developers, four junior (including me) and a project management type who works with the two team leaders and handles a lot of the paperwork and client contact.
I have always maintained that "quality is free", and for two years on this project, I have been proving it. I now get assigned far more than my fair share of the more challenging/high risk tasks, because they know I'll get it done, and it'll work in the end (or at least if it doesn't -- hey, no-one's perfect :-) -- it'll be easy to fix).
The old-timers, after making the usual comments about "can't do it that way in the real world, son" or "that's just not what happens", are slowly but surely coming around to acknowledging that actually, you can. I recently had a performance review, in which my manager recorded three things I think are really important here. First, I am prepared to look critically at multiple designs and pick the one that works best for the task at hand. Secondly, I do test things thoroughly. Thirdly, I do generate rather more than my fair share of the output from the team. I don't think these facts are independent.
Of course, I'm blessed with immediate management who are smart enough to let me get on with it. Sometimes they raise concerns about what I'm doing, particularly where I prefer a strategy that on the face of it looks like a bigger risk but in reality is likely to pay off much more. After all, it's their job to raise those concerns, and mine to address them. But generally, if I have a good argument in favour of my choice, they leave me be. I'm sure they still mumble things about "can't do it that way" under their breath occasionally, but the results are clear for all to see.
I think I am living proof of the fact that quality is free. Well, actually, it pays refunds... "Best practices" are called that for a reason, and it never ceases to amaze me how few people in business get it, and how much money is wasted as a direct result. Hey, if I can do it, there's no reason other people can't. All it takes is management with a couple of brain cells to rub together.
There is always time to design properly and test. Good design, implementation and testing takes a lot less time than bad design, botched implementation and rushed testing. You just have to have enough faith to do it, and resist the management bull that is short-termism. If you can do that and get the results for long enough, then you'll establish a level of credibility that commands the respect of your superiors, and you've won.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I do some beta testing for various sorts of projects. I have a reputation as "the tester who can break anything", for good reason: I often do the unexpected (ie. whatever came into my head at the moment) and thus expose hitherto unknown bugs.
More often than not, the response from the coder is "You aren't supposed to do that!" not "Ooops, I need to fix that."
Yeah, that's real useful if the idea is to produce a stable product that users can't break just by doing random things.
~REZ~ #43301. Who'd fake being me anyway?
Yes, and that's why we have C#.
;-)
I was going to learn C#....so I opened up one of my Java programs, and replaces all the "String"s with "string".
Thomas Galvin
IMHO, there are three chief reasons code is vulnerable.
.ini file get's nabed, it probably isn't as big a deal as if the entire system registry gets nabed.
Time. The article was right about this one. If you look through our source code, you can see a definate difference between the "we've got all the time in the world, so follow the style guide to the letter, comment everything, and desk check it all before you send it to test" code and the "beta is due on Monday, so tell you girlfriend to have a nice weekend, and could you get some Code Red on the way in, we're going to be here a while" code.
When you are trying to get code done fast, one is much more prone to looking only at the stated goal of the code (i.e. it takes file X, converts it to format Y, and sends it to machine Z) and ignoring things like modularity and security. One tends to be much more concerned with "how do I get this to work" than "how can some one get this to break".
Ignorance. I don't know a whole lot about buffer overflows, or gaining root when I shouldn't have it, etc. I've got a book on it (which I'm sure my sys admin would love to see sitting on my desk), but the fact of the matter is that most colleges don't doa whole lot of teching in this area; what people know about security holes is usually because they hack around (either on their system or someone elses), or they got hacked. The industry would be a lot better off if schools were teaching woul-be programmers what people will try to do to their systems, and how to avoid it.
Over Reliance on the OS. At least in Microsoft's case, I beilieve they are trying to do too many things at the OS level, which means a security flaw that effects one program can often be opened up to exploit all programs. Take, for example, the registry. If one program's
Thomas Galvin
Developers who are more inclined to write secure code seem to come from a background that involves administering free UNIX systems in the mid-90s. This is when we started seeing an explosion in the number of nodes attached to the internet 24/7, most of them running a freenix. We were first to bear security problem onslaughts that everyone now deals with today. A sneak preview.
We had to deal with release after agonizingly insecure release from Berkeley, Washington University, Carnegie Mellon. Deal with urgent "security patches" that simply add bounds checking to strcpy, and praying to god that we get our bugtraq email before the script kiddies have figured out how to uncripple the exploit code.
Servers being attacked just because one user was running an IRC bot in a channel some teenage punk wanted to take over. ISPs being knocked off the net just for running an IRC server. Spammers, denial of service attacks, buffer overflow exploits, rootkits, social engineering, man-in-the-middle attack, password sniffing, brute force cracks, .
Developers who lived through this find that the rest of the world (ie, the people starting to do serious stuff on the internet today) are blissfully unprepared for the security onslaught. More NT servers are connected now than ever, ASPs are coming to the harsh reality that they have 40,000 lines of insecure trash running their web site, home users completely unaware that their broadband "always-on" connection really means "always-vulnerable".
The only common traits we share are cynicism. Cynicism for all developers, all companies, all users, everyone. Hundreds of security holes being introduced every second. Every gadget you buy, every shopping cart you push, your comb could have a buffer overflow, careful! that milk might be sour!, oh no! quiet or the cake won't rise!!! they're crawling all over my skin--get them off get them off, use the ice pick use the ice pick!!$%*)!@!!
If you as a programmer don't see the world that way, don't expect to write anything but insecure garbage. But don't worry, you'll learn your lesson just as we all did. And don't be mad at us if we laugh, because we're laughing with you.
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
It's a stupid argument. If you profile all of the programs on freshmeat, 95% of them will be bound by interactive user input, or disk, or network, or memory, not CPU.
Unless you have a specific need or die-hard preference, most programs today should be written in a high level language. If you even have CPU bottlenecks, you can rewrite the hotspots in a lower level language--kind of like how people used to optimize portions of C code by rewriting it in assembly.
I suggest Python. ;)
"The Microsoft campus contains some of the most brilliant designers and programmers the world has to offer"
Statements like this are silly. *HOW* can the author say M$ has brilliant designers when all you see is the end product?!?! They could have gone through thousands of design interations, each entirely different, with no vision until they hit on something they think looks good! And brilliant programmers?!?! There are an unlimited number of ways you can write an algorithm but there are only a handful of ways to do it `brilliantly!' Do the programmers at M$ write brilliant algorithms? Well, let's check the source...oops!
I was going to learn C#....so I opened up one of my Java programs, and replaces all the "String"s with "string".
SO was I, until I realized you have to distribute a set of 20MB DLLs with your program.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
Everyone that designs a bridge or skyscraper has some of of state regulated certification, and gobs of experience/education to go with it.
Software industry is not like that. You have everyone and their brother coding in VB thinking they are the god of coding, despite not having any formal CS background teaching theory, structure, etc etc.
So you end up with gobs of "terribly" designed and structured code. A long time ago, I was working at a financial software company. I was was one of few CS people they actually had, and I was horrified at how "ugly" their code was. I'm so glad I don't work there anymore. They had some of the most "barely" functional code I'd ever seen. That company thought that oodles of string manipulations was perfectly fine, and did not comprehend when and when not to spawn threads, or even how to take advantage of them.
Imagine what our bridges/buildings would look like if a bulk of the designers had no structural engineering background, and were hired because they had "experience building tree houses" at home....
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.
Perl's taint checking happens at run time, not compile time. If you're willing to bite the bullet and let the language do a bunch of run time analysis, you ought to switch languages rather than repeating Bjarne's C-plus-bolt-ons mistake.
Greg Bacon
If bridge/building designers were hired the same way a lot of software guys are, we would've had a BUNCH more Galloping Girdies...
Ken Thompson always knew code was insecure. Almost 20 years ago. I know everyone is fucusing on DDoS attacks and buffer overflows, but we can't ignore that code is not secure on several different levels.
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."
I'm a software engineer working in a research lab position. Aside from coding, I spend a lot of time discussing various projects with various co-workers. I'm surprised that almost everytime I nitpick their ideas, their response is, "the user shouldn't be doing that", or "that should never happen"...
My philosophy is to assume that the end-user is an idiot and doesn't know what they're doing. My philosophy is also to assume that people who use my objectsare also idiots, so I design my objects as such. ie, "When you initialized that state variable, you initialized it as an int32, so when you try to change its state, I'm going to make damn sure you are giving me an int32", I'm not going to assume the developer is smart enough to figure that out. Because we all know that to assume makes an "ass" or "u" and "me"
I was talking to a coworker about this a few days ago. You can tell all your engineers to drop what they are doing for a month and focus on security, but that isn't going to do jack if these same engineers don't comprehend security. One man's idea of a secured object could turn out to be the most open object. You need to understand how security works, and the differences between: Authentication, Authorization, Confidentiality, and Integrity. Without this knowledge it will be impossible to design a secure object.
I like to put some thought into my code, before I implement something. Hence my objects are easier to use and extend, hence I get more challenging tasks.
;)
Also, the reasons you state, is why I like working in a lab/research group, rather than a product driven group. We don't have those arbitrary deadlines pulled out of someone's hind-quarters, and we don't code with making the most $$$ in mind. Well, not in the usual way anyways. Our motivation is not to sell products. Our motivation is to design cool things that will make you want to go out and buy our silicon. Heck sometimes when we code, we don't even care if you buy our silicon or somebody elses silicon. Just as long as we create a need for you to buy somebody's silicon, then we'll leave it to marketing to steer you in our direction
-
The bridge is designed, in considerable detail, by a small team of experienced people, long before any construction begins. The team includes experts in diverse disciplines. New approaches are subjected to extremely expensive testing in the form of computer analysis, physical models, etc. There are no "start up" bridge design companies staffed by college dropouts.
-
While hundreds of workers may be involved in the actual construction, very few are doing things that can by themselves render the bridge unsafe. By comparison, almost any programmer on the team can render the entire program insecure by failing to test an input adequately at runtime.
-
Critical bridge components are tested to a degree (and can be tested to that degree) rarely seen in the software world. What's the equivalent of x-raying a large sample of the welded joints?
Just for the sake of argument, I would assert that most shrink-wrap software and the downloadable equivalents are built using standards no better than those of the home craftsman building a bookcase. And like the bookcase, that software works just fine, most of the time, until someone pushes at it the wrong way. However, if we built bridges and skyscrapers the way that craftsmen build bookscases...One time somebody told me that they didn't understand the Object Oriented world, etc etc. Or that you can do the same things with this "older" language etc etc.
/. and get nailed as a troll for bickering with some of the youth and some of the old-farts.
My mentality to that was, "If I thought like you did, I would still be programming in assembly"
Another time, someone made the reference, "You can't teach an old dog new tricks"...
My response was, "If I ever get like that, put me out of my misery"...
You can be deng sure that even when I'm old and gray, I'll still be learning every new technology out there just so I can rest easy.
Heck, I may still even be reading
What are you talking about? The dot net runtime installer is ONE 20 meg executable.
.net framework already installed.
.msi installer file, and will package only parts of the .net framework that your app has dependencies on.
.net framework installed already. So when I deploy an app to another machine, I only need to copy the assembly over. So if you app consists of only one .exe file, that that is the only file you need to "copy" over.
Besides, windows will ship with the
Or, you can tell VS to package your whole app into one
In our lab, all our machines have the
is a great essay by Edsger W. Dijkstra (yes, the shortest-path algo guy). the central point is that the complexity of software development is so much greater than anything else we construct that this sort of problem is inevitable.
it can be read here:
http://www.ulla.mcgill.ca/arts150/arts150r1.htm
The only solution is to have a wide variety of software, so that any particular fault only affects a small number of users. Yes, you pay for that in interoperability and support costs, but the alternative, an operating system monoculture, will be getting more and more vulnerable and unreliable over time.
It's damn good that high quality embedded software is not built the same way as Windows.
Otherwise cars and aircraft would crash and people taking radiation therapy would die!
What are you talking about? The dot net runtime installer is ONE 20 meg executable.
sorry, I meant a set of DLLs that equaled 20 MB in total size.
What about the rest of the windows population, who still use 98 variants?
Did you even bother to read the article? It deals with security, i.e. why software is vulnerable to intentional attack from malicious parties. Are you really saying that, unlike software, "bridges and high rise buildings" are invulnerable to intentional attack? Have you forgotten the events of Sept. 11, 2001? Yes, programmers should make it as hard as possible for attacks to succeed, but I'm sorry, nothing is completely invulnerable to intentional attack, including "bridges and high rise buildings".
The article misses the real problem with computer programing: the immaturity of the industry.
I believe that there are three types of programers :-
Programmers: May have a degree in some computer related field, but in practice do not use the 'science' or 'engineering' in their daily work. They are always under some time pressure to get things done.
Engineers: Use formal specifications and mathematics to design and build programs. Most of them are not working in the commercial world. (No UML is not a formal specification.)
Scientists: Look for better algorithms, write papers about their research, typically employed by universities.
So here is the problem:
'programers' write code that is only as good as the best code they have been exposed to. They learn by osmosis. They almost never read research papers, instead they read opinion pieces about the tools they do use.
'engineers' write code that is correct and bug free and take forever to get anything done. As a result they are not wanted in the typical software development team.
'scientists' write code that illustrates their particular area. It's often bug ridden when outside of the test domain and unmaintainable.
Both 'engineers' and 'scientists' write papers for their peers and are not targeted at 'programers' in the field. They may as well be using a different language when it comes to trying to comprehend some of the papers.
There is very little cross over between the different schools of programing. Almost none of the thousands of engineering/science papers published have had any effect on the world of practical programing.
While there are various associations of computing professionals, not one of them provides an industry recognized certification that tests the knowledge of a programmer/engineer. (please no MSCE/MCSE wars)
Given the above it's not suprising that for any given team of programers they will produce code that contains bugs, is insecure, and doesn't use 'best practices'. The tools we use have been written by us, not by engineers, and fulfill a different purpose, not correctness or security but speed of development.
One other point: Why spend time on security of an application when you know the OS and the other applications are gaping security holes anyway. Why put an expensive shiny lock on the back door when the front door has a "please come in" sign? - AndrewN
- AndrewN
I know that you want to make this an OSS verses Closed Source debate, but it is not. And the "root of the problem" is not what you describe at all, for what you describe deals with bugs in general, not specifically security holes.
The real problem is that over the years, QA has looked for bugs, not exploits. It is one thing for testers to try to find a way to make a program crash or not function properly, it is quite another for testers to try to find a way to make a program run malicious code.
In order to address the problem, software houses could hire seasoned hackers as part of QA. These hackers could be given a certain amount of time (say, a year) to find as many security holes as possible, and each hacker could get a $10,000 bonus for each hole he found. Only at the end of this process, would the software be released to the general public. There are problems with this. First, this scheme still won't catch every security hole. Second, who knows if a seasoned hacker could be trusted? Such individuals are by their very nature, sleazy. Maybe one of them would find a security hole, not report it, then exploit it once the sofware was released. This is the reason that I suggest the $10,000 bonus, so that there is an incentive to actually report the holes that are found. Maybe the bonus should be higher.
Almost every software tester I have met has the same mind set as you (minus the arrogance). You are nothing special, buddy.
Most of the responses on this story have been the pointless, trite, hackneyed, cliched drivel that you hear constantly.
But the parent post tells it like it is!
Why suggest ML and Haskell for functional programming? I suggest one go all the way and use LISP - the "real" functional language. :-)
You are correct that the physical construction analogies that have been posted are not accurate, but you then fall into the same trap with the statement: "However, if we built bridges and skyscrapers the way that craftsmen build bookscases...".
Sofware security exploits are malicious attacks. The "bridges and skyscrapers" that you refer to are just as vulnerable to malicious attacks, no matter how well designed and constructed. I am sure that the World Trade Center towers were well designed and constructed, but were still brought down by malicious attack. Maybe if the towers had been built like craftsmen bookcases, the attack would have been easier (maybe it would only have taken a Cessna), but my point still stands.
They don't count remote holes not found in the default install. I remember a particularly nasty one effecting the ftp daemon (remote root shell easy), but ftp is not enabled by default so they did not count that. They may be more secure than other flavors, but that slogan is just stupid.
Exactly. If I'm not "supposed" to do something the coder didn't happen to think of in advance (and who can think of every use a program will be put to?) make it a "can't happen", don't just tell me "Don't do that". That's not very useful in the real world -- are you going to track down and tell EVERY user "don't do that"?? :)
~REZ~ #43301. Who'd fake being me anyway?
That is a good point... most of my programming is stringing unix commands together in a shell script.
Most of the time when I am writing in C it is because nothing else is fast enough for the task at hand. You still can't beat C for speed. And I don't do that much user interaction with the C programs.
Even though it is harder to write and maintain, I can process a text file at least 100 times faster in C than I can with a scripted language. Even Perl isn't as fast as C.
I haven't used python, what is it's speed like compared to C?
-- Never make a general statement.
I agree that they need a better slogan, but they have done something impressive, which is go through the code looking for security problems, or just iffy code.
The OpenBSD team thinks that security is at the top of importance, and I agree. There needs to be some other name for operating systems that are not secure. Maybe framis. Microsoft Framis XP.
If an OS is not secure, it is just a toy.
Bush's education improvements were
I think this error was put intentionally to make people feel more insecure... (The wording makes it sound like other users can read your e-mail)
I normally do not care about little things like this, but I wonder if having the error has the effect of reinforcing the reader's concept that software is more insecure?
I can't resist...
Most of the time when I am writing in C it is because nothing else is fast enough for the task at hand
Interesting. By the time this discussion on Slashdot has died down, hardware will have gotten so much faster that just about any language will be fast enough for the task at hand.
OK, that was exaggerated...
You still can't beat C for speed
Hand-optimized assembly language!
I can process a text file at least 100 times faster in C than I can with a scripted language.
Don't know what scripted language you mean, but anyway, you must be doing some pretty fancy processing if the disk is not the bottleneck. So, if that is not the case, and the disk is the bottleneck, then you can do disk access 100 times faster in C than any scripted language? Forgive me if I'm a bit skeptical...
Blindly selecting C because it is (supposedly) faster boils down to premature optimization. Hopefully I don't have to quote Donald Knuth to point out that that is a bad thing...
MSN 8: Now Microsoft even has bugs in their ad campaigns.
a certification for software engineers.
The processing I do involves receiving, processing and transmiting millions of messages containing patient data, billing, and lab reports everyday. In near real time. To and from 50 systems on multiple 100Mb ethernet cards. If I used a scripting language to do all the processing it would take a week to do a days worth of messages. At peak times, even with heavily optimized C we can still run 5 to 10 minutes behind in passing messages between systems.
And the disk is _not_ the bottleneck, it has 20 disks that are mirrored and stripped (hardware RAID 10) using multiple controllers, so it has no problem keeping up with the quad processor IBM. We easily read and write data at about 160MB a second. If anything a lot of the receiving systems are the bottleneck.
All the main routines are in C. They are wired together using ksh, perl and tcl scripts. And before you ask, we pretty much know what tasks can be scripted and what tasks need C from about 50 years of in house experience with a team of 10 programmers at this particular task.
We also already have the libraries we need. Libraries that are tried and true with years of testing and experience on the 20 different systems that we fully support.
Hardly _blindly_ selecting C.
-- Never make a general statement.
I haven't used python, what is it's speed like compared to C?
Python is an extremely expressive, runtime evaluated language. As such, it's probably about 4x slower than perl in cpu bound operations.
People still develop cpu-intensive applications using Python though, even games. The graphics routines/physics are implemented in C, how it all comes together is where Python shines.
I wonder how much cheaper it would be for MS to fix things before they go out the door vs. the service pack downloads.
I've misplaced SP2 for W2K a few times, downloaded it between 5 and 10 times. That's 500megs to a gig, and that's just me.
This is where reasonable SPECS come in. When the coder has nothing but his own ass to refer to for what the expected behavior of a program is, then you get this type of attitude.
Personally, when in-house testers find bugs in my code my response is "Thank you, I'm glad a customer didn't find it!".
Fair enough. It seems like your application has some pretty tough performance requirements. I can't judge it of course, but it does seem you have no alternative but to use C.
MSN 8: Now Microsoft even has bugs in their ad campaigns.
> caused by the C libraries poor implementation
:-(
> of strings, and by the lack of any runtime
> bounds checking?
I like C and C++ very much. However, I think their time has gone.
It is now the time for languages like Python, Delphi, etc.
The problem, as I see it, isn't that there are too many inexperienced programmers, just too few of the good ones.
Sorry, this is a rant. It bugs me to hear people say this.
There are plenty of good, experienced programmers. They just have a hard time getting hired, because they are older than 25. When you interview them, what they talk about are good, solid development strategies, such as proving programs. This is different from and far less impressive than a spew of hot new buzzwords.
So you have some idiots who don't understand the basics of stacks. OK. Someone hired them instead of a 40-year-old like me who has grokked stacks since his and/or her teens. The reason they made this hiring decision is that's who they wanted to hire.
Even worse, they're going to keep on hiring these idiots, because people have been so beaten into submission to accept bugs that they hardly notice the difference between a well designed and badly designed piece of code.
Exercise: how many OpenBSD security flaws exist (or have existed) where the weakness was exploited before the team fixed it? What has the severity of the flaw been compared to flaws that have been found in other systems>
There are no programs called ftp, httpd or smtp. FTP, SMTP and HTTP are protocols for which there are many implementations; rarely does a protocol have a bug. Implementations of these protocols may have bugs. So it makes sense to talk of Apache or Sendmail having a bug, but not httpd since there's no such thing.If one particular OS distribution -- one of the *BSDs or a Linux distribution -- runs BIND as root, and another runs it as a user with no privileges except to read files in one particular part of the filesystem, then a flaw in BIND is obviously much more severe in the former than in the latter.
With OpenBSD, when you run BIND you're not just running BIND version 4, you're running a version of BIND 4 that has been audited by the OpenBSD team for flaws. (This is why OpenBSD is still using BIND4 and will continue to do so for a while: the code has been audited, and it works perfectly well providing DNS. Why "upgrade" when the old version isn't missing anything you need?)
All the code that is part of a standard OpenBSD install has been audited. If Apache is found to have a bug, it is not necessarily true that Apache on OpenBSD has a bug. And unfortunately bug fixes that the OpenBSD team makes in standard daemons don't always get accepted into the mainstream code for it.
Unlimited growth == Cancer.
Try splint: . It can be used to make statical analysis for C source, including tainting.
I sympathise to an extent, because although I am (just) under 25, I still see people who are good getting passed over in favour of people with high buzzword counts. I've also seen the results several times, and it's never pretty.
On the other hand, I really don't think that, as a proportion, there are that many good programmers out there, of any age. I just don't see any evidence for it. Notice that most of the dumb decisions being made (including recruiting buzzword specialists) are made by older people, either senior developers or those who've moved into project management. Furthermore, most of them are a direct result of that older person feeling qualified to make a decision when in fact they are not, through ignorance, prejudice or whatever.
To give a concrete example, most of the reason we have such bad C++ programming in the world is that older programmers who have used C for decades think that they are somehow qualified to comment on (or program in) C++. As a result, we have a fabulously powerful language being used to write incredibly bad code all over the place. Most of the criticism directed at C++, particularly on boards like this, is unfounded, but the perceived weaknesses are there because people haven't done their homework. This is just my own pet peeve, which I see every day, but is a definite argument against your claim that there are plenty of good older programmers out there. I'd rather have a 25-year-old whose C++/OO knowledge was current than a 45-year-old whose knowledge was based on a decade of programming C until five years ago, but who thought it was still current and thought he could do OO as well, because it's just "a variation on the theme". It's amazing how many "old and wise C++ experts" don't know what a template is, and I'm sure entirely coincidental that C doesn't have the concept and it wasn't in "Learn OO in Five Seconds".
It's certainly true that there are good older programmers, and that they are better than good younger programmers, simply because they have wider experience to draw upon. But IME, they really are pretty few and far between. At the same time, you have to remember that the field levels out a lot once you've been in the business for more than, say, five years, however old you are. Knowledge dates fast in this industry, and the relevance of older experience drops away until it's really only the domain-specific experience and general business acumen that are still useful, IMHO.
I've never liked age discrimination, at either end of the spectrum. I believe in rewarding genuine merit alone, and in my experience, those who do so make a better job of things. But to claim that plenty of the older programmers are being passed over in favour of younger types purely because of discrimination/buzzwordism is Just Plain Wrong. A lot of those older programmers still think they're good, but their knowledge is so far out of date that it's simply not as valuable as the enthusiasm and recent knowledge of the younger competition.
It's a hard thing to learn what you're truly worth, and that "N years of experience" and "respect your elders" don't always cut it. On the other hand, looking purely on objective merit, I see relatively few programmers who can get the job done properly in the first place, and most of them are pretty young. That's always going to make it look as if older programmers are being discriminated against, but actually, there's a much simpler explanation a lot of the time.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Ada was developed for military use as a coding standard. Its syntax is so strict that the code works often. But...uh...it doesn't matter. You can still screw up.
Similarly, people speak English badly every day.
Mod me down and I will become more powerful than you can possibly imagine!
Absolutely agreed. Along these lines, The Edge Report has posted an interesting article talking about the national security implications of closed source software. While the infiltration of Microsoft by Al Qaeda may have been only a rumor, the article explores a world where this could happen. And guess what? We're living in it. It closes with a powerful statement: "Closed source software vendors, in the name of National Security: Open your Code!".
http://www.edgereport.com/article.php?sid=135
--
All your comment are belong to us.r e+belong+to+us%22
http://www.google.com/search?q=%22all+your+base+a
All your comment are belong to us.
some of your comment may or may not belong to us.