Buffer overflows are a serious problem. A buffer overflow is a condition in a program where the software loads a buffer with data without checking the data for proper length. When the data size exceeds the buffer size and no coded remedy is in place to correct that situation, a buffer overflow occurs because of excess data.
So what's the big deal about buffer overflows? If the excess data destined for the buffer contains shell code or other executable code, the OS might execute the code. The implications are clear: Buffer overflow conditions leave room for attackers to penetrate or deny service to a system with relative ease.
How serious is the problem? Very serious, if you ask me. Over the last 2 weeks, users have reported more than a dozen and a half security risks related to buffer overflows in Windows NT-based applications. This is a staggering figure for reported NT security problems.
Some of the first discoveries of buffer overflows on i386 processors were publicly reported as early as 1995—perhaps even earlier in the underground. Savvy programmers found these problems, developed shell code to help facilitate exploits against the problems, and the rest is, as they say, history. And that history is still being made on an almost daily basis, as witnessed in the barrage of vulnerability reports posted in this newsletter alone.
Knowledge of buffer overflows is not a new revelation; information of this type has been shared in the PC underground for more than a decade. Over the years, countless numbers of security risks have occurred as direct results of poor programming practices that left room for buffer overflows through faulty or nonexistent bounds checking.
I can't understand why developers don't pay acute attention to the reported security risks and learn from other developers' mistakes. The number of buffer overflows reported in just the last 2 weeks shows that developers continue to ignore the warning signs.
It's time we handled this problem more effectively; the eEye Digital Security Team tells me crackers seek out these buffer overflow conditions rampantly. The overflows are easy to find and easy to exploit. If nothing else, the overflows can lead to a hard-to-detect denial of service (DoS) attack, and at worst, they can lead to a complete network compromise.
The bottom line is that, for whatever reason, developers by and large don't take security seriously. But all developers should be aware that security starts with them, the software creators. So if they write code that works but is insecure, the product will remain less-than-acceptable to security-minded consumers.
Security is a red-hot topic, and it will continue to get even hotter. Over a relatively short period of time, a huge number of Windows administrators will learn enough security knowledge and skills to understand which companies don't take security seriously and which companies do. Administrators will learn this by watching for security risk reports, and they'll remember a company when its name appears in those reports. And I think they'll take particular note of any vendors who continually have buffer overflows in their code.
So ask yourself how that might affect your ability to sell products in the future. Sure, you can sell products today, but will you be able to sell them tomorrow? I seriously doubt it. Is it easier to learn adequate coding practices, or is it easier to go out of business due to a bad reputation?
I think the days of old-school programming are long gone. The new school is attentive to buffer overflows and other security implications. To become a decent programmer or security practitioner in today's world, you must be aware of security issues as they surface; otherwise, how can you expect to guard against the risks? The answer is, you can't. Until next time, have a great week.
End of Article
Izzy Leeds November 15, 1999