SDL e falha de XML Parser do Internet Explorer

Um excelente post no blog Security Development Lifecycle, fala sobre a falha de XML Parser que afeta algumas versões do Internet Explorer da Microsoft.

A falha irá causar algumas mudanças na capacitação dos desenvolvedores, segundo o post o conteúdo dos treinamentos voltados ao SDL (Secure Development Lifecycle) não cobre com clareza a falha que ocorreu.

"Code Analysis and Review

Memory-related TOCTOU bugs are hard to find through code review; we teach TOCTOU issues, and we teach memory corruption issues, and issues with using freed memory blocks; but we do not teach memory-related TOCTOU issues. We will update our training to address this.

Our static analysis tools don't find this because the tools would need to understand the re-entrant nature of the code."

Devido a característica bastante peculiar da falha, muito provavelmente a falha foi encontrada por acaso, pois até mesmo as técnicas de fuzzing (considerada bala de prata por alguns) não conseguiriam identificar facilmente.

"Fuzz Testing

In theory, fuzz testing could find this bug, but today there is no fuzz test case for this code. Triggering the bug would require a fuzzing tool that builds data streams with multiple data binding constructs with the same identifier. Random (or dumb) fuzzing payloads of this data type would probably not trigger the bug, however."

Outro ponto é a questão da compatibilidade entre as versões. Devido a compatibilidade com versões anteriores não é usado ASLR e NX, o que poderia ter amenizado o problema.

"ASLR and NX

Even though Windows Vista and Windows Server 2008 have both ASLR and NX enabled by default, Internet Explorer 7 does not opt-in to these defenses owing to compatibility issues with many common applications. Internet Explorer 8 enables these defenses by default, but an attack could be mounted by calling a component that does not use these defenses, and then by using an attack technique known as heap-spraying get the attacker's code into the non-ASLR and non-NX memory. This is why it's so important to build components for Windows that use all the available Windows defenses. Matt Thomlinson and I wrote an article on this subject, and David LeBlanc and I wrote Writing Secure Code for Windows Vista that covers the subject in much more detail."