gcc -fstack-protector-all, Mudflap, DUMA e o Valgrind!

11 11 2007

“Quem programou em C ou C++ já esbarrou nesta categoria de erro: buffer overflows que podem vir acompanhados” (ou não de) outros problemas como ponteiros não inicializados, memory leaks, etc e como afirma o David LeBlanc “toda vulnerabilidade pode ser explorada até que se prove o contrário”, portanto codificar de forma segura e debugar é preciso! Entre algumas dicas já oferecidas aqui anteriormente, segue um artigo bem interessante do Savago onde ele trata de um específico tipo de buffer overflow e ele aborda o Mudflap e cita o Valgrind, que é uma ferramenta recomendada pelo Michael Behm como ferramenta para detectar problemas de memória.

[1] Detectando buffer over/underflow em C e C++ com ferramentas OpenSource

[2] Mudflap

[3] Valgrind

[4] Using valgrind to detect and prevent application memory problems

Anúncios




Os formatadores de strings da Granja do Solar

7 11 2007

Recentemente fiz uma revisão de código onde encontrei sprintf, gets, strcat e strcpy para todos os cantos, além de outros pecados mortais. Não houve como não lembrar dos capítulos “os formatadores de strings da Granja Solar” do livro Exceptional C++ Style (que traduzido para o pt-br virou Programação Avançada em C++) do Herb Sutter, onde de uma forma divertida ele cita George Orwell:

 

“Todos os animais são iguais, mas alguns são mais iguais do que outros”

Descontando os detalhes não tão óbvios, sobre strings, com várias fontes bibliográficas (inclusive em português) não acreditei na quantidade de código inseguro que encontrei num software comercial, mas é como diz o Jeff Atwood do Coding Horror [1] para encontrar código inseguro, basta procurar!

Continue lendo »





8 Regras simples para o desenvolvimento de código mais seguro

28 10 2007

Novembro é mes de Segurança na revista MSDN Magazine e após ler alguns artigos, realmente nenhum me chamou tanto a atenção quanto um artigo do ano passado do “Michael Howard” que aborda:

* Uso de ferramentas de análise e especialistas para rever seu código
* Redução do risco utilizando difusão e modelagem de ameaça
* Manutenção da entrada errada fora dos aplicativos
* Aprendizado de tudo sobre conceitos de segurança

Sinceramente, vale a pena “estudar” o artigo, pois apesar dos conceitos não serem novos a abordagem do Michael Howard está muito boa.

E aproveitando, já que o Howard é um dos pais do SDL [2] recomendo a leitura dos blog do SDL Team e principalmente o post que trata um relatório do governo americano chamado State of the Art of Software Security Assurance que dá muito destaque ao SDL.

De qualquer forma na revista deste último ano, também há um artigo dele bem interessante que é o [5] “Lessons Learned from Five Years of Building More Secure Software” ou lições aprendidas em 5 anos de criação de softwares mais seguros, no geral a revista está  interessante mas me agradou menos do que a de 2006.

[1] MSDN Magazine – 8 Regras simples para o desenvolvimento de código mais seguro

[2] Trustworthy Computing Security Development Lifecycle

[3] SDL Team

[4] “State of the Art of Software Security Assurance” Report

[5]  Lessons Learned from Five Years of Building More Secure Software