Programação defensiva e memória

Uma função que aceita nomes precisa de um contrato. Chama-se contrato às regras sobre que tipo de dados recebe, que tamanho admite e que faz quando a entrada é inválida. Uma entrada vinda da rede não passa a ser confiável só porque o formulário a validou no navegador, porque o atacante pode enviar o pedido diretamente.

Validar e interpretar

Valida tipo, tamanho, intervalo e significado no servidor. Uma lista de permissão define o conjunto aceite; uma lista de negação tenta excluir padrões perigosos. Uma lista de negação pode complementar um controlo, mas tende a falhar quando existem muitas representações equivalentes.

A validação não substitui a separação entre dados e instruções. Um apelido legítimo pode conter uma aspa. Rejeitar aspas não é a solução geral para SQL: os parâmetros separam os valores da estrutura da consulta. Para HTML, a codificação depende do contexto de saída.

Ao validar caminhos, normalizar e verificar uma pasta permitida pode detetar ../. Porém, verificar o caminho e abri-lo depois ainda pode permitir uma troca de ligações simbólicas. As operações de abertura e verificação têm de preservar a identidade do objeto, conforme as regras do sistema operativo.

Format strings: o formato é uma instrução

Em printf(formato, ...), o primeiro argumento descreve como interpretar os seguintes. Por isso, printf(entrada) deixa a entrada escolher essa interpretação. Mesmo sem overflow, uma entrada com especificadores pode pedir leituras ou escritas para argumentos que o programa não forneceu.

%n não imprime o inteiro apontado: é uma escrita. Argumentos ausentes, tipos incompatíveis ou ponteiros inválidos produzem comportamento indefinido; não permitem prever uma saída portátil. Por exemplo, não executes %s com um ponteiro nulo para tentar obter um resultado garantido.

Uma entrada com formato controlado também é uma primitiva de leitura potencial: pode levar a implementação a interpretar argumentos inexistentes e, nesta máquina de laboratório x86, a devolver valores lidos de posições da pilha, que podem incluir segredos ou o canário da secção seguinte. Em C, argumentos ausentes ou incompatíveis dão comportamento indefinido, sem saída portátil garantida, como exige printf(3). Por isso uma fuga de formato pode anular uma defesa que dependa de um valor imprevisível, sem prometer fuga automática em qualquer ABI.

No programa seguinte só há formatos literais e argumentos válidos: o % da entrada é dado, não um especificador, e no segundo printf o %n guarda 3 antes de serem impressos ! e a mudança de linha.

#include <stdio.h>

int main(void) {
    const char *entrada = "100% concluido";
    int escritos = -1;
    printf("%s\n", entrada);
    printf("abc%n!\n", &escritos);
    printf("Contagem guardada: %d\n", escritos);
    return 0;
}

Para mostrar texto externo, usa printf("%s", entrada) ou uma API de texto apropriada. Isto não valida tamanho, ponteiro ou contexto HTML: cada problema exige o seu contrato.

Chamada normal antes da corrupção

Numa chamada típica, o chamador coloca argumentos, executa call, que guarda o endereço de retorno, e o chamado cria o seu frame. Variáveis locais ficam nesse frame. Ao terminar, o chamado repõe o frame e executa ret, que retoma o endereço guardado. Uma corrupção só faz sentido contra este percurso: algum passo escreve fora do objeto e alcança dados de controlo como o endereço de retorno.

Buffer overflow

Um buffer de 8 bytes permite uma string de até 7 bytes mais o terminador nulo. strcpy não conhece a capacidade de destino. Copiar 12 letras e o terminador escreve 13 bytes, cinco para além do buffer.

void saudar(const char *nome) {
    char buf[8];
    strcpy(buf, nome); /* não verifica a capacidade de buf */
    printf("%s\n", buf);
}

Isto é comportamento indefinido: pode corromper dados, falhar ou permitir desvio de execução, conforme a disposição da memória e as proteções, por isso não deduzas da ordem das declarações qual variável será alterada.

Seguir a pilha no modelo x86

Os exemplos das aulas usam um modelo Linux/x86. Num processo, código, dados estáticos, heap e pilha têm papéis diferentes. Globais e estáticos não passam a estar na pilha só por serem usados numa função. A heap guarda alocações dinâmicas; a pilha guarda contextos de chamadas segundo a convenção adotada.

Num exemplo convencional de x86 de 32 bits com frame pointer, a pilha cresce para endereços menores. ebp referencia o frame; variáveis locais podem estar em offsets negativos, e o endereço de retorno em ebp+4. Esta disposição não vale para todos os binários, otimizações ou arquiteturas.

Suponhamos que o enunciado fixa buf em ebp-16, com 12 bytes, e o endereço de retorno em ebp+4. A cópia da string escreve em endereços crescentes. A diferença entre os endereços é $4-(-16)=20$ bytes. O byte no índice 20 da cópia atinge o primeiro byte do endereço de retorno; no mapa seguinte, buf ocupa de ebp-16 a ebp-5, os bytes 16 a 19 cobrem o valor guardado de ebp e o índice 20 alcança o retorno.

A cópia avança para endereços maiores: o índice 12 já sai do buffer e o índice 20 alcança o retorno. A pilha cresce para endereços menores ao criar frames, por isso não confundas os dois sentidos.

Com vinte caracteres de um byte, esse byte seria o terminador; não precisamos de copiar um endereço completo para ter uma escrita indevida.

A little-endian, o inteiro de 32 bits 0x11223344 ocupa, em endereços crescentes, os bytes 44 33 22 11. A ordem dos bytes é diferente da direção em que a pilha cresce, por isso distingue endianness, offsets e sentido da cópia antes de analisar um desenho.

Este exemplo analisa uma disposição dada, sem executar código injetado nem pressupor que o programa real terá esses offsets. Linguagens com verificação de memória reduzem estas classes de erro, mas bibliotecas nativas e componentes inferiores continuam a precisar de análise.

Corrigir a cópia

Se nome é uma string terminada em nulo válida, mede antes de copiar e rejeita o que não cabe, porque n >= sizeof buf inclui o caso em que falta espaço para o terminador.

#include <stdio.h>
#include <string.h>

static void saudar(const char *nome) {
    char buf[8];
    size_t n = strlen(nome);
    if (n >= sizeof buf) {
        puts("Nome demasiado comprido.");
        return;
    }
    memcpy(buf, nome, n + 1);
    printf("Olá, %s!\n", buf);
}

int main(void) {
    saudar("Ana");
    saudar("1234567");
    saudar("12345678");
    return 0;
}

Estamos a contar bytes, não letras Unicode: uma letra acentuada pode ocupar vários bytes em UTF-8. Para dados recebidos como bloco binário, não uses strlen sem garantir um terminador dentro de memória acessível. Nesse caso, recebe o comprimento e valida-o explicitamente.

strncpy pode não escrever um terminador quando a origem é longa. Também pode truncar silenciosamente um identificador e fazê-lo colidir com outro. Escolhe entre rejeitar e truncar de acordo com o contrato, em vez de assumir que qualquer função com “n” no nome resolve o problema.

Outros erros de memória

Um overflow na heap ultrapassa uma alocação dinâmica. Duas chamadas consecutivas a malloc não garantem que os objetos sejam adjacentes, nem permitem deduzir qual objeto será corrompido. Os slides mostram alocadores com metadados e ponteiros de controlo, mas a disposição e as verificações dependem do alocador. NX não impede alterar dados ou um ponteiro de função.

Um use-after-free usa uma referência depois de libertar o objeto. Segue o estado, sem executar o acesso inválido:

Um double free tenta libertar o mesmo objeto duas vezes. Anular um ponteiro depois de libertar pode evitar o seu uso, mas não anula outras referências copiadas antes.

Um integer overflow pode transformar um tamanho grande num tamanho pequeno antes da alocação. Por exemplo, com size_t de 32 bits e itens de 8 bytes, este cálculo reserva pouco e escreve muito quando quantidade é grande:

typedef struct { unsigned char b[8]; } item;
size_t total = quantidade * sizeof(item);
item *p = malloc(total); /* se a multiplicação excede SIZE_MAX, total envolve */
for (size_t i = 0; i < quantidade; i++)
    p[i] = itens[i];

quantidade conta itens e total conta bytes; o ciclo copia item a item. Verifica a multiplicação antes de alocar, por exemplo rejeitando quando quantidade > SIZE_MAX / sizeof(item).

Leituras fora dos limites

Uma leitura indevida pode divulgar dados sem alterar memória. Considera uma mensagem com quatro bytes de conteúdo que declara ter 32. Se o servidor confia no comprimento declarado e devolve 32 bytes a partir desse conteúdo, tenta ler 28 bytes que não pertencem à mensagem. Não podemos prever quais seriam esses bytes, mas a ausência de escrita não elimina o risco de confidencialidade.

Antes de usar o comprimento, compara-o com os bytes realmente disponíveis. Num vetor de comprimento len, um índice inteiro com sinal precisa de satisfazer 0 <= indice < len. Só testar indice < len deixa passar valores negativos; usar indice <= len deixa passar o primeiro índice para além do fim.

Conversões de tamanho

Um tamanho pode perder informação antes da verificação. Suponhamos um comprimento sem sinal de 65 540 que é guardado num campo sem sinal de 16 bits. O campo fica com $65\,540\bmod2^{16}=4$. Verificar que o campo é menor que 100 não demonstra que o conteúdo original cabe num buffer de 100 bytes.

Conserva a representação do comprimento efetivamente usado e rejeita valores que não cabem no tipo de destino antes de converter. Em C, a aritmética sem sinal envolve segundo o módulo do tipo; overflow de inteiros com sinal tem regras diferentes e pode ser comportamento indefinido. As promoções de inteiros também contam: uma operação com operandos de tipo pequeno pode ser calculada em int. Declara os tipos antes de prever o resultado.

Injeção e reutilização de código

Heap spraying coloca muitas cópias de dados numa região para aumentar a hipótese de um desvio a atingir. JIT spraying procura influenciar bytes de código gerados pelo compilador em execução. São estratégias diferentes: a primeira, por si, não transforma páginas não executáveis em código executável. Em ambos os casos ainda é necessário um caminho que viole a proteção ou desvie o fluxo. Não são efeitos garantidos de qualquer overflow.

As proteções têm objetivos distintos. Um canário pode detetar algumas alterações na pilha antes do retorno. NX impede executar certas páginas de dados. ASLR dificulta prever endereços. Nenhuma destas proteções corrige o acesso fora dos limites, porque ataques que reutilizam código existente podem evitar a necessidade de executar bytes na pilha.

Reutilização de código e ROP

NX impede executar páginas marcadas como não executáveis. Não impede executar instruções que já pertencem a páginas de código. Return-oriented programming, ou ROP, encadeia pequenos trechos existentes, chamados gadgets, usando desvios como ret. Reutilizar funções completas é um caso mais simples para seguir a ideia de controlo por endereços de retorno.

Neste modelo didático (x86 de 32 bits, argumentos na pilha, funções que não retiram os argumentos ao retornar, sem canário nem rearranjo da pilha), queremos visitar etapaA() e depois etapaB(7); os nomes são símbolos, não endereços de um programa explorável.

Segue a sequência de retornos no modelo didático:

1. O primeiro ret consome etapaA e deixa o topo em etapaB.
2. A entrada de etapaA vê etapaB como endereço de retorno.
3. O retorno de etapaA consome esse endereço. etapaB vê agora continuação como retorno e 7 como argumento.
4. Quando etapaB retorna, a execução segue para continuação; o valor 7 ainda exige tratamento conforme a convenção.

Não podemos acrescentar livremente argumentos às etapas anteriores: sem ajuste, esses valores ficariam no caminho dos retornos. Cadeias gerais usam instruções que ajustam a pilha e, noutras arquiteturas, preparam registos. Não extrapoles esta disposição para x86-64 ou para qualquer convenção de chamada.

ASLR dificulta localizar código; uma fuga de endereços pode reduzir essa proteção. Verificação de integridade do fluxo de controlo e mecanismos de retorno protegido procuram restringir os destinos. A correção continua a ser remover a corrupção de memória que permite controlar o fluxo.

Control-Flow Integrity, ou CFI, verifica em execução se certos desvios seguem destinos admitidos pelo modelo de fluxo de controlo. Não é uma verificação de todos os índices ou comprimentos. Se um acesso fora dos limites corrompe apenas dados, sem violar um desvio verificado, pode continuar a escapar a CFI. O conjunto de destinos, os desvios cobertos e a precisão da política determinam o limite da proteção. A distinção face a SFI e interposição de chamadas fica para sistemas seguros.

Canários: o que está a ser verificado?

Um canário fica numa posição que certas escritas entre um buffer e o retorno têm de atravessar. Antes de retornar, o programa verifica se o valor mudou. Uma alteração provoca a interrupção, em vez de continuar com o retorno corrompido. Não protege todos os objetos nem escritas que saltem diretamente para outra posição.

Um canário terminador, em construções históricas, contém bytes que terminam operações de texto, como nulo e mudança de linha. Uma cópia que para no nulo não consegue transportar esse byte e continuar com o resto da entrada. A justificação depende da função: uma cópia binária com comprimento explícito pode transportar bytes nulos.

Um canário aleatório depende de o valor ser imprevisível e não ser exposto. Uma fuga que o revele pode permitir reproduzi-lo numa escrita. Uma leitura com formato controlado sobre a pilha é uma forma concreta de obter essa fuga nesta máquina de laboratório, por isso as duas secções analisam-se em conjunto. Construções históricas XOR também ligam o valor protegido ao endereço de retorno. Nenhum tipo é sempre superior: especifica a primitiva de cópia, a informação disponível e a disposição da pilha. Implementações atuais podem combinar aleatoriedade com bytes terminadores.

Análise estática, dinâmica e taint

Taint analysis acompanha dados de origens não confiáveis (sources) até operações sensíveis (sinks). Ler uma linha da rede é uma origem; usá-la como formato de printf é um sink. Concatenação e atribuição podem propagar a marca. Uma transformação só é uma sanitização se estabelecer a condição exigida por aquele sink.

Suponhamos linha = ler_rede(); copia = linha; printf(copia);. A marca chega ao formato através da cópia, mesmo que a variável tenha outro nome. Mudar para printf("%s", copia) remove o controlo do formato. Nesse caso, copia continua externa mas passa como dado. Isto não prova que é uma string válida ou que outro uso será seguro.

Um teste dinâmico com apenas Ana pode não revelar um problema que depende de %. A análise estática pode identificar o fluxo potencial, mas precisa de modelar ler_rede e a chamada de impressão. Usa as duas técnicas como evidências complementares, não como provas automáticas de ausência de falhas.

TOCTOU

Uma race condition depende da ordem de operações concorrentes. TOCTOU ocorre quando uma condição muda entre a verificação e o uso. Verificar um nome e abrir esse nome depois resolve a referência duas vezes: o mesmo texto pode designar objetos diferentes. Uma segunda verificação pelo nome apenas cria outro intervalo se o nome continuar mutável.

Assume que outro processo pode alterar a entrada de diretório relatorio. A e B são ficheiros diferentes, e só A foi autorizado:

O texto do nome ficou igual. A identidade do objeto mudou entre a verificação e a abertura.

Quando o sistema permite, abre com as restrições adequadas, verifica o objeto pelo descritor e usa esse mesmo descritor. Para uma atualização de saldo, verificar e alterar deve ser uma operação atómica ou uma transação com isolamento adequado. Um mutex numa única aplicação não coordena automaticamente outros processos ou servidores.

Atualizações e resposta

Uma atualização pode corrigir uma vulnerabilidade conhecida. Antes de a aplicar, verifica dependências e compatibilidade; depois confirma a versão e o comportamento. Fixar uma versão permite reproduzir o sistema, mas exige um processo de atualização. Um componente sem manutenção continua a precisar de isolamento, substituição ou uma decisão sobre o risco residual.