Fig. 1. Contusion, mais pas cassé. La calculatrice Windows, dont le code a été récemment publié sur Github , s'est avérée être l'une des deux applications testées qui ne se bloquaient pas et ne tombaient pas en opposition avec le flou des messages de fenêtre développé en 2000. Taille de fenêtre spécialement agrandie pour afficher les artefacts de fuzzing

Il est temps pour la deuxième partie de nos efforts de tester les anciennes techniques de fuzzing sur les systèmes modernes. Si vous avez raté, voici la première partie . Cette fois, nous allons essayer les techniques de fuzzing de Windows 10 de l'article «Investigation empirique de la fiabilité des applications Windows NT à l'aide de tests aléatoires» (alias «NT Fuzzing Report») par Justin Forrester et Barton Miller, publié en 2000.

Les chercheurs ont testé 33 applications de Windows NT et une version antérieure de Windows 2000 pour la sensibilité aux messages de fenêtre déformés et aux événements aléatoires de la souris et du clavier. Depuis que le Dr Miller a publié le code flou, nous avons utilisé exactement les mêmes outils que les auteurs originaux pour rechercher des bogues dans les applications Windows modernes.

Les résultats sont presque identiques: il y a 19 ans, 100% des applications testées se sont écrasées ou se sont écrasées lorsqu'elles ont rencontré des messages de fenêtre déformés. Aujourd'hui, le même fuzzer a abandonné ou suspendu 93% des applications testées. Seuls deux se tenaient, dont notre vieil ami Calculatrice (Fig. 1). Nous avons également trouvé un bogue (mais pas un problème de sécurité) sur Windows.

Une brève introduction à Windows

Alors, quels sont les messages de fenêtre et pourquoi provoquent-ils le plantage d'un programme?

Les applications Windows GUI sont pilotées par les événements: mouvements de la souris, pressions sur les boutons, frappes de touches, etc. Une application pilotée par les événements ne fera rien tant qu'elle ne recevra pas un événement. Une fois qu'un événement est reçu, l'application exécute l'action en fonction de l'événement, puis attend d'autres événements. Cela vous semble familier? Cette architecture a reçu une seconde vie sur des plateformes telles que node.js.

Les messages de fenêtre sont une méthode de notification d'événements Windows . Chacun d'eux a un code numérique associé à un événement spécifique . Chaque message a un ou plusieurs paramètres, qui par convention sont appelés lParam et wParam . Ils définissent des informations plus détaillées sur l'événement. Des exemples de telles informations sont les coordonnées du mouvement de la souris, la touche enfoncée ou le texte à afficher dans la fenêtre. Ces messages peuvent être envoyés par le programme lui-même, le système d'exploitation ou d'autres programmes. Ils peuvent arriver à tout moment et dans n'importe quel ordre et doivent être traités par la demande côté réception.

Conséquences pour la sécurité

Avant Windows Vista, un processus à faible privilège pouvait envoyer un message à un processus à privilège élevé. En utilisant la bonne combinaison de messages, vous pouvez exécuter du code dans ce processus. Sous Vista, ces «attaques subversives» étaient largement protégées par UIPI et en isolant les services système dans une session distincte.

Un traitement incorrect des messages de fenêtre est peu susceptible d'affecter la sécurité des systèmes Windows modernes pour deux raisons. Tout d'abord, les messages de fenêtre ne peuvent pas être envoyés sur le réseau. Deuxièmement, planter une application ou exécuter du code au même niveau de privilège n'est pas très utile pour un attaquant. C'était probablement évident pour les auteurs du rapport de fuzzing NT. Ils ne font pas de déclarations de sécurité, mais soulignent correctement que les échecs dans le traitement des messages de fenêtre impliquent un manque de tests rigoureux.

Dans certains domaines, l'exécution de code avec les mêmes privilèges peut compromettre la sécurité. Certaines applications combinent diverses primitives de sécurité pour créer un niveau de privilège artificiel qui ne se trouvait pas à l'origine dans le système d'exploitation. Un exemple typique est un sandbox pour le rendu dans un navigateur. Les fabricants de navigateurs sont bien conscients de ces problèmes et ont pris des mesures pour les résoudre . Un autre exemple est celui des produits antivirus. Là, le panneau de contrôle fonctionne avec des privilèges normaux, mais est isolé des autres modules antivirus.

Méthodologie de test

Pour fuzz toutes les applications de la suite de tests, nous avons utilisé le même code de base et la même technique de fuzzing décrits dans le rapport NT initial. En particulier, dans les modes SendMessage et PostMessage , fazzer a utilisé trois itérations de 500 000 messages avec 42 graines et trois itérations de 500 000 messages avec 1 337 graines. Les résultats sont apparus après avoir effectué une seule itération de chaque méthode.

Nous avons manqué des entrées aléatoires de souris et de clavier en raison de contraintes de temps et d'un désir de nous concentrer uniquement sur les messages de fenêtre. Nous encourageons également ceux qui souhaitent répéter les tests et confirmer les résultats.

Pièges

Pour fuzzer dans Windows 10 a dû apporter deux modifications mineures. Tout d'abord, adaptez-le pour une plate-forme 64 bits. La deuxième modification a permis à Fuzzer de sélectionner un descripteur de fenêtre spécifique à l'aide de l'argument de ligne de commande. Le fuzzing d'un descripteur spécifique est une solution rapide au fuzzing des applications de la plateforme Windows universelle (UWP) . Le programme d'origine se concentre sur le flou des fenêtres appartenant à un certain processus, mais toutes les applications UWP affichent leur interface utilisateur via le même processus (Fig. 2). Cela signifie que le fuzzer ne peut pas être dirigé vers la fenêtre principale de l'application UWP.


Fig. 2. Sur la plate-forme UWP, toutes les applications appartiennent à un seul processus ( ApplicationFrameHost.exe ). Pour fuzz ces applications, j'ai dû changer le fuzzer NT d'origine et le diriger vers des poignées de fenêtre spécifiques

Il y avait une faille sérieuse dans la modification floue: les valeurs choisies pour les deux principales sources d'entrée aléatoire, les arguments lParam et wParam pour SendMessage et PostMessage , sont limitées à des entiers 16 bits. Les deux arguments sont 32 bits sur Windows 32 bits et 64 bits sur Windows 64 bits. Le problème se produit dans Fuzz.cpp , où lParam et wParam :

  wParam = (UINT) rand(); lParam = (LONG) rand(); 

La fonction rand () renvoie un nombre dans la plage [0, 2 ¹⁶ ], ce qui limite considérablement l'ensemble des valeurs testées. Nous avons intentionnellement enregistré cette erreur lors des tests afin que les résultats soient exactement adaptés au travail d'origine.

Applications testées

Dans le rapport NT d'origine, 33 programmes ont été testés. Nous n'en avons que 28, car une seule version de chaque programme est utilisée pour les tests. L'écosystème logiciel Windows a considérablement changé depuis 2000, mais étonnamment, beaucoup reste inchangé. La suite Microsoft Office contient les mêmes programmes que dans les tests d'origine. Netscape Communicator est devenu Firefox. Adobe Acrobat a été renommé Adobe Reader, mais il est toujours valide. Même Winamp a publié une nouvelle version en 2018, ce qui permet une comparaison équitable avec le rapport d'origine. Cependant, certains programmes obsolètes ont dû être remplacés. Voir ci-dessous pour une liste des changements et les raisons de ces changements:

• Lecteur CD ⇨ Lecteur Windows Media: la fonctionnalité du lecteur CD est incluse dans le nouveau programme.
  
• Eudora ⇨ Windows Mail: Qualcomm s'occupe désormais des puces plutôt que des clients de messagerie. Depuis Eudora n'existe plus, le client de messagerie Windows par défaut a été testé à la place.
  
• Command AntiVirus ⇨ Avast Free Edition: Command AntiVirus n'est plus disponible. Il a été remplacé par Avast comme antivirus tiers le plus populaire.
  
• GSView ⇨ Photos: GSView n'est plus pris en charge. Il a été remplacé par la visionneuse de photos Windows par défaut.
  
• IDE JavaWorkshop Net NetBeans: l'IDE JavaWorkshop n'est plus pris en charge. NetBeans semble être une bonne alternative gratuite qui correspond à l'esprit de ce qui doit être vérifié.
  
• Secure CRT ⇨ BitVise SSH: Secure CRT existe toujours, mais un formulaire Web très long est requis pour télécharger la version d'essai. BitVise SSH a proposé un démarrage rapide.
  
• Telnet ⇨ Putty: L' application telnet existe toujours sous Windows, mais maintenant c'est une application console. Pour flouer l'interface graphique, nous l'avons remplacée par Putty, l'émulateur de terminal open source populaire pour Windows.
  
• Nous avons trouvé Freecell et Solitaire dans la collection Microsoft Solitaire du catalogue d'applications Windows App Store.

La version spécifique de l'application est affichée dans le tableau des résultats. Tout le fuzzing a été effectué sur Windows 10 Pro 649 version 1809 (build 17763.253).

Résultats

Comme mentionné dans le rapport d'origine, les résultats ne doivent pas être considérés comme des failles de sécurité, mais comme un indicateur de la fiabilité et de la qualité des logiciels.

«Enfin, nos résultats constituent un point de départ quantitatif à partir duquel juger de l’amélioration relative de la fiabilité des logiciels.»

- De «l'étude empirique de la fiabilité des applications Windows NT à l'aide de tests aléatoires» par Justin Forrester et Barton Miller

Les chiffres ne sont pas particulièrement encourageants, bien que la situation s'améliore. Dans le rapport NT initial, toutes les applications se sont écrasées ou ont suspendu le fuzzing. Maintenant, deux programmes: la calculatrice et Avast Antivirus, ont survécu au phasage des messages de fenêtre sans aucune conséquence négative. Nous félicitons les équipes d'Avast et de Windows Calculator pour leur approche des messages de fenêtre erronés. L'équipe de calculatrice a gagné un respect supplémentaire pour l'ouverture du code source et la démonstration de la création d'une application UWP de haute qualité. Voir le tableau 1 pour tous les résultats de fuzzing, ainsi que la version spécifique du logiciel utilisé.

Tableau 1. Résultats de la lecture du fuzzing d'origine sur Windows 10. Après 19 ans, presque toutes les applications ne gèrent toujours pas correctement les messages de fenêtre déformés

Bogue Windows?

Malheureusement, la curiosité a prévalu et nous avons dû faire une exception. Il semblait que plusieurs applications non liées étaient frappées par un problème commun. Le débogage a montré que le problème était lié au message WM_DEVICECHANGE . Lorsque le fuzzer a envoyé ce message, même l'application la plus simple s'est écrasée - HelloWorld, l'exemple officiel de l'API Windows (Fig. 3).


Fig. 3. HelloWorld.exe 32 bits se bloque lors de la réception d'un message de fenêtre de fuzzer. Cela ne devrait pas se produire, car le programme est complètement simple. Il est entendu que le problème se situe quelque part dans Windows

Après la chute de HelloWorld, nous avons immédiatement réalisé que le problème affectait uniquement les applications 32 bits, mais pas celles 64 bits. Un débogage rapide a montré qu'un crash se produit dans wow64win.dll, une couche de compatibilité des applications 32 bits pour 64 bits . Mon analyse superficielle (et peut-être incorrecte) du problème conduit à la conclusion que la fonction wow64win.dll!whcbfnINDEVICECHANGE considère wParam comme un pointeur vers la structure DEV_BROADCAST_HANDLE64 dans le programme cible. La fonction convertit cette structure en structure DEV_BROADCAST_HANDLE32 pour la compatibilité avec les applications 32 bits. L'échec se produit car la valeur wParam générée par le fuzzer indique une mémoire non valide.

Traiter wParam comme un pointeur local est une mauvaise idée, bien qu'il s'agisse probablement d'une décision de conception délibérée pour que les notifications de périphériques amovibles fonctionnent avec les applications Windows 32 bits héritées. Mais il est toujours faux que vous puissiez planter une autre application sans aucun problème. Nous avons signalé le problème au MSRC, bien que la frontière de sécurité n'ait pas été franchie. Ils ont confirmé que l'erreur n'était pas un problème de sécurité. Nous espérons voir une solution à cet étrange problème généralement accepté dans une future version de Windows.

Conclusion

Les messages de fenêtre sont sous-estimés et souvent ignorés en tant qu'entrée peu fiable dans les programmes Windows. Même 19 ans après l'apparition du premier flou de messages de fenêtres open-source, 93% des applications testées se bloquent ou se bloquent toujours au démarrage du même programme. Mais il est encourageant que certaines applications gèrent gracieusement cette entrée déformée: cela signifie que certaines organisations disposent de cadres et de connaissances institutionnelles pour éviter de telles erreurs.

Bien sûr, le fuzzer peut être amélioré de plusieurs façons, mais même la méthode la plus simple a bloqué 93% des applications. Peut-être que dans certains cas, les messages de fenêtre traversent même la vraie frontière de sécurité. Si vous explorez ce domaine, nous espérons que vous partagerez les résultats.