Histoire vraie de mes débuts chez Microsoft.
Vous n'avez pas connu la peur jusqu'au jour où vous vous réveillez et voyez le titre sur ZDNet.com ce matin-là " pire trou de sécurité d'Internet Explorer a jamais été découvert dans" Blah " " où "Blah" est le code que vous vous avez écrit six mois auparavant .
Immédiatement après mon arrivée au travail, j'ai vérifié les journaux des modifications et découvert que quelqu'un dans une autre équipe - quelqu'un en qui nous avions confiance pour apporter des modifications au produit - avait extrait mon code, changé un tas de paramètres de clé de registre de sécurité sans raison valable, Je l'ai réintégré, et je n'ai jamais eu d'examen du code ni en parler à personne. À ce jour, je n'ai aucune idée de ce qu'il pensait qu'il faisait; il a quitté l'entreprise peu après. (De son propre gré.)
(MISE À JOUR: Quelques réponses aux questions soulevées dans les commentaires:
Tout d'abord, notez que je choisis de prendre la position caritative que les changements de clé de sécurité étaient involontaires et basés sur la négligence ou la méconnaissance, plutôt que sur la malveillance. Je n'ai aucune preuve dans un sens ou dans l'autre, et je pense qu'il est sage d'attribuer des erreurs à la faillibilité humaine.
Deuxièmement, nos systèmes d'enregistrement sont beaucoup, beaucoup plus solides maintenant qu'ils ne l'étaient il y a douze ans. Par exemple, il n'est désormais plus possible d'enregistrer le code sans que le système d'enregistrement envoie la liste des modifications par e-mail aux parties intéressées. En particulier, les changements apportés à la fin du cycle d'expédition ont beaucoup de «processus» autour d'eux, ce qui garantit que les bons changements sont apportés pour assurer la stabilité et la sécurité du produit.)
Quoi qu'il en soit, le bogue était qu'un objet qui n'était PAS sûr d'être utilisé à partir d'Internet Explorer avait été accidentellement publié comme étant marqué comme "sûr pour les scripts". L'objet était capable d'écrire des fichiers binaires - des bibliothèques de type OLE Automation, en fait - dans des emplacements de disque arbitraires. Cela signifiait qu'un attaquant pouvait créer une bibliothèque de types qui contenait certaines chaînes de code hostile, l'enregistrer dans un chemin qui était un emplacement exécutable connu, lui donner l'extension de quelque chose qui provoquerait l'exécution d'un script et espérer que l'utilisateur exécuterait accidentellement le code. Je ne connais aucune attaque réussie "du monde réel" qui a utilisé cette vulnérabilité, mais il a été possible de créer un exploit fonctionnel avec elle.
Nous avons expédié un patch assez rapidement pour celui-là, laissez-moi vous dire.
J'ai causé et corrigé par la suite de nombreuses autres failles de sécurité dans JScript, mais aucune d'entre elles n'a jamais été aussi proche de la publicité que celle-ci.