20 ans passés avec AWS : je n’ai jamais dit une seule fois « ce n’est pas mon travail »

• Colin Percival, responsable sécurité de FreeBSD et fondateur de Tarsnap, revient chronologiquement sur les 20 années durant lesquelles il a largement contribué à l’évolution d’AWS depuis la création de son premier compte en 2006 jusqu’à aujourd’hui, en tant que contributeur externe et non employé officiel : mise en place du support de FreeBSD sur EC2, découverte et signalement proactifs de vulnérabilités de sécurité, jusqu’aux retours sur la conception des services
• À ses débuts, AWS nécessitait une activation séparée pour chaque service ; les premiers services activés par défaut étaient Amazon SQS et le très méconnu Amazon E-Commerce Service
• Pour faire fonctionner FreeBSD sur EC2, il a fallu résoudre pendant plusieurs années des obstacles techniques liés à la compatibilité des versions de Xen, au support du PAE et au passage à HVM ; le premier démarrage réussi a eu lieu en 2010 sur t1.micro
• Il a découvert et signalé à l’avance de nombreux problèmes de sécurité, notamment une vulnérabilité de collision de normalisation dans le mécanisme de signature des requêtes AWS, le risque d’exposition d’identifiants via IMDS (devenu réalité lors de la compromission de Capital One en 2019), ainsi que des problèmes de sécurité liés à Seekable OCI
• Depuis 2024, il continue la maintenance de FreeBSD/EC2 grâce au soutien d’Amazon via GitHub Sponsors ; un exemple de résultats obtenus comme contributeur externe, sans accès aux systèmes internes, grâce à la coopération d’ingénieurs d’Amazon

---

Création du compte AWS et premiers services

• Le 10 avril 2006, après l’annonce d’Amazon S3, il crée son premier compte AWS, motivé par son intérêt pour les services de stockage en ligne ; il disposait déjà d’une expérience dans la création de services web basés sur HTTP depuis 1998
• À cette époque, chaque service AWS devait être activé séparément sur le compte ; les seuls services fournis par défaut étaient Amazon SQS et Amazon E-Commerce Service (API de catalogue produits pour les partenaires Amazon)
  • Amazon E-Commerce Service était en pratique le tout premier service AWS, mais il est resté largement méconnu et a discrètement disparu de l’histoire officielle d’AWS

Premier intérêt pour la sécurité et retours initiaux

• Fort de son expérience comme FreeBSD Security Officer, il s’est immédiatement intéressé à l’architecture de sécurité d’AWS et a souligné que, si les requêtes AWS étaient signées avec une clé API pour garantir l’authentification et l’intégrité, les réponses, elles, n’étaient pas signées
• Comme les requêtes AWS passaient couramment par HTTP à l’époque, la possibilité de falsification des réponses représentait un risque réel ; même après la transition vers TLS, il a continué de considérer qu’une signature de bout en bout restait supérieure à la sécurité de la couche de transport

FreeBSD sur EC2 — les premiers défis

• Peu après le lancement d’Amazon EC2, il vise l’exécution de FreeBSD et est mis en relation, via Jeff Barr, avec les interlocuteurs internes chez Amazon ; début 2007, il signe son premier NDA Amazon
  • Amazon utilisait alors encore le fax, mais comme il n’en avait pas, il a dû envoyer l’original signé par courrier, ce qui a retardé le premier briefing
• À l’origine, EC2 a été lancé sans support des noyaux personnalisés (d’une manière comparable à AWS Lambda aujourd’hui) ; cette possibilité a été activée en novembre 2007 en même temps que le support de Red Hat, ce qui a aussi permis à son compte FreeBSD d’accéder à l’API interne de « publication d’Amazon Kernel Images »

Audit de sécurité de Xen et alerte sur les attaques par canal auxiliaire

• En mars 2007, il signale à son contact chez Amazon la nécessité d’un audit de sécurité de Xen et, ne sachant pas quel auditeur recommander, suggère Tavis Ormandy
  • La même année, Tavis a signalé deux vulnérabilités Xen (CVE-2007-1320, CVE-2007-1321), sans que le lien avec cette recommandation soit clairement établi
• Lors d’une rencontre d’utilisateurs AWS organisée par Jeff Barr dans Second Life, il demande un disque racine en lecture seule et la garantie d’un effacement mémoire au redémarrage, pour des scénarios d’exécution de code non fiable comme la compilation de paquets FreeBSD ; EC2 Instance Attestation n’arrivera que 18 ans plus tard
• À re:Invent 2012, il explique à un Principal Engineer d’EC2 des travaux de recherche sur le vol de clés RSA via HyperThreading et recommande fermement de ne pas exécuter en parallèle des instances EC2 sur les deux threads d’un même cœur
  • Cette recommandation expliquerait pourquoi de nombreuses familles d’instances EC2 ont sauté la taille « medium » pour commencer directement à 2 vCPU (« large »)

Eventual Consistency et proposition théorique

• Fin 2007, dans un billet de blog largement lu en interne chez Amazon, il pointe les limites de l’Eventual Consistency et défend un modèle légèrement plus fort, baptisé Eventually Known Consistency
  • Un modèle permettant de conserver la voie « A » (availability) du théorème CAP tout en exposant l’état interne afin d’obtenir aussi « C » (consistency) dans le chemin nominal
  • Amazon S3 est ensuite passé d’une optimisation pour la disponibilité à une optimisation pour la cohérence, tandis que DynamoDB a offert le choix entre lectures Eventual et Strongly Consistent

Problèmes de compatibilité Xen et échec du démarrage de FreeBSD

• Début 2008, Kip Macy écrit un noyau FreeBSD avec support Xen PAE, tandis que le portage des outils AMI internes vers FreeBSD prend plusieurs semaines
  • Il mentionne au passage la nécessité de repenser le choix des langages quand des scripts Ruby génèrent puis exécutent des scripts bash
• L’AMI FreeBSD ne démarrait pas sur EC2, à cause d’un bug de Xen 3.0 utilisé par EC2, qui ne prenait pas en charge les tables de pages récursives du code VM de FreeBSD
  • Le problème a été corrigé dans Xen 3.1, mais faute d’ABI stable, Amazon a choisi de rester sur Xen 3.0 afin de préserver la compatibilité avec les AMI existantes

Découverte et correction d’une vulnérabilité de signature AWS

• En avril 2008, en utilisant Amazon SimpleDB pour la bêta de Tarsnap, il découvre une collision de normalisation dans le mécanisme de signature
  • Comme Amazon ne disposait alors d’aucun canal de signalement des problèmes de sécurité, il transmet l’information via Jeff Barr
• Amazon lui demande d’examiner la conception de Signature Version 2 ; après des corrections d’ambiguïtés documentaires, de décisions de conception et l’ajout d’une liste blanche de comptes, la faille est corrigée en décembre

Problème d’hygiène de sécurité du NextToken de SimpleDB

• En juin 2008, il découvre que la valeur NextToken de SimpleDB n’est qu’un objet Java sérialisé encodé en base64
  • Il signale qu’un chiffrement est nécessaire pour éviter les fuites d’informations internes et qu’une signature est requise pour empêcher les altérations, mais ne reçoit aucune réponse
  • Six mois plus tard, il refait le signalement via un autre ingénieur, ce qui donne lieu à un ticket interne, sans réponse officielle par la suite

Tests alpha d’EBS et moment opportun pour les retours de conception

• En mars 2008, Matt Garman de l’équipe EC2 l’invite à l’alpha privée d’Elastic Block Storage (aujourd’hui Elastic Block Store)
  • Selon lui, le moment le plus utile pour formuler des retours sur un nouveau service est avant sa construction, au stade de la conception ; avec son bagage en mathématiques et en théorie, il estime qu’examiner des documents de conception est plus efficace que tester une alpha

Épisode d’entretien d’embauche chez Amazon

• En 2008, sur l’insistance de Jeff Barr, il envisage de rejoindre Amazon ; lors d’un entretien téléphonique avec Al Vermeulen, 30 des 45 minutes sont consacrées à débattre des avantages et inconvénients des exceptions
  • Il maintient que les exceptions constituent une méthode de gestion des erreurs fondamentalement inadaptée, car elles favorisent des bugs difficiles à repérer dans des revues de code ordinaires

IAM et clés d’accès restreintes — jusqu’à SigV4

• En novembre 2008, lors du Seattle AWS Start-up Tour, il discute directement avec des ingénieurs Amazon de la nécessité de clés d’accès AWS limitées
  • Il défend une approche de clés dérivées cryptographiquement, où les clés propres à chaque service sont dérivées par hachage à partir d’un secret maître, tandis qu’Amazon préfère alors une conception fondée sur des règles
• En janvier 2010, il est invité à la bêta privée d’IAM ; lors du lancement de SigV4 en 2012, l’approche par clés dérivées est retenue

Problème de pare-feu EC2 et Path MTU Discovery

• En 2009, il découvre et signale que les règles de pare-feu par défaut d’EC2 bloquent les messages ICMP Destination Unreachable (Fragmentation Required), empêchant le bon fonctionnement de Path MTU Discovery
  • En décembre 2009, un responsable EC2 approuve une solution, mais la correction effective n’intervient qu’après qu’il a soulevé publiquement le problème en 2012

Détour par NetBSD et passage à HVM

• Début 2010, EC2 restant sur une ancienne version de Xen, il tente un détour par NetBSD et parvient en une semaine à démarrer, monter le système de fichiers, configurer le réseau et lancer sshd
• En juillet 2010, les instances Cluster Compute prennent en charge HVM, redonnant espoir pour FreeBSD, tandis qu’il devient évident que PV (paravirtualisation) est une impasse technique

Premier démarrage de FreeBSD/EC2 — t1.micro

• La famille d’instances t1.micro, lancée en septembre 2010, exécute en interne Xen 3.4.2, ce qui élimine le bug empêchant le démarrage de FreeBSD
• À la mi-novembre 2010, il réussit à se connecter en SSH à une instance FreeBSD/EC2 t1.micro ; le support officiel de FreeBSD EC2 sur t1.micro est annoncé le 13 décembre

Extension aux types d’instances et astuce de « defenestration »

• Un Solutions Architect d’Amazon le met en relation avec des utilisateurs FreeBSD souhaitant des instances plus puissantes, ce qui permet d’implémenter le support des instances Cluster Compute
• En exploitant le fait qu’EC2 ne savait pas réellement quel OS tournait, il rend possible l’usage de FreeBSD sur tous les types d’instances 64 bits via defenestration (déguisement en instance Windows)
  • Il fallait payer la « taxe Windows », ce qui déplaisait aussi à Amazon, mais c’était indispensable pour répondre à la demande client ; cette astuce devient inutile en juillet 2014, lorsque les instances T2 complètent le support HVM « Linux »

Diagnostic d’une panne matérielle de routeur S3

• En avril 2012, de nombreuses requêtes vers certains endpoints S3 échouent, notamment avec l’erreur SignatureDoesNotMatch
• En observant que la valeur StringToSign des réponses d’erreur ne correspondait pas à celle envoyée, il identifie un bit bloqué ; à l’aide de traceroute et de millions de ping, il remonte jusqu’à une panne matérielle sur un routeur du chemin réseau
  • Après signalement sur les AWS Developer Forums, Amazon confirme le problème en quelques jours et remplace le matériel

re:Invent 2012 et alerte sur les attaques par canal auxiliaire

• Le premier re:Invent manquait de contenu technique et comptait beaucoup de costumes, mais offrait l’occasion d’échanger en face à face avec de nombreux ingénieurs Amazon
• Après qu’un vice-président d’Intel intervenant sur le thème de la sécurité des machines virtuelles a répondu ne rien savoir des attaques par canal auxiliaire, il explique directement les recherches en question à un Principal Engineer sur le stand EC2

Officialisation de FreeBSD/EC2 et release engineering

• En avril 2015, le processus de build des AMI FreeBSD/EC2 est intégré à l’arbre src de FreeBSD, et la construction des images est transférée à l’équipe de release engineering de FreeBSD, transformant un projet personnel en projet officiel FreeBSD
• En septembre 2020, à la demande de Glen Barber, responsable du release engineering de FreeBSD, il accepte le rôle de Deputy Release Engineer
  • Fin 2022, Glen est hospitalisé pour une pneumonie et, en raison de séquelles de longue durée qui compliquent son retour, il reprend lui-même le rôle de FreeBSD Release Engineering Lead le 17 novembre 2023
  • Il met en place des builds hebdomadaires de snapshots, renforce le calendrier, établit un cycle de publication plus rapide et prévisible, et gère quatre releases par an

Alerte de sécurité sur IMDS et compromission de Capital One

• En octobre 2016, il analyse IAM Roles for Amazon EC2 et publie un billet expliquant que l’exposition d’identifiants via IMDS, fonctionnant sur HTTP non authentifié tout en avertissant dans la documentation de ne pas y stocker de données sensibles, constitue un risque
• En juillet 2019, Capital One subit exactement cette attaque, avec 106 millions de clients touchés ; après un échange avec Amazon en novembre de la même année, IMDSv2 est lancé deux semaines plus tard
  • Il estime toutefois qu’IMDSv2 n’est qu’une atténuation d’un vecteur d’attaque spécifique, et non une solution au problème fondamental d’identifiants exposés via une interface inadaptée

Programme AWS Heroes

• En mai 2019, il est invité au programme AWS Heroes, qui distingue des personnes non employées par Amazon ayant apporté des contributions importantes à AWS
  • Sa sélection est inhabituelle dans un programme surtout centré sur les contributeurs à l’évangélisation développeur (blogs, YouTube, ateliers) ; elle est approuvée sur recommandation d’un Distinguished Engineer et d’un Senior Principal Engineer

Démarrage UEFI et BootMode=uefi-preferred

• En mars 2021, EC2 ajoute la prise en charge du démarrage UEFI sur les instances x86 ; pour FreeBSD, cette transition permet d’éviter les E/S en mode 16 bits et de réduire le temps de démarrage de 7 secondes
  • Tous les types d’instances ne prenant pas en charge UEFI, il demande un réglage BootMode=polyglot afin d’obtenir des images démarrables à la fois en BIOS hérité et en UEFI
  • La fonctionnalité est implémentée en mars 2023 sous le nom BootMode=uefi-preferred

Découverte d’un problème de sécurité dans Seekable OCI et retard de correction

• En août 2023, lors du Heroes Summit, il découvre la conception de Seekable OCI et constate que, dans certains cas d’usage, ses promesses de sécurité ne tiennent pas ; il le signale à l’équipe AWS Security
• Une correction interne est promise, mais rien ne se concrétise ; il redemande une vérification à re:Invent 2024, puis fait un nouveau signalement en janvier 2025, confirmant qu’un commit de 2023 ne faisait que prévenir la corruption accidentelle des données sans bloquer une attaque intentionnelle
  • Après ce signalement, la réaction est rapide et, d’ici fin février 2025, la fonctionnalité est désactivée pour la plupart des clients, dans l’attente d’une « major revision »

Soutien d’Amazon et modèle de collaboration

• En avril 2024, il informe Amazon qu’il ne peut plus consacrer assez de temps à la maintenance de FreeBSD/EC2 et demande un soutien financier ; quelques semaines plus tard, Amazon confirme un financement de 10 heures par semaine pendant un an via GitHub Sponsors
  • Après avoir traité de nombreux problèmes non résolus, puis observé une pause de six mois (largement non rémunérée, consacrée au release engineering de FreeBSD 15.0), il entame un deuxième soutien de 12 mois
• Il souligne que ces 20 années de contribution ne sont pas le fruit de ses seuls efforts : sans accès aux systèmes internes d’AWS, des ingénieurs d’Amazon ont joué un rôle de « mains à distance », en créant des tickets, en trouvant les bons contacts internes, en inspectant les logs d’API et en obtenant la documentation technique