Vulnerabilities

From
Revision as of 12:19, 4 January 2005 by Kermit (talk | contribs)
Jump to navigation Jump to search

Vulnerabilities can emerge at every level of program design and implementation. The following systematization of vulnerabilities is taken from the book "Exploiting Software" by Greg Hoglund and McGraw. There are of course many other approaches, the one presented here is nevertheless preferred by the authors.

We distinguish:

  • Bugs
  • Flaws
  • Configuration errors

Bugs are errors that are done at the implementation level. A well known example are buffer overflows. A very good description of buffer overflows has been written by Aleph One "Smashing the Stack for fun and profit". Bugs are usually relativly easy to find and fix (Codescanners do this very well).

Vulnerabilities that emerge at the design level are referenced as flaws. Flaws are usually very difficult to find as they appear in the "philosophy" of the program and merely in one line of code. Examples of design flaws are

ethernet can be sniffed unencyrpted communication protocols (smtp, telnet, pop3)


Design flaws can emerge at the reason of environment changes. The protocols smtp and pop3 are good examples for this. In the time they were designed, encryption was unnecessary, there were few hosts and only a small "community". Security concerns were therefore mostly unrelevant. But it can be considered a configuration error to use these protocols in the modern "aggressive" environment.

Configuration errors are "boring" because they are done by the "user", which is seldom profitable to blaim. They are nevertheless a very common reason for compromised systems and should be regarded as a serious problem therefore. Examples for these problems are: - good passwords - default configurations are often optimized for functionality and not for security - unneeded but running services, which disclose too much information - wrong file permissions - wrong firewall/gateway configurations