ハンドルは、メモリの一部やファイルなどのシステム リソースを表す参照です。この場合、コードは、対応する同等のメソッドを使用せずに危険なメソッドを安全でない方法で呼び出しているため、ハンドルを確実に解放できません。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。ただし、攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service を開始するよう試みる可能性があります。

例 1: 次のコードは、SafeEvpPKeyHandle の新しいインスタンスを作成しますが、対応する DangerousRelease の呼び出しを行わずに DangerousAddRef メソッドを呼び出しています。

var pkey = NativeMethods.ENGINE_LOAD_SSL_PRIVATE_KEY(...);
var safeEvpHandle = new SafeEvpPKeyHandle(handle: handle, ownsHandle: true);
bool success = false;

try {
    safeEvpHandle.DangerousAddRef(ref success);
    var handle = safeEvpHandle.DangerousGetHandle();
} catch (ObjectDisposedException ex) { 
    //...
} finally {
    safeEvpHandle.close();
}

例 2: 次のコードは、SafeEvpPKeyHandle の新しいインスタンスを作成しますが、対応する DangerousAddRef の呼び出しを行わずに DangerousRelease メソッドを呼び出しています。

var pkey = NativeMethods.ENGINE_LOAD_SSL_PRIVATE_KEY(...);
var safeEvpHandle = new SafeEvpPKeyHandle(handle: handle, ownsHandle: true);
bool success = false;

try {
    var handle = safeEvpHandle.DangerousGetHandle();
} catch (ObjectDisposedException ex) { 
    //...
} finally {
    safeEvpHandle.DangerousRelease();
    safeEvpHandle.close();
}

ハンドルは、メモリの一部やファイルなどのシステム リソースを表す参照です。この場合、コードは現在のオブジェクトを基礎となるハンドルの所有者として設定しないため、オブジェクトが破棄された後にハンドルを確実に解放できません。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。ただし、攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service を開始するよう試みる可能性があります。

例 1: 次のコードは、SafeEvpPKeyHandle の新しいインスタンスを作成しますが、ownsHandle パラメーターを false に設定することによって完了処理フェーズ中にオブジェクトがハンドルを確実に解放できるようにすることはできません。

var pkey = NativeMethods.ENGINE_LOAD_SSL_PRIVATE_KEY(...);

var safeEvpHandle = new SafeEvpPKeyHandle(handle: handle, ownsHandle: false);

if (safeEvpHandle.IsInvalid) {
	...
}
safeEvpHandle.close();

ハンドルは、メモリの一部やファイルなどのシステム リソースを表す参照です。この場合、コードは、無効化された後のハンドルを使用してハンドルを確実に解放することができません。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。ただし、攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service を開始するよう試みる可能性があります。

例 1: 次のコードは、SafeEvpPKeyHandle の新しいインスタンスを作成しますが、SetHandleAsInvalid によってハンドルが無効化された後に DangerousGetHandle を呼び出しており、古いハンドルの値が返される可能性があります。

var pkey = NativeMethods.ENGINE_LOAD_SSL_PRIVATE_KEY(...);
var safeEvpHandle = new SafeEvpPKeyHandle(handle: handle, ownsHandle: true);
...
safeEvpHandle.SetHandleAsInvalid();
...
var handle = safeEvpHandle.DangerousGetHandle();
...
safeEvpHandle.close();

プログラムは LDAP リソースの開放に失敗する可能性があります。

リソースリークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service 攻撃を開始する可能性があります。

例 1: 通常の条件下では、次のコードは LDAP クエリを実行し、Active Directory から戻された結果を処理し、割り当てられた DirectoryEntry オブジェクトを閉じます。ただし、LDAP クエリの実行中または結果処理中に例外が発生すると、DirectoryEntry オブジェクトは閉じません。DirectoryEntry では Active Directory サーバーのクエリに COM API が内部的に使用されるため、これによりメモリ リークが発生します。

  ...
  DirectoryEntry entry = new DirectoryEntry("LDAP://CN=users,DC=fabrikam,DC=com");
  DirectorySearcher mySearcher = new DirectorySearcher(entry);
  SearchResultCollection result = mySearcher.FindAll();
  CheckUsers(result);
  mySearcher.Dispose();
  entry.Close();
  ...

プログラムはソケットの解放に失敗する可能性があります。


リソースリークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service 攻撃を開始する可能性があります。

例 1: 次のメソッドは、開いたソケットを閉じていません。つまり、使用中の環境では JVM ですべてのソケットを使い切ってしまう場合もあります。

private void echoSocket(String host, int port) throws UnknownHostException, SocketException, IOException
{
  Socket sock = new Socket(host, port);
  BufferedReader reader = new BufferedReader(new InputStreamReader(sock.getInputStream()));

  while ((String socketData = reader.readLine()) != null) {
    System.out.println(socketData);
  }
}

例 2: 通常の状況下では、次の修正プログラムは、ソケットと関連するストリームを適切に閉じています。しかし、入力を読み取るときや画面にデータを書き込むときに例外が発生すると、ソケットオブジェクトが閉じられない場合があります。この状況が頻繁に発生すると、システムはソケットを使い果たし、それ以降の接続を処理できなくなります。

private void echoSocket(String host, int port) throws UnknownHostException, SocketException, IOException
{
  Socket sock = new Socket(host, port);
  BufferedReader reader = new BufferedReader(new InputStreamReader(sock.getInputStream()));

  while ((String socketData = reader.readLine()) != null) {
    System.out.println(socketData);
  }
  sock.close();
}

プログラムはシステムリソースの解放に失敗する可能性があります。

リソースリークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service 攻撃を開始する可能性があります。

例 1: 次のメソッドは、開いたファイル ハンドルを閉じていません。FileInputStream の finalize() メソッドは最終的に close() をコールしますが、finalize() メソッドが呼び出されるまでにどれくらいの時間がかかるかは保証されません。つまり、使用中の環境では JVM ですべてのファイル ハンドルを使い切ってしまう場合もあります。

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

プログラムはシステムリソースの解放に失敗する可能性があります。

リソースリークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service を開始する可能性があります。

例 1: 次のコードは、performOperationInCriticalSection() の前にロックを確立しますが、このメソッドで例外が発生する場合にはロックを解放しません。

ReentrantLock  myLock = new ReentrantLock ();

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

プログラムは管理対象外のシステムリソースを使用する管理対象オブジェクトを適切に処理できません。
管理対象外のシステムリソースを使用する管理対象オブジェクトを適切に処理できない場合には、少なくとも 2 つの原因があります。

- エラー条件などの例外的状況。
- プログラムのどの部分がリソースを解放するかに関する混乱。

管理対象 .NET オブジェクトの小さなサブセットは、管理対象外のシステムリソースを使用します。.NET のガベージコレクタは、予測できる方法で、元の管理対象オブジェクトを解放しない場合があります。この場合、ガベージコレクタが管理対象外のリソースにより消費されるメモリを認識しないため、アプリケーションが利用可能なメモリをすべて消費してしまう可能性があります。管理対象外のリソース リークの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者による意図的な管理対象外のリソース リークが可能な場合、攻撃者は管理対象外のリソース プールを枯渇させることにより、Denial of Service 攻撃を開始する可能性があります。

例 1: 次のメソッドでは、受信したストリーム incomingStream から管理対象の Bitmap オブジェクトを作成しています。この Bitmap は処理され、送信ストリーム outgoingStream に残ります。incomingBitmap および outgoingBitmap の Dispose() メソッドは明示的にコールされていません。

通常は、管理対象外のシステムリソースを使用しない管理対象オブジェクトについては、ガベージコレクタを信頼して、安全にこの処理を実行させることができます。ガベージ コレクタは、Bitmap を見つけると、Bitmap.Dispose() をコールします。しかし、この Bitmap オブジェクトは、まれな、管理対象外のシステム リソースを使用しています。そのため、ガベージ コレクタは、Dispose() をコールできずに、管理対象外のリソース プールが枯渇してしまう可能性があります。

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

ポインタを解放した後で、プログラムがそのポインタを使用し続ける場合に、Use After Free エラーが発生します。Double Free エラーや Memory Leak と同様に、Use After Free エラーには 2 つの一般的な原因があり、これらが重なっていることもあります。

- エラー条件などの例外的状況。

- プログラムのどの部分でメモリを解放するかに関して混乱が発生している。

Use After Free エラーは、何も影響を生じないこともありますが、プログラムをクラッシュさせることがあります。技術的には、解放されたメモリの再割り当てが可能であり、この再割り当てを使用した Buffer Overflow 攻撃も可能ですが、このタイプの攻撃に基づく悪用には気が付きません。

例 1: 次のコードは Use After Free エラーの例です。

char* ptr = (char*)malloc (SIZE);
...
if (err) {
    abrt = 1;
    free(ptr);
}
...
if (abrt) {
    logError("operation aborted before commit", ptr);
}