Vulnerabilities: Difference between revisions

From
Jump to navigation Jump to search
mNo edit summary
No edit summary
 
(One intermediate revision by the same user not shown)
Line 6: Line 6:
*'''Flaws'''
*'''Flaws'''
*'''Configuration errors'''
*'''Configuration errors'''



'''Bugs''' are errors that are done at the implementation level. A well known example are buffer overflows.
'''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".
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).
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
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
*ethernet can be sniffed
*unencyrpted communication protocols (smtp, telnet, pop3)
*unencrypted 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.
'''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.
In the time they were designed, encryption was unnecessary, there were few hosts and only a small "community". Security concerns were therefore mostly irrelevant. 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.
'''Configuration Errors''' are kind of "boring" because they are done by the "user", which is seldom profitable to blame.
They are nevertheless a very common reason for compromised systems and should be regarded as a serious problem therefore. Examples for these problems are:
They are nevertheless very common reasons for compromised systems and should be therefore regarded as a serious problem. Examples for these problems are:
*good passwords
*bad passwords
*default configurations are often optimized for functionality and not for security
*default configurations are often optimized for functionality and not for security
*unneeded but running services, which disclose too much information
*unneeded but running services, which disclose too much information

Latest revision as of 12:24, 25 January 2005

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
  • unencrypted 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 irrelevant. But it can be considered a Configuration Error to use these protocols in the modern "aggressive" environment.


Configuration Errors are kind of "boring" because they are done by the "user", which is seldom profitable to blame. They are nevertheless very common reasons for compromised systems and should be therefore regarded as a serious problem. Examples for these problems are:

  • bad 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