Erros de liberação dupla ocorrem quando free() é chamado mais de uma vez com o mesmo endereço de memória que um argumento.



Chamar free() duas vezes no mesmo valor pode resultar em um buffer overflow. Quando um programa chama free() duas vezes com o mesmo argumento, as estruturas de dados de gerenciamento de memória desse programa se tornam corrompidas. Essa corrupção pode fazer com que o programa trave ou, em algumas circunstâncias, com que duas chamadas posteriores para malloc() retornem o mesmo apontador. Se malloc() retornar o mesmo valor duas vezes, e, mais tarde, o programa der ao invasor controle sobre os dados que são gravados nessa memória duplamente alocada, o programa se tornará vulnerável a um ataque de buffer overflow.

Exemplo 1: O código a seguir mostra um exemplo simples de uma vulnerabilidade de liberação dupla.

	char* ptr = (char*)malloc (SIZE);
	...
	if (abrt) {
	  free(ptr);
	}
	...
	free(ptr);

Vulnerabilidades de liberação dupla têm duas causas em comum (e algumas 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.

Embora algumas vulnerabilidades de liberação dupla não sejam muito mais complicadas do que o exemplo anterior, a maioria se dispersa entre centenas de linhas de código ou até mesmo arquivos diferentes. Programadores parecem particularmente susceptíveis a liberar variáveis globais mais de uma vez.

O código-fonte que contém caracteres de controle de substituição bidirecional Unicode pode ser um sinal de um ataque de ameaça interna. Esse ataque pode ser alavancado por meio da cadeia de suprimentos para linguagens de programação como C, C++, C#, Go, Java, JavaScript, Python e Rust. Diversas variantes de ataque já foram publicados por Nicholas Boucher e Ross Anderson, incluindo: Retornos iniciais, comentários e strings estendidas.
Exemplo 1: O código a seguir exibe um caractere de controle, presente em um arquivo de código-fonte C, que leva a um ataque de Retorno Antecipado:

#include <stdio.h>

int main() {
	/* Nothing to see here; newline RLI /*/ return 0 ;
	printf("Do we get here?\n");
	return 0;
}

O caractere Unicode de controle bidirecional isolado da direita para a esquerda (RLI), em Example 1, faz com que o código seja visto como o seguinte:

#include <stdio.h>

int main() {
	/* Nothing to see here; newline; return 0 /*/
	printf("Do we get here?\n");
	return 0;
}

É importante ressaltar que um desenvolvedor que realiza uma revisão de código, em um editor/visualizador vulnerável, não veria visivelmente o que um compilador vulnerável processará. Especificamente, a instrução de retorno antecipado que modifica o fluxo do programa.

Essa biblioteca é considerada experimental e não deve ser usada em ambientes de produção, a menos que você saiba o que está fazendo.

O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de buffer overflow de pilha ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e erros "off-by-one", entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Nesse caso, uma cadeia de formato indevidamente construída faz com que o programa acesse valores fora dos limites da memória alocada.

Exemplo: O exemplo a seguir lê valores arbitrários da pilha, porque o número de especificadores de formato não está alinhado ao número de argumentos transmitidos para a função.

void wrongNumberArgs(char *s, float f, int d) {
   char buf[1024];
   sprintf(buf, "Wrong number of %.512s");
}

O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de buffer overflow de pilha ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e erros "off-by-one", entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Nesse caso, uma cadeia de formato indevidamente construída faz com que o programa converta valores de dados ou acesse valores fora dos limites da memória alocada.

Exemplo: O código a seguir converte incorretamente f de um flutuante usando um especificador de formato %d.

void ArgTypeMismatch(float f, int d, char *s, wchar *ws) {
   char buf[1024];
   sprintf(buf, "Wrong type of %d", f);
   ...
}

Uma Intent interna usa uma ação personalizada conforme definido por um componente interno. Intenções implícitas podem facilitar a chamada de intenções de qualquer componente externo sem o conhecimento do componente específico. A combinação das duas permite que um aplicativo acesse intenções especificadas para um uso interno específico fora do contexto do aplicativo desejado.

A capacidade de processar uma Intent interna de um aplicativo externo pode permitir uma ampla variedade de explorações man-in-the-middle que variam em gravidade desde vazamento de informações e negação de serviço até execução remota de código, dependendo da capacidade de ação interna especificada pela Intent.

Exemplo 1: O código a seguir usa uma Intent interna implícita.

...
val imp_internal_intent_action = Intent("INTERNAL_ACTION_HERE")
startActivity(imp_internal_intent_action)
...

Intents Android são usadas para vincular aplicativos e componentes de aplicativos, fornecendo instruções sobre ações que um determinado componente executa. As intenções pendentes são criadas para entregar a Intent posteriormente. As intenções implícitas facilitam a chamada de intenções de qualquer componente externo, usando um nome geral e um filtro para determinar a execução.

Quando uma Intent implícita é criada como uma PendingIntent, isso pode permitir que Intent seja enviada para um componente não intencional que é executado fora do contexto temporal pretendido, deixando o sistema vulnerável a explorar vetores como negação de serviço, vazamento de informações privadas e do sistema e escalonamento de privilégios.

Exemplo 1: O seguinte código usa uma PendingIntent implícita.

...
val imp_intent = Intent()
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable_impintintent = PendingIntent.getService(
    this,
    0,
    imp_intent,
    flag_mut
)
...