C/C++ Users Journal September, 2005
Security is an important topic these days, as well it ought to be. Billions of computers are out there running every day, not even counting embedded processors, which are far more numerous. Many of those billions run 'round the clock, and many of those are reachable via the Internet from anywhere in the world. Sociopaths, con artists, and just plain thieves with highly varied goals all share a common desire to seize control of inadequately protected systems and bend them to assorted nefarious purposes.
I suspect the most common way to obtain unwanted entry is through the front door. My e-mail has two levels of spam filtering, yet 90 percent of the mail that makes it through is still garbage. If the crud isn't virus infected directly, it's just a step or two away from it. The phishers must be working overtime thinking of new ways to fool us into executing malicious code, if my IN box is any indication. Of course, it's cheap enough for them to send out the odd million e-mails—all it costs the world is a bit of Internet bandwidth and some widely spread annoyance. Whatever the personal cost, the phishers must be getting an adequate return on their own investment in time and ISP charges because they keep doing it.
Nevertheless, most of the press coverage concerns vulnerabilities in system software. That's probably as it should be, because no amount of vigilance on the part of civilians can prevent an entry through an unguarded back door. And the attacks from that direction are at least as persistent as the e-mail bombardment. At Dinkumware, we've learned to reinstall an operating system only when the computer is off the Internet. Otherwise, it gets infected within minutes, well before we can install the latest security patches. (I sympathize more than ever with baby birds and tadpoles these days.)
I suspect the most common system vulnerabilities are the moral equivalent of leaving the back door unlocked. For years, people demanded computers that are ever easier to use. The vendors were happy to oblige, but to do so they had to be sure that different software packages could cooperate behind the scenes. It's way easier to let all your coworkers in through the servants' entrance than to annoy the gentry. And everybody is much happier—at least until the folks coming in through the back door come with their own agendas.
So the press coverage shifts to system software with defective protections. That usually means bugs that can be exploited to seize unwelcome control. I suspect the most common of these bugs are storage overwrites of some form. There's nothing quite like rewriting code on the fly for turning a conscientious program into a witless zombie. Unlike the vulnerabilities I cited above, storage overwrites have no redeeming social value. In the best of cases they quietly stumble on; in the worst they cause erratic failures, or give aid and comfort to the enemy. Eliminating storage overwrites has to be a Good Thing (TM).
A lot of systems code in everyday use is written in C and C++. Both languages are notorious for offering multiple opportunities for "undefined behavior." That's a standardese term for working without a net, or for operating dangerous machinery with the safety panels removed. You can make code that's small and efficient if you do it right. You can make code that's a sucker for storage overwrites, and other vulnerabilities, if you don't.
Thus the current interest in ways to make C and C++ code more secure, even if it means sacrificing some of that vaunted size and efficiency. Computers are way bigger and more powerful than when C was born (over a third of a century ago!). It's high time we spent some of that horsepower on carrying around more safety equipment.
And we're doing so, on multiple fronts. I've mentioned the modified C library developed at Microsoft that's now making its way through the C committee as a nonnormative Technical Report. It emphasized increased visibility of buffer sizes and runtime checking, as ways to lower the odds of a buffer overrun. I've also mentioned Microsoft's Managed C++, now nearing completion. It employs garbage collection and code validation, among other things, as ways to catch overwrites before they happen. There are also (non-Microsoft) efforts to improve code readability and automatic checking that I hope to describe in later installments.
Just don't expect any one of these approaches to solve the whole problem. You still have to put locks on your doors, and use them.
P.J. Plauger
Senior Contributing Editor
pjp@plauger.com