[Risks Digest 21.84] Pointing the finger at buffer overflows Date: Wed, 26 Dec 2001 21:19:22 -0800 From: Henry Baker
Subject: "Buffer Overflow" security problems I'm no fan of lawyers or litigation, but it's high time that someone defined "buffer overflow" as being equal to "gross criminal negligence". Unlike many other software problems, this problem has had a known cure since at least PL/I in the 1960's, where it was called an "array bounds exception". In my early programming days, I spent quite a number of unpaid overtime nights debugging "array bounds exceptions" from "core dumps" to avoid the even worse problems which would result from not checking the array bounds. I then spent several years of my life inventing "real-time garbage collection", so that no software -- including embedded systems software -- would ever again have to be without such basic software error checks. During the subsequent 25 years I have seen the incredible havoc wreaked upon the world by "buffer overflows" and their cousins, and continue to be amazed by the complete idiots who run the world's largest software organizations, and who hire the bulk of the computer science Ph.D.'s. These people _know_ better, but they don't care! I asked the CEO of a high-tech company whose products are used by a large fraction of you about this issue and why no one was willing to spend any money or effort to fix these problems, and his response was that "the records of our customer service department show very few complaints about software crashes due to buffer overflows and the like". Of course not, you idiot! The software developers turned off all the checks so they wouldn't be bugged by the customer service department! The C language (invented by Bell Labs -- the people who were supposed to be building products with five 9's of reliability -- 99.999%) then taught two entire generations of programmers to ignore buffer overflows, and nearly every other exceptional condition, as well. A famous paper in the Communications of the ACM found that nearly every Unix command (all written in C) could be made to fail (sometimes in spectacular ways) if given random characters ("line noise") as input. And this after Unix became the de facto standard for workstations and had been in extensive commercial use for at least 10 years. The lauded "Microsoft programming tests" of the 1980's were designed to weed out anyone who was careful enough to check for buffer overflows, because they obviously didn't understand and appreciate the intricacies of the C language. I'm sorry to be politically incorrect, but for the ACM to then laud "C" and its inventors as a major advance in computer science has to rank right up there with Chamberlain's appeasement of Hitler. If I remove a stop sign and someone is killed in a car accident at that intersection, I can be sued and perhaps go to jail for contributing to that accident. If I lock an exit door in a crowded theater or restaurant that subsequently burns, I face lawsuits and jail time. If I remove or disable the fire extinguishers in a public building, I again face lawsuits and jail time. If I remove the shrouding from a gear train or a belt in a factory, I (and my company) face huge OSHA fines and lawsuits. If I remove array bounds checks from my software, I will get a raise and additional stock options due to the improved "performance" and decreased number of calls from customer service. I will also be promoted, so I can then make sure that none of my reports will check array bounds, either. The most basic safeguards found in "professional engineering" are cavalierly and routinely ignored in the software field. Software people would never drive to the office if building engineers and automotive engineers were as cavalier about buildings and autos as the software "engineer" is about his software. I have been told that one of the reasons for the longevity of the Roman bridges is that their designers had to stand under them when they were first used. It may be time to put a similar discipline into the software field. If buffer overflows are ever controlled, it won't be due to mere crashes, but due to their making systems vulnerable to hackers. Software crashes due to mere incompetence apparently don't raise any eyebrows, because no one wants to fault the incompetent programmer (and his incompetent boss). So we have to conjure up "bad guys" as "boogie men" in (hopefully) far-distant lands who "hack our systems", rather than noticing that in pointing one finger at the hacker, we still have three fingers pointed at ourselves. I know that it is my fate to be killed in a (real) crash due to a buffer overflow software bug. I feel like some of the NASA engineers before the Challenger disaster. I'm tired of being right. Let's stop the madness and fix the problem -- it's far worse, and caused far more damage than any Y2K bug, and yet the solution is far easier. Henry Baker
"Of course, I am using a browser, Internet Explorer, produced by the
world's most successful supplier of erroneous software, Microsoft Inc.,
and that may explain the problem."
Michel Joly de Lotbinire
From: email@example.com (Charles Cazabon)
Subject: Software Requirements
Date: Wed, 3 Dec 97 19:30:03 EST
On the side of the software box, in the "System Requirements" section, it said "Requires Windows 95 or better". So I installed Linux. [As told to me by a friend...]
"I have stopped reading Stephen King novels. Now I just read C code instead." Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok
"C program run -- Run program run -- Run, C program, Run! -- (please)" Bumper Sticker
"The last good thing written in C was Franz Schubert's Symphony number 9." Erwin Dieterich firstname.lastname@example.org
"When your hammer is C++, everything begins to look like a thumb." Steve Hoflich compl.lang.c++
"Being really good at C++ is like being really good at using rocks to sharpen sticks."
"So, when you typed in the date, it exploded into a sheet of blue flame and burned the entire admin wing to the ground? Yes, that's a known bug. We'll be fixing it in the next release. Until then, try not to use European date format, and keep an extinguisher handy." email@example.com (Tequila Rapide)
> Feel free to post more examples of "Why c++ sucks". ;-)
Read through the C++ Public Review Document and look for occurences of the phrases "behavior is undefined" and especially "no diagnostic is required".
Or here's an even simpler indicator of how much C++ sucks: Print out the C++ Public Review Document. Have someone hold it about three feet above your head and then drop it. Thus you will be enlightened.
An old quote from me: "The newest programming language for CS-1 starts with C and ends with an incredible amount of debugging." Rich Pattis ("an old quote of mine")