Segundo Fred Cohen, no artigo “20 Tips on Software Security”, projetar e executar sistemas de software seguros podem ser complexos, contudo, o autor descreve 20 dicas para auxiliar os desenvolvedores de softwares a construir sistemas mais seguros. Esta 20 dicas são divididas em 05 partes.

Segue abaixo um paralelo entre o artigo de Cohen e O CLASP (Comprehensive, Lightweight Application Security Process) que é um documento que descreve as melhores práticas de devenvolvimento de softwares seguros. O CLASP mantém uma lista de 104 tipos de vulnerabilidades submetidos dentro de 05 categorias.

Parte 3 – Use medidas razoáveis e prudentes:

10 - Do an independent protection audit before release

Se o produto possui características de segurança, deve-se testar todas as funcionalidades para evitar desgastes futuros. Tenha alguém no projeto que conheça de testes voltados para segurança.

11 - Use good change control in your software update process

O emprego de um controle de mudanças no processo de atualização de um software evita embaraços com clientes. Descrito pelo CLASP como erros de lógica, falta de parâmetros em procedimentos.

12 - Provide a secure manufacturing and distribution mechanism

Prover um mecanismo de produção e distribuição seguros. É importante adotar estratégias de segurança para que o sistema não chegue ao mercado com algum tipo de vírus embutido. Classificado pelo CLASP como erros ambientais.

13 - Track who does what and attribute faults to root causes

Erros são cometidos por todos, e a maioria dos erros são similares num ambiente. Deve-se encontrar a origem dos problemas e adotar maneiras de eliminá-los. Identifique quem faz o que no projeto. Categorizado pelo CLASP como erros gerais de lógica, falta de parâmetros .

Parte 4 – Forneça um processo de beta-teste que ajude a encontrar  falhas:

14 - Internal beta-testing should seek out flaws relentlessly

Um beta teste interno deve procurar falhas no sistema. Mantenha uma equipe interna que saída sobre teste de segurança. O custo de reparar erros relacionados à segurança é maior após o software ser liberado para uso. Classificado pelo CLASP como erros gerais de lógica.

15 - Get some monkeys on your keyboards

Erros no software podem ser descobertos com entrada de dados incorretos, o que pode resultar numa falha a ser explorada pelo atacante. Classificado pelo CLASP como erros gerais de lógica.

16 - Build a repeatable testing capability

Contruir uma capacidade de repetição nos testes. A repetibilidade e a automação do processo de teste do software são a chaves principal para o sucesso e a eficiência.

17 - Get an outside community with an interest in finding and fixing holes

Se você não pode testar o software sozinho, procure uma comunidade externa que o auxilie.

Parte 5 – Apenas porque você não seja perfeito não significa que você não tentou.

18 - Don't throw up your hands - work the issues

Mesmo que você não consiga resolver um problema da melhor maneira, você deve fazer o bastante de forma suficiente para garantir uma base de segurança.

19 - Use constant quality improvement to enhance your security

Faça uso de uma constante melhoria de qualidade no produto para realçar a segurança.

20 - People that complain about 'defensive programming' don't belong

Pessoas que se queixam sobre programação defensiva não fazem parte do ambiente de programação profissional. Muitas vezes programas dependem de outros programas e programadores também dependem de outros programadores.

Este artigo descreve três famílias de exploits para buffer overrun, também conhecidos como Buffer Overflow : arc injection, pointer subterfuge, e heap smashing. Sistemas desenvolvidos com baixa segurança são a causa principal das vulnerabilidades por parte destes novos tipos de ataques.

O método tradicional de exploração de buffer overrunns é através de stack smashing, que ocorre através da modificação do endereço de retorno salvo no stack (região da memória empregada para armazenamento de parâmetros, variáveis locais e endereços de retorno), que aponta para o código do atacante que reside num buffer stack do sistema atacado.

Na década passada, porém, hackers criaram várias formas de explorar buffer overruns. A técnica Heap smaching permite exploração de buffer overruns na área da memória alocada dinamicamente, o oposto à pilha. O exploit Apacha/Open_SSL Slapper worm utiliza a técnica heap smashing para explorar uma vulnerabilidade no Servidor OpenSSL.

Explorando Buffer Overruns

Um buffer overrun ocorre quando uma aplicação tenta ler ou escrever além do array determinado na área de buffer da memória. O Buffer overrun ocasiona exceções em linguagens como Pascal, Ada, Java, porém linguagens como C e C++ não realizam nenhum tipo de checagem.

Stack Smashing

É uma técnica que foi descrita em detalhes na década de 90 pelos hackers AlephOne e DillDog, na qual consiste de duas etapas : trocar o controle de fluxo de dados para executar o código criado pelo atacante. A técnica confia no fato de que a maioria dos compiladores C armazenam o endereço de retorno salvo na mesma pilha usada para as variáveis locais.

Arc Injection

Esta técnica ocorre quando o atacante fornece dados a uma aplicação, tendo como retorno o efeito desejado, ou seja, também tem o objetivo de modificar o endereço de retorno. Geralmente faz com que aponte para algum local que contenha alguma função específica.

Pointer Subterfuge

Pointer Subterfuge é uma técnica de exploração que utiliza da alteração de valores de ponteiros. Pode-se citar pelo menos quatro variantes de Pointer Subterfuge : funtion-pointer clobbering, data-pointer modification, exception-handler hijcking e virtual pointer smashing.

Heap Smashing

Até recentemente, especialistas acreditavam que somente pilhas de buffers eram vulneráveis a ataques do tipo exploits. Porém, vários exploits do tipo Pointer Subterfuge desafiaram esta suposição, sendo que foi desenvolvido um ataque específico para memória Heap que deste então ficou conhecido como Heap Smashing.

Heap Smashing explora implementações em memória dinâmicas alocadas por violação em algumas invariantes assumidas.

Conclusão

É importante que desenvolvedores de sistemas tenham conhecimento das vulnerabilidades de linguagens como C, C++, de forma a estudar os ataques que possam ocorrem nestes ambientes. Os esforços devem ser empregados para abrandar as vulnerabilidades encontradas nestes ambientes, como observar o processo inteiro da programação do software para evitar erros de programação.