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
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]],
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
=== Uso de bibliotecas seguras ===
|