Transbordamento de dados: diferenças entre revisões

Conteúdo apagado Conteúdo adicionado
→‎Aspectos práticos da exploração: incluir ligação interna para Shellcode
m Ajustes
Linha 1:
{{Sem-fontes|data=abril de 2012| angola=| arte=| Brasil=| ciência=| geografia=| música=| Portugal=| sociedade=|1=|2=|3=|4=|5=|6=}}
Em [[Segurança da Informaçãoinformação e Comunicaçõescomunicações|segurança computacional]] e [[Programação de computadores|programação]], um '''transbordamento de dados''' ou '''estouro de''' '''''[[Buffer (ciência da computação)|buffer]]''''' (do [[Língua inglesa|inglês]] ''buffer overflow'' ou ''buffer overrun'') é uma anomalia onde um programa, ao escrever dados em um ''buffer'', ultrapassa os limites do ''buffer'' e sobrescreve a memória adjacente. Esse é um caso especial de violação de segurança de memória.
 
Estouros de ''buffer'' podem ser disparados por entradas que são projetadas para executar código, ou alterar o modo como o programa funciona. Isso pode resultar em comportamento errado do programa, incluindo erros de acesso à memória, resultados incorretos, parada total do sistema, ou uma brecha num sistema de segurança. Portanto, eles são a base de muitas vulnerabilidade de ''software'' e pode ser explorados maliciosamente.
Linha 51:
* Sobrescrever o endereço de retorno da pilha. Uma vez que a função retorna, a execução irá continuar no endereço de retorno especificado pelo atacante, geralmente um ''buffer'' preenchido por entrada do usuário.
* Sobrescrever um ponteiro de função, ou tratador de exceção, que é posteriormente executado.
 
Com um método chamado ''trampolining'', se um endereço de um dado fornecido pelo usuário é desconhecido, mas a sua localização é guardada em um registrador, então o endereço de retorno pode ser sobrescrito com um ''[[opcode]]'' que fará a execução saltar para os dados fornecidos pelo usuário. Se a localização é guardada num registrador R, então um salto de execução para a localização contendo o ''opcode'' para um salto para R, chamada para R ou uma instrução similar, causará a execução de dados fornecidos pelo usuário. A localização de ''opcodes'' adequados, ou ''bytes'' na memória, podem ser encontradas em DLLs ou no próprio executável. Entretanto, o endereçamento de ''opcodes'' tipicamente não pode conter nenhum caractere nulo e as localizações desses ''opcodes'' podem mudar entre aplicações e versões do sistema operacional. O Projeto Metasploit é um banco de dados de ''opcodes'', apesar de apenas os ''opcodes'' encontrados nos sistemas Windows estarem listados.
Não se deve confundir estouro de ''buffer'' baseado em pilha com estouro de pilha.
Linha 71 ⟶ 72:
A escolha da linguagem de programação pode ter um efeito profundo na ocorrência de estouros de buffer. Como em 2008, entre as linguagens mais populares estão C e sua derivativa C++, com uma ampla gama de ''softwares'' sendo escritos nessas linguagens. C e C++ não proveem proteção embutida contra acesso indevido ou sobrescrita de qualquer parte da memória. Mais especificadamente, elas não checam se um dado escrito em um ''buffer'' está nos limites do ''buffer''. Entretanto, as bibliotecas de C++ padrão proveem muitas maneiras de copiar dados para um ''buffer'' de forma segura, e técnicas para evitar estouros de ''buffer'' também existem em C.
 
Muitas outras linguagens de programação proveem checagem em tempo de execução e em alguns casos até checagens em tempo de compilação, que enviam um alerta um lançam uma exceção quando C ou C++ iriam sobrescrever os dados e continuar a executar instruções até que resultados errados fossem obtidos, os quais poderiam ou não fazer o programa parar. Exemplos de tais linguagens incluem [[Ada (linguagem de programação)|Ada]], [[Eiffel (linguagem de programação)|Eiffel]], [[Lisp]], [[Modula-2]], Smalltalck[[Smalltalk]], [[Objective Caml]] e derivadas de C como Cyclone e [[D (linguagem de programação)|D]]. Os ambientes de bytecodes de Java e do .Net Framework também requerem checagem de limites em todos os arrays. Quase todas as linguagens interpretadas irão proteger contra estouros de buffer, sinalizando uma condição de erro bem definida.
 
Na maioria das vezes, quando uma linguagem proveem informação de tipos suficiente para se fazer checagem de limites de ''arrays'', é dada a opção de habilitar ou desabilitar a checagem. Análise estática de código estática pode remover muitas checagens de limites e tipos dinâmicas, mas implementações pobres e casos estranhos podem diminuir significativamente o desempenho. Engenheiros de ''software'' devem considerar cuidadosamente os ganhos e perdas de segurança versus custos de desempenho ao decidirem qual linguagem e configuração de compilador utilizar.
 
=== Uso de bibliotecas seguras ===