Unreleased Resource

The program can potentially fail to release a system resource.

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 attack by depleting the resource pool.

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 as to how long it will 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.

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

Example 2: Under normal conditions the following 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 will not be closed. If this happens often enough, the database will run out of available cursors and not be able to execute any more SQL queries.

        ...
	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 program can potentially fail to release a system resource.

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 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.

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;
}

The program can potentially fail to release a system resource.

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 about 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 might launch a denial of service by depleting the resource pool.

Example 1: The following program 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.

  CALL "CBL_CREATE_FILE"
      USING filename
            access-mode
            deny-mode
            device
            file-handle
  END-CALL

  IF return-code NOT = 0
      DISPLAY "Error!"
      GOBACK
  ELSE
      PERFORM write-data
      IF ws-status-code NOT = 0
          DISPLAY "Error!"
          GOBACK
      ELSE
           DISPLAY "Success!"
      END-IF
  END-IF

  CALL "CBL_CLOSE_FILE"
      USING file-handle
  END-CALL

  GOBACK
  .

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 might be able to launch a denial of service attack by depleting the resource pool.

Example 1: The following method never closes the socket it opens. The New() function establishes a new connection to the system log daemon. It is part of the log.syslog package. Each write to the returned writer sends a log message with the given priority (a combination of the syslog facility and severity) and prefix tag. In a busy environment, this can result in the system using up all of its sockets.

func TestNew() {

	s, err := New(syslog.LOG_INFO|syslog.LOG_USER, "the_tag")
	if err != nil {
		if err.Error() == "Unix syslog delivery error" {
			fmt.Println("skipping: syslogd not running")
		}
		fmt.Println("New() failed: %s", err)
	}
}

Example 2: In this example, the Dial() method of the net/smtp package returns a new client connected to an SMTP server at localhost. The connection resources are allocated but are never released by calling the Close() function.

	func testDial() {
	   client, _ := smtp.Dial("127.0.0.1")
	   client.Hello("")
	}

The program can potentially fail to release a system resource.

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 function does not close the file handle it opens. If the process is long-lived, it may run out of file handles.

BEGIN
...
  F1 := UTL_FILE.FOPEN('user_dir','u12345.tmp','R',256);
  UTL_FILE.GET_LINE(F1,V1,32767);
...
END;