Buffer-Overflow Attacks: Perimeter Defenses No Panacea

By now youve probably read about, if not experienced, buffer-overflow attacks. In fact, recent CERT statistics indicate that more than 60 percent of advisories refer to buffer-overflow attacks. And because many of the attacks come through enterprise intranets (which are open by design), perimeter defenses cant provide the protection required to keep these malicious data streams from doing damage—potentially in your enterprise. In some cases, buffer overflows cause asset destruction, requiring hundreds of hours of "forensic programming" to reconstruct or restore the destroyed assets. So what can be done to prevent them?

One conceptual defense is easier said than done: writing programs that check buffers. More often the recommendation is to install the latest patch that fixes the vulnerability. There are other preventative security measures and ways to mitigate the damage.

A good preventative defense starts first by protecting assets based on their value to the enterprise. Since there will be buffer overflows if enough code is created over time (a humanistic certainty), place a higher scrutiny/protection priority on the more valuable code, and limit its ability to operate as a privileged user.

Programs developed to create, access, modify or delete the most valuable assets should be defended most vigorously. These include programs that run as a privileged user, across multiple systems or networks in an enterprise. Since these programs already have access to the most valuable assets (by virtue of their execution privilege), a potential "best practice" would include limiting their access by means beyond "quality assurance" and "good programming."

By drawing on privilege-based access control, you ensure that only programs with proper access privilege run. Further restrictions can be defined such as restricting execution from outside a specific "launch directory" and setting "runuser" to an alternate user ID, all of which limit access to minimize significant damage in the event of a buffer-overflow attack. For example, until source code patches became available for a recent Unix and Linux Sendmail attack, the most effective method of preventing the intrusion was to set the "RunAsUser" option for the sendmail daemon, limiting its ability to provide a high-privilege portal for the attack to the system. By limiting a programs scope, ability and duration while operating as a privileged user, when accessing the most valuable assets, the highest level of "non code-level" security is enforced for the protection of the asset.

With the value of the data assets along the vertical axis and the required duration of privileged access spanning the horizontal axis, plot your data appropriately. The highest-valued data requires the shortest duration of privileged access, while the least-valued data can withstand the longer privileged access. Conceptual examples follow:

In the example illustrated above, weve determined that among our highest-valued data assets are computer account data (such usernames and passwords); HR data (such as Social Security numbers, salary information and stock-option information), and HIPAA or financial data are higher-value.

The various data is protected from buffer-overflow attacks by limiting the applications that access this data, both in duration and privilege. For example, user accounts are added via a program that runs as root but must be executed from a specific host and directory, started by a specified administrators, and run only at a certain period of time during specified weekdays.

Another best practice to mitigate damage caused by a buffer-overflow attack is restricting access beyond the compromised host. Even if the attacker gains root-level access, minimize the hackers ability to gain root access to other hosts by securing each hosts unique root password needed to invoke superuser privileges.

Although software developers are working diligently to write good programs, best practice to address buffer-overflow attacks involves analyzing and prioritizing assets based on their value to your company, protecting these assets by restricting administrative and particularly root privileges, and minimizing the attackers ability to gain access to other machines beyond the compromised host.

Richard Williams is a Senior Technical Support Specialist for Symark Software of Westlake Village, Calif. He has been involved in Unix computing, networking and security since 1983.