Difference between revisions of "Asymmetric resource consumption (amplification)"

From OWASP
Jump to: navigation, search
m (Categories)
(Updated description, examples, links, vulnerabilities, and references)
 
(30 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
{{Template:Attack}}
 
{{Template:Attack}}
 +
<br>
 +
[[Category:OWASP ASDR Project]]
 +
 +
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
 
==Description==
 
==Description==
  
An attacker can force a victim to consume more resources than should be allowed for the attacker's level of access. The program can
+
Asymmetric resource consumption consists in an attacker forcing a web application to consume excessive resources when the application fails to release, or incorrectly releases, a system resource.
potentially fail to release or incorrectly release a system resource.
+
 
A resource is not properly cleared and made available for re-use.
+
==Risk Factors==
 +
TBD
  
 
==Examples ==
 
==Examples ==
  
'''Example1'''
+
===Example 1===
 
+
 
The following method never closes the file handle it opens. The Finalize() method for StreamReader eventually calls Close(), but there
 
The following method never closes the file handle it opens. The Finalize() method for StreamReader eventually calls Close(), but there
is no guarantee how long it is going to take before the Finalize() method is invoked. In fact, there is no guarantee that Finalize() will ever be invoked. In a busy environment, this can result in the VM using up all of its available file handles.
+
is no guarantee how long it is going to take before the Finalize() method is invoked. In fact, there is no guarantee that Finalize() will ever be invoked. In a busy environment, this can result in using up all available file handles.
 
<pre>
 
<pre>
 
private void processFile(string fName) {
 
private void processFile(string fName) {
Line 21: Line 26:
 
}
 
}
 
</pre>
 
</pre>
After using up all handles (file descriptors) VM may become very unstable, slow and what is the most immportant it may stop working
+
After using up all handles (file descriptors) the application may become very unstable, slow, or may stop working, significantly impacting the applications usability.
deterministically comparing to its previous state.
+
  
 
+
===Example 2===
'''Example2'''
+
Under normal conditions, the following C# code executes a database query, processes the results returned by the database, and closes the allocated SqlConnection object. If an exception occurs while executing the SQL, or processing the results, the code does not close the SqlConnection object. If this happens enough times, the database runs out of available cursors and is not able to execute any more queries.
 
+
Under normal conditions the following C# code executes a database query, processes the results returned by the database, and closes the allocated SqlConnection object. But if an exception occurs while executing the SQL or processing the results, the SqlConnection object is not closed. If this happens often enough, the database runs out of available cursors and is not able to execute any more SQL queries.
+
  
 
C# Example:
 
C# Example:
Line 40: Line 42:
 
...
 
...
 
</pre>
 
</pre>
The amount of the concurent connections to the databases is often lower than maximal amount of possible handles in the system to use.
+
The number of concurent connections to the databases is often lower than maximum number of possible handles for the system to use.
It makes easier to locate application bottlenecks and use them to stop the application or make it unstable.
+
This allows application bottlenecks to negatively impact or stop the application.
 
+
 
+
'''Example3'''
+
 
+
If application which can handle N concurent connections doesn't implement appropriate mechanism to disconnect clients e.g. TIMEOUTs,
+
then it's very easy to disable it by establishing close to N connections. Additionally the connections should simulate work with
+
application using its protocol untill exhaustion of the available resources.
+
 
+
 
+
Reference:
+
* http://cwe.mitre.org/data/definitions/404.html
+
 
+
==Related Threats==
+
 
+
* [[Denial_of_Service]]
+
 
+
==Related Attacks==
+
 
+
* [[Account_Lockout_Attack]]
+
  
==Related Vulnerabilities==
+
===Example 3===
 +
If an application can handle N concurent connections and does not implement an appropriate mechanism to disconnect clients (e.g. TIMEOUTs), it becomes very easy to adversely affect the application by simply establishing close to N connections. Additionally, those multiple connections could be used to simulate interaction with the application until exhaustion of available resources.
  
* [[Insufficient_Resource_Locking]]
+
==Related [[Threat Agents]]==
* [[Insufficient_Resource_Pool]]
+
* TBD
  
==Related Countermeasures==
+
==Related [[Attacks]]==
 +
* [[Denial of Service]]
 +
* [[Account lockout attack]]
  
It is good practice to be responsible for freeing all resources you allocate.
+
==Related [[Vulnerabilities]]==
 +
* [[Resource Exhaustion]]
  
Memory should be allocated/freed using matching functions such as
+
==Related [[Controls]]==
malloc/free, new/delete, and new[]/delete[].
+
* [[Memory Management]]
 +
* [[Resource Locking]]
  
==Categories==
+
==References==
 +
* http://cwe.mitre.org/data/definitions/405.html
 +
* https://www.securecoding.cert.org/confluence/display/java/FIO04-J.+Release+resources+when+they+are+no+longer+needed
  
 
[[Category:Resource_Depletion]]
 
[[Category:Resource_Depletion]]
 +
[[Category:Attack]]

Latest revision as of 20:22, 30 January 2013

This is an Attack. To view all attacks, please see the Attack Category page.




Last revision (mm/dd/yy): 01/30/2013

Description

Asymmetric resource consumption consists in an attacker forcing a web application to consume excessive resources when the application fails to release, or incorrectly releases, a system resource.

Risk Factors

TBD

Examples

Example 1

The following method never closes the file handle it opens. The Finalize() method for StreamReader eventually calls Close(), but there is no guarantee how long it is going to take before the Finalize() method is invoked. In fact, there is no guarantee that Finalize() will ever be invoked. In a busy environment, this can result in using up all available file handles.

private void processFile(string fName) {
 StreamWriter sw = new
 StreamWriter(fName);
 string line;
 while ((line = sr.ReadLine()) != null) processLine(line);
}

After using up all handles (file descriptors) the application may become very unstable, slow, or may stop working, significantly impacting the applications usability.

Example 2

Under normal conditions, the following C# code executes a database query, processes the results returned by the database, and closes the allocated SqlConnection object. If an exception occurs while executing the SQL, or processing the results, the code does not close the SqlConnection object. If this happens enough times, the database runs out of available cursors and is not able to execute any more queries.

C# Example:

...
SqlConnection conn = new SqlConnection(connString);
SqlCommand cmd = new SqlCommand(queryString);
cmd.Connection = conn; conn.Open();
SqlDataReader rdr = cmd.ExecuteReader();
HarvestResults(rdr);
conn.Connection.Close();
...

The number of concurent connections to the databases is often lower than maximum number of possible handles for the system to use. This allows application bottlenecks to negatively impact or stop the application.

Example 3

If an application can handle N concurent connections and does not implement an appropriate mechanism to disconnect clients (e.g. TIMEOUTs), it becomes very easy to adversely affect the application by simply establishing close to N connections. Additionally, those multiple connections could be used to simulate interaction with the application until exhaustion of available resources.

Related Threat Agents

  • TBD

Related Attacks

Related Vulnerabilities

Related Controls

References