The program can potentially fail to release a system resource.

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.

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

Example 1: The following code establishes a lock before performOperationInCriticalSection(), but fails to release the lock if an exception is thrown in that method.

  ReentrantLock  myLock = new ReentrantLock();

  myLock.lock();
  performOperationInCriticalSection();
  myLock.unlock();

The Android activity allocates a media object that is not released in onPause(), onStop(), or onDestroy() callback. The Android OS invokes these callbacks whenever it needs to send the current activity to the background, or when it needs to temporarily destroy the activity when system resources are low. By failing to release the media object properly, the activity causes subsequent accesses to Android's media hardware (by other applications or even the same application) to fall back to the software implementations, or even fail altogether. Leaving too many unreleased media instances open can lead Android to throw exceptions, effectively causing a denial of service. Furthermore, maintaining possession of the media instance while the activity is paused can negatively impact the user's experience by unnecessarily draining the battery.

Example: The following code describes an Android activity that does not override the base onPause() method, which should be used to release the media object, nor does it properly release it during its shutdown sequence.

public class UnreleasedMediaActivity extends Activity {
  private MediaPlayer mp;

  @Override
  public void onCreate(Bundle state) {
      ...
  }

  @Override
  public void onRestart() {
      ...
  }

  @Override
  public void onStop() {
      mp.stop();
  }
}

The Android activity allocates a Camera instance that is not released in onPause(), onStop(), or onDestroy() callback. The Android OS invokes these callbacks whenever it needs to send the current activity to the background, or when it needs to temporarily destroy the activity when system resources are low. By failing to release the Camera object properly, the activity prevents other applications (or even future instances of the same application) from accessing the camera. Furthermore, maintaining possession of the Camera instance while the activity is paused can negatively impact the user's experience by unnecessarily draining the battery.

Example: The following code describes an Android activity that does not override the base onPause() method, which should be used to release the Camera object, nor does it properly release it during its shutdown sequence.

public class UnreleasedCameraActivity extends Activity {
  private Camera cam;

  @Override
  public void onCreate(Bundle state) {
      ...
  }

  @Override
  public void onRestart() {
      ...
  }

  @Override
  public void onStop() {
      cam.stopPreview();
  }
}

The Android activity maintains an Android SQLite database handler that is not closed in onPause(), onStop(), or onDestroy() callback. The Android OS invokes these callbacks whenever it needs to send the current activity to the background, or when it needs to temporarily destroy the activity when system resources are low. By failing to close the database properly, the activity can potentially exhaust the device of available cursors if the activity is constantly restarted. In addition, depending on the implementation, the Android operating system can also throws DatabaseObjectNotClosedException, which crashes the application if the exception is not caught.

Example: The following code describes an Android activity that caches user data and writes the data to disk when the activity is stopped. Note that does not override the base onPause(), which should be used to release the database object, nor does it properly release it during its shutdown sequence.

public class MyDBHelper extends SQLiteOpenHelper {
  ...
}

public class UnreleasedDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }

  @Override
  public void onRestart() {
      ...
  }

  @Override
  public void onStop() {
      db.insert(cached_data);     // flush cached data
  }
}

The program fails to properly dispose of a managed object that uses unmanaged system resources.
Failure to properly dispose of a managed object that uses unmanaged system resources has at least two common causes:

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

A small subset of managed .NET objects use unmanaged system resources. .NET's Garbage Collector may not free the original managed objects in a predictable way. As such, the application may run out of available memory as the Garbage Collector is unaware of the memory consumed by the unmanaged resources. Most unmanaged resource leak issues result in general software reliability problems, but if an attacker can intentionally trigger an unmanaged resource leak, the attacker may be able to launch a denial of service attack by depleting the unmanaged resource pool.

Example 1: The following method creates a managed Bitmap Object from an incoming stream incomingStream. The Bitmap is manipulated and persisted to the outgoing stream outgoingStream. The Dispose() method of incomingBitmap and outgoingBitmap is never explicitly called.

Normally, one can safely rely upon the Garbage Collector to do this at a safe time for managed objects that do not use unmanaged system resources. The Garbage Collector calls Bitmap.Dispose() when it sees fit. However, the Bitmap object utilizes scarce, unmanaged system resources. The Garbage Collector may fail to call Dispose() before the unmanaged resource pool is depleted.

private void processBitmap(Stream incomingStream, Stream outgoingStream, int thumbnailSize)
{
	Bitmap incomingBitmap = (Bitmap)System.Drawing.Image.FromStream(incomingStream);

	bool validBitmap = validateBitmap(incomingBitmap);
	if (!validBitmap)
		throw new ValidationException(incomingBitmap);

	Bitmap outgoingBitmap = new Bitmap(incomingBitmap, new Size(thumbnailSize, thumbnailSize));
	outgoingBitmap.Save(outgoingStream, ImageFormat.Bmp);
}

Application resources containing sensitive information or providing privileged functionality are generally at a greater risk of exploitation. During the reconnaissance phase, an attacker will make attempts to discover such files and directories. Using predictable naming schemes for such resources makes it easier for the attacker to locate them. All the application resources that deal with sensitive functionality such as authentication, administrative tasks, or handling of private information must be sufficiently protected from discovery.

Example 1: In the following example, the admin application is deployed in a predictable URL:

from django.conf.urls import patterns
from django.contrib import admin

admin.autodiscover()

urlpatterns = patterns('',
    ...
    url(r'^admin/', include(admin.site.urls)),
    ...

Resources responsible for storing data must be separated from those that implement application functionality. Programmers must exercise caution when creating temporary or backup resources.

Billable computational resources include but are not limited to CPU usage, memory, persistent storage, and network connections. In the absence of resource usage limits, attackers could cause a denial of service that consumes all available resources or incur exorbitant bills.