MSDN : Trouvez les failles de sécurité dans vos applications

Comment pouvez-vous vous assurer qu’une panne de programme n’est pas exploitable ? La réponse est simple : vous devez supposer que chaque panne est exploitable et résoudre le problème ! Il s’agit là d’une question de qualité et il est souvent plus économique et plus pratique de résoudre le problème avant que le produit ne soit expédié au client. L’analyse nécessaire pour déterminer l’exploitabilité d’un programme peut être coûteuse.

L’analyse des pannes de programmes liées à la corruption de la mémoire afin de comprendre les ramifications de sécurité peut s’avérer une tâche complexe et sujette à des erreurs. Plusieurs facteurs doivent être considérés, y compris l’emplacement du tampon en mémoire, les cibles possibles pour l’écrasement, la taille de l’écrasement, les restrictions sur les données qui peuvent être utilisées pendant l’écrasement, l’état de l’environnement d’exécution du service d’exécution et la capacité à contourner n’importe quels mécanismes d’atténuation en place. En bref, vous devez comprendre la cause initiale de la panne afin de bien répondre à ces questions.

N’oubliez pas que les pannes ne se manifestent pas toutes d’une manière observable. Nous citerons, en guise d’exemple, le problème d’exécution de code à distance GDI abordé dans le bulletin de sécurité Microsoft MS07-017. Le logiciel chargé d’invoquer le code d’analyse vulnérable utilisait un gestionnaire d’exceptions pour se rétablir de pratiquement n’importe quelle exception qui pouvait être créée et continuer à fonctionner comme si de rien n’était. (Pour en savoir plus, consultez le site Web blogs.msdn.com/sdl/archive/2007/04/26/lessons-learned-from-the-animated-cursor-security-bug.aspx.) Un autre exemple, moins évident, se trouve dans certains types de corruptions de la mémoire de pile et tas, où il est possible que des défaillances aient eu lieu mais l’état actuel du programme et son environnement d’exécution ont l’air tout à fait normal.

Cet article offre de l’aide sur la manière d’analyser les incidents de programme et d’évaluer les implications possibles en termes de sécurité, notamment les cas de corruption de la mémoire pouvant permettre l’exécution de code arbitraire ou au minimum un déni de service. Nous énumérerons les exceptions matérielles et logicielles courantes que vous risquez de rencontrer lorsque vous examinez ces types de problèmes. Nous vous proposerons également des directives générales à utiliser lors d’une telle investigation. La figure 1, par exemple, affiche un chemin graphique du processus d’investigation qui vous aidera à déterminer si un incident particulier est exploitable. Il est important de se rappeler qu’il ne s’agit là que de directives et que seule une analyse complète pourra confirmer de manière définitive si l’incident est exploitable ou pas. De nouvelles techniques ou des variations de techniques d’attaque existantes sont découvertes régulièrement.

Suite de l'article: http://msdn.microsoft.com/msdnmag/issues/07/11/ExploitingCrashes/default.aspx?loc=fr

Posté le 11 novembre 2007 par Jeremy Amiot - source msdn.microsoft.com

Vous pouvez commenter cette nouvelle
en posant vos avis, questions et remarques
sur le forum actualité