Unreleased Resource

程式可能會無法釋出系統資源。

程式可能會無法釋出系統資源。

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 Denial of Service 攻擊。

範例 1：以下方法從來不會關閉它所開啟的檔案控制碼。在 StreamReader 的 Finalize() 方法最終會呼叫 Close()，但不確定何時會呼叫 Finalize() 方法。事實上，不確定是否會呼叫 Finalize()。在忙碌的環境中，這可能會導致 VM 用盡它所有能使用的檔案控制碼。

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

範例 2：在正常情況下，以下程式碼會執行資料庫查詢，處理資料庫傳回的結果並關閉分配的 SqlConnection 物件。但是，如果在執行 SQL 或處理結果時發生異常，SqlConnection 物件將不會關閉。如果這種情況時常發生的話，那麼資料庫將會用盡可用指標，並且無法再執行任何 SQL 查詢。

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

程式可能會無法釋出系統資源。

程式可能會無法釋出系統資源。

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 Denial of Service。

範例 1：如果發生錯誤，以下函數將不會關閉其開啟的檔案控制代碼。如果此處理程序長時間存留，則處理程序可能會耗盡檔案控制代碼。

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

程式可能會無法釋出系統資源。

程式可能會無法釋出系統資源。

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部分負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，如果攻擊者蓄意觸發資源洩漏的話，就可能會藉由耗盡資源集區的方式來發動 Denial of Service 攻擊。

範例 1：如果發生錯誤，以下程式將無法關閉其開啟的檔案控制代碼。如果此處理程序長時間存留，則處理程序可能會耗盡檔案控制代碼。

  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
  .

程式可能會無法釋出系統資源。

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題。但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 Denial of Service 攻擊。

範例 1：下列方法絕對不會關閉它所開啟的通訊端。New() 函數會建立與系統記錄常駐程式的新連線。它是 log.syslog 套件的一部分。每次寫入傳回的寫入器時，都會傳送一則含有指定優先順序 (系統記錄工具和嚴重性的組合) 和字首標籤的記錄訊息。因此，在繁忙的環境中，這可能會導致系統用盡其所有的通訊端。

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

範例 2：在此範例中，net/smtp 套件的 Dial() 方法將傳回一個新用戶端，這個新用戶端會連線到位於 localhost 的 SMTP 伺服器。連線資源會被分配，但永遠不會透過呼叫 Close() 函數來釋放。

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

程式可能會無法釋出系統資源。

程式可能會無法釋出系統資源。

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 Denial of Service。

範例 1：以下函數不會關閉它所開啟的檔案控制碼。如果執行的時間很長，它可能會耗盡所有的檔案控制碼。

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