CastleCops® - Buffer-Overflow Attacks: Perimeter Defenses No Panacea

By now you've 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 can't 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?

By Richard Williams, Symark
June 20, 2003

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 program's 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.

Source: Secuirty Supersite


	2002-2008 © Computer Cops LLC dba CastleCops®. All rights reserved. Acceptable Use Policy. Use signifies your agreement. 180ppm 0.423s (0.014s) Making cybercriminals unhappy since 2002*