Vulnerabilities - Revision history

141.20.192.126 at 12:24, 25 January 2005

2005-01-25T12:24:06Z

← Older revision		Revision as of 12:24, 25 January 2005
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.

141.20.192.126 at 12:23, 25 January 2005

2005-01-25T12:23:39Z

← Older revision		Revision as of 12:23, 25 January 2005
Line 10:		Line 10:
	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

Kermit at 12:22, 4 January 2005

2005-01-04T12:22:07Z

← Older revision		Revision as of 12:22, 4 January 2005
Line 20:		Line 20:
	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 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.		'''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:		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		*good 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
	- wrong file permissions		*wrong file permissions
	- wrong firewall/gateway configurations		*wrong firewall/gateway configurations

Kermit at 12:21, 4 January 2005

2005-01-04T12:21:20Z

← Older revision		Revision as of 12:21, 4 January 2005
Line 7:		Line 7:
	*'''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)		*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.		'''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 unrelevant. But it can be considered a configuration error to use these protocols in the modern "aggressive" environment.

Kermit at 12:19, 4 January 2005

2005-01-04T12:19:41Z

← Older revision		Revision as of 12:19, 4 January 2005
Line 3:		Line 3:
	We distinguish:		We distinguish:

	Bugs		*'''Bugs'''
	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.

141.20.195.201 at 13:19, 14 December 2004

2004-12-14T13:19:15Z

New page

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