Um identificador é uma referência que representa um recurso do sistema, como uma parte da memória ou um arquivo. Nesse caso, o código falha em liberar um identificador de forma confiável ao invocar de forma insegura um método perigoso sem sua contraparte correspondente.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, ele poderá iniciar uma negação de serviço esgotando o pool de recursos.

Exemplo 1: O código a seguir cria uma nova instância de SafeEvpPKeyHandle, mas chama o método DangerousAddRef sem uma chamada correspondente para DangerousRelease.

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

Exemplo 2: O código a seguir cria uma nova instância de SafeEvpPKeyHandle, mas chama o método DangerousRelease sem uma chamada correspondente para DangerousAddRef.

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

Um identificador é uma referência que representa um recurso do sistema, como uma parte da memória ou um arquivo. Nesse caso, o código não define o objeto atual como o proprietário do identificador subjacente, o que não libera o identificador de forma confiável após o objeto ter sido descartado.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, ele poderá iniciar uma negação de serviço esgotando o pool de recursos.

Exemplo 1: O código a seguir cria uma nova instância de SafeEvpPKeyHandle, mas não permite que o objeto libere o identificador de forma confiável durante a fase de finalização, definindo o parâmetro ownsHandle como false.

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

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

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

Um identificador é uma referência que representa um recurso do sistema, como uma parte da memória ou um arquivo. Nesse caso, o código não consegue liberar um identificador de forma confiável ao usá-lo depois que ele foi invalidado.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, ele poderá iniciar uma negação de serviço esgotando o pool de recursos.

Exemplo 1: O código a seguir cria uma nova instância de SafeEvpPKeyHandle, mas chama DangerousGetHandle depois que o identificador foi invalidado por SetHandleAsInvalid, que potencialmente retorna um valor de identificador obsoleto.

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

O programa talvez não consiga liberar um recurso LDAP.

Vazamento de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar um ataque de negação de serviço esgotando o pool de recursos.

Exemplo 1: Em condições normais, o código a seguir executa uma consulta LDAP, processa os resultados retornados pelo Active Directory e fecha o objeto DirectoryEntry alocado. Mas, se ocorrer uma exceção durante a execução da consulta LDAP ou o processamento dos resultados, o objeto DirectoryEntry não será fechado. Isso introduzirá um vazamento de memória no aplicativo, poisDirectoryEntry usa APIs COM internamente para consultar o servidor do Active Directory.

  ...
  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();
  ...

O programa talvez não consiga liberar um soquete.


Vazamento de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar um ataque de negação de serviço esgotando o pool de recursos.

Exemplo 1: O método a seguir nunca fecha o soquete que ele abre. Em um ambiente muito ativo, isso pode fazer com que a JVM use todos os seus soquetes.

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

Exemplo 2: Em condições normais, a correção a seguir fecha corretamente o soquete e quaisquer fluxos associados. Porém, se ocorrer uma exceção durante a leitura da entrada ou a gravação dos dados no fluxo, o objeto de soquete não será fechado. Se isso acontecer com frequência suficiente, o sistema ficará sem soquetes e não poderá lidar com mais conexões.

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

O programa talvez não consiga liberar um recurso do sistema.

Vazamento de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar um ataque de negação de serviço esgotando o pool de recursos.

Exemplo 1: O método a seguir nunca fecha o identificador de arquivo que ele abre. O método finalize() para FileInputStream eventualmente chama close(), mas não há garantia de quanto tempo levará até que o método finalize() será invocado. Em um ambiente muito ativo, isso pode fazer com que a JVM use todos os seus identificadores de arquivo.

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

O programa talvez não consiga liberar um recurso do sistema.

Vazamento de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar uma negação de serviço esgotando o pool de recursos.

Exemplo 1: O código a seguir estabelece um bloqueio antes de performOperationInCriticalSection(), mas não consegue liberá-lo quando uma exceção é lançada nesse método.

ReentrantLock  myLock = new ReentrantLock ();

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

O programa não consegue descartar corretamente um objeto gerenciado que utiliza recursos de sistema não gerenciados.
A incapacidade de descartar corretamente um objeto gerenciado que utiliza recursos de sistema não gerenciados tem pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.
- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

Um pequeno subconjunto de objetos .NET gerenciados usa recursos de sistema não gerenciados. O Coletor de Lixo do .NET pode não liberar os objetos gerenciados originais de maneira previsível. Dessa forma, o aplicativo pode esgotar a memória disponível, já que o Coletor de Lixo não está ciente da memória consumida pelos recursos não gerenciados. A maioria dos problemas de vazamento de recursos não gerenciados resulta em problemas gerais de confiabilidade de software. Porém, se um invasor puder provocar intencionalmente um vazamento de recursos não gerenciados, talvez ele consiga lançar um ataque de negação de serviço esgotando o pool de recursos.

Exemplo 1: O método a seguir cria um Objeto de Bitmap gerenciado a partir de um fluxo de entrada incomingStream. O Bitmap é manipulado e mantido como persistente no fluxo de saída outgoingStream. O método Dispose() de incomingBitmap e outgoingBitmap nunca é chamado explicitamente.

Normalmente, é possível contar com o Coletor de Lixo para fazer isso em uma ocasião segura para objetos gerenciados que não utilizam recursos de sistema não gerenciados. O Coletor de Lixo chama Bitmap.Dispose() quando ele considera apropriado. No entanto, o objeto Bitmap utiliza recursos de sistema não gerenciados escassos. O Coletor de Lixo talvez não consiga chamar Dispose() antes que o pool de recursos não gerenciados se esgote.

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

Erros de uso após a liberação podem ocorrer quando um programa continua a usar um ponteiro depois que ele é liberado. Como erros de liberação dupla e vazamentos de memória, erros de uso após a liberação têm duas causas comuns e por vezes sobrepostas:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável por liberar a memória.

Erros de uso após a liberação às vezes não têm nenhum efeito e outras vezes fazem com que um programa falhe. Embora seja tecnicamente possível que a memória liberada seja realocada e que um invasor use essa realocação para lançar um ataque de buffer overflow, não temos conhecimento de qualquer exploração com base nesse tipo de ataque.

Exemplo 1: O código a seguir ilustra um erro de uso após a liberação:

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