We've been assuring our readers that they have to execute a program before their computers can get infected by a virus program. "Not so," claim the panic mongers. The latest virus programs do their mischief, they tell us, simply by causing an E-mail buffer to overflow, and then overlaying executable code upon the unsuspecting E-mail program or web browser.
Nonsense! At worst, such viruses rely on a blatant bug in software on the user's machine. Data are read into buffers by a program, which has total control over the number of bytes stored. It takes an appallingly naive program bug to store data beyond the end of a buffer.
Avoiding such errors isn't sophisticated or advanced programming; everyone learns to do it in his or her first elementary programming course. Forty-year-old buffered I-O systems used length flags to specify the size of a following logical record, and the systems, coded in early assembly languages, made sure there was room to store the record.
A recent article in Infoworld ("Microsoft scrambles to patch Outlook and IE security holes", July 24, p. 8) quotes a virus expert as asserting that "buffer overflows are the most common Internet security holes." He blames the programming languages:
". . C and C++ have buffers but do not have bouncers [sic]; they leave that to the programmer. Therefore buffer overflow is very problematic. Java performs bounce checking and buffer overflows."Presumably the reporter misheard, and the expert really meant " Java performs bounds checking and prevents buffer overflows." Even with the correction, however, the diagnosis is naive. Competent programmers routinely validate length flags in an input stream, especially when that input stream originates outside the immediate program environment. They do so in all programming languages.
Furthermore, Java does not relieve the programmer of responsibility. A heavy duty system program doesn't lose control on unhandled Java exceptions, even if that's preferable to introducing a virus.
Even if such a bug slips past the original programming team, it should almost certainly be caught in the early stages of testing. Any experienced programmer testing a buffering program would be sure to include test cases that are exactly the buffer size and one byte larger. Failure to do so is worse than naive; it's irresponsible.
We can't help noticing a pattern in the most recent and most notorious virus scares. (Word macro, Melissa, and Love Bug) Each targeted Microsoft products. That's not only because Microsoft is such a tempting target, but more because design flaws, blatant bugs, and sloppy testing in those products made such viruses possible. Other vendors, of course, are also vulnerable even if not on so large a scale.
In defense of those vendors, some observers remind us that today's systems are far more complicated and sophisticated than their predecessors. It's unrealistic, they claim, to expect the old levels of reliability from pioneering software.
They're right about that. Given the unpredictability of event-firing sequences and the complexity of distributed object technologies, it's a miracle that those vendors ever get their products to work at all. Nevertheless, loading fixed-length buffers with variable-length data is by no means a new or sophisticated technique; there's no excuse for getting it wrong.
Return to Viruses.
IDI home page.