Unreleased Resource - Revision history

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

2017-11-10T21:51:51Z

Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

Imifos: fixed classification

2015-12-01T11:52:58Z

fixed classification

Jmanico at 18:48, 5 April 2014

2014-04-05T18:48:31Z

KirstenS at 02:01, 21 February 2009

2009-02-21T02:01:27Z

KirstenS at 14:19, 19 February 2009

2009-02-19T14:19:15Z

KirstenS at 14:14, 9 November 2008

2008-11-09T14:14:41Z

KirstenS at 13:14, 3 October 2008

2008-10-03T13:14:29Z

Weilin Zhong at 15:11, 21 July 2006

2006-07-21T15:11:36Z

New page

{{Template:Vulnerability}}
{{Template:Fortify}}

==Abstract==

The program can potentially fail to release a system resource.

==Description==

Most unreleased resource issues result in general software reliability problems, but if an attacker can intentionally trigger a resource leak, the attacker might be able to launch a denial of service attack by depleting the resource pool.

Resource leaks have at least two common causes:

* Error conditions and other exceptional circumstances.
* Confusion over which part of the program is responsible for releasing the resource.

==Examples ==

'''Example 1:''' The following Java method never closes the file handle it opens. The finalize() method for FileInputStream eventually calls close(), but there is no guarantee as to how long it will take before the finalize() method will be invoked. In a busy environment, this can result in the JVM using up all of its file handles.

<pre>
private void processFile(String fName) throws FileNotFoundException, IOException
{
FileInputStream fis = new FileInputStream(fName);
int sz;
byte[] byteArray = new byte[BLOCK_SIZE];
while ((sz = fis.read(byteArray)) != -1) {
processBytes(byteArray, sz);
}
}
</pre>

'''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. 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 will run out of available cursors and not be able to execute any more SQL queries.

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

'''Example 3:''' The following C function does not close the file handle it opens if an error occurs. If the process is long-lived, the process can run out of file handles.

<pre>
int decodeFile(char* fName)
{
char buf[BUF_SZ];
FILE* f = fopen(fName, "r");

if (!f) {
printf("cannot open %s\n", fName);
return DECODE_FAIL;
} else {
while (fgets(buf, BUF_SZ, f)) {
if (!checkChecksum(buf)) {
return DECODE_FAIL;
} else {
decodeBlock(buf);
}
}
}
fclose(f);
return DECODE_SUCCESS;
}
</pre>

==Related Threats==

==Related Attacks==

==Related Vulnerabilities==

==Related Countermeasures==

==Categories==

[[Category:Code Quality Vulnerability]]

[[Category:Java]]

[[Category:Implementation]]

[[Category:Code Snippet]]

@@ Line 1: / Line 1: @@
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
-[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
+= Description =
 The program can potentially fail to release a system resource.
@@ Line 16: / Line 11: @@
 * Confusion over which part of the program is responsible for releasing the resource.
 = Risk Factors =
 * Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen
@@ Line 23: / Line 17: @@
 * Consider the likely [business impacts] of a successful attack
-==Examples==
+==Example 1==
 The following Java method never closes the file handle it opens. The finalize() method for FileInputStream eventually calls close(), but there is no guarantee as to how long it will take before the finalize() method will be invoked. In a busy environment, this can result in the JVM using up all of its file handles.
@@ Line 41: / Line 35: @@
 </pre>
-===Example 2===
+== 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. 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 will run out of available cursors and not be able to execute any more SQL queries.
@@ Line 56: / Line 51: @@
 </pre>
-===Example 3===
+== Example 3 ==
 The following C function does not close the file handle it opens if an error occurs. If the process is long-lived, the process can run out of file handles.
@@ Line 82: / Line 77: @@
 </pre>
 [[Category:Code Quality Vulnerability]]
 [[Category:Java]]

@@ Line 78: / Line 78: @@
 [[Category:Code Quality Vulnerability]]
-[[Category:OWASP_Java_Project]]
+[[Category:Java]]
 [[Category:Implementation]]
 [[Category:Code Snippet]]
 [[Category:Vulnerability]]

@@ Line 1: / Line 1: @@
 {{Template:Vulnerability}}
 {{Template:Fortify}}
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 ==Description==

@@ Line 1: / Line 1: @@
 {{Template:Vulnerability}}
 {{Template:Fortify}}
-==Abstract==
+[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 ==Description==
 Most unreleased resource issues result in general software reliability problems, but if an attacker can intentionally trigger a resource leak, the attacker might be able to launch a denial of service attack by depleting the resource pool.
@@ Line 15: / Line 21: @@
 * Confusion over which part of the program is responsible for releasing the resource.
-'''Example 1:''' The following Java method never closes the file handle it opens. The finalize() method for FileInputStream eventually calls close(), but there is no guarantee as to how long it will take before the finalize() method will be invoked. In a busy environment, this can result in the JVM using up all of its file handles.
+==Risk Factors==
 <pre>
@@ Line 31: / Line 46: @@
 </pre>
-'''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. 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 will run out of available cursors and not be able to execute any more SQL queries.
+===Example 2===
 <pre>
@@ Line 45: / Line 61: @@
 </pre>
-'''Example 3:''' The following C function does not close the file handle it opens if an error occurs. If the process is long-lived, the process can run out of file handles.
+===Example 3===
 <pre>
@@ Line 70: / Line 87: @@
 </pre>
-==Related Attacks==
+==Related [[Attacks]]==
-==Related Vulnerabilities==
+Cryptographic Vulnerability
-==Related Countermeasures==
+Encoding Vulnerability
-==Categories==
+Error Handling Vulnerability
 [[Category:Code Quality Vulnerability]]
 [[Category:Java]]
 [[Category:Implementation]]
 [[Category:Code Snippet]]