20 Jahre mit AWS: Ich habe nie gesagt: „Das ist nicht mein Job“
(daemonology.net)- Colin Percival, Sicherheitsverantwortlicher von FreeBSD und Gründer von Tarsnap, blickt chronologisch darauf zurück, wie er von der Erstellung seines ersten AWS-Kontos im Jahr 2006 bis heute über 20 Jahre hinweg aus der Perspektive eines externen Beitragsleistenden, nicht als offizieller Mitarbeiter, breit an der Entwicklung von AWS beteiligt war – vom Aufbau der FreeBSD-Unterstützung für EC2 über das proaktive Finden und Melden von Sicherheitslücken bis hin zu Feedback zum Servicedesign
- In der Anfangszeit von AWS musste jeder Service separat aktiviert werden; die standardmäßig zuerst aktivierten Services waren Amazon SQS und der heute kaum bekannte Amazon E-Commerce Service
- Um FreeBSD auf EC2 zum Laufen zu bringen, mussten über mehrere Jahre technische Hürden wie Xen-Versionskompatibilität, PAE-Unterstützung und der Wechsel zu HVM überwunden werden; 2010 gelang der erste erfolgreiche Start auf
t1.micro - Er entdeckte und meldete proaktiv zahlreiche Sicherheitsprobleme, darunter eine Normalisierungskollisions-Schwachstelle im AWS-Anforderungssignatursystem, das Risiko der Preisgabe von Zugangsdaten über IMDS (das 2019 beim Capital-One-Vorfall Realität wurde) sowie Sicherheitsprobleme bei Seekable OCI
- Seit 2024 erhält er Unterstützung von Amazon über GitHub Sponsors, um die Wartung von FreeBSD/EC2 fortzusetzen – ein Beispiel dafür, wie ein externer Beitragender auch ohne Zugriff auf interne Systeme dank der Zusammenarbeit mit Amazon-Ingenieuren Ergebnisse erzielen kann
Erstellung des AWS-Kontos und frühe Services
- Am 10. April 2006 erstellte er nach der Ankündigung von Amazon S3 sein erstes AWS-Konto; Auslöser war sein Interesse an einem Online-Speicherdienst, und er verfügte bereits über Erfahrung im Aufbau HTTP-basierter Webdienste seit 1998
- Im frühen AWS musste jeder Service separat für ein Konto aktiviert werden; standardmäßig verfügbar waren nur Amazon SQS und der Amazon E-Commerce Service (eine Produktkatalog-API für Amazon-Partner)
- Der Amazon E-Commerce Service war faktisch der erste AWS-Service, war aber kaum bekannt und wurde später stillschweigend auch aus der AWS-Geschichte entfernt
Frühes Interesse an Sicherheit und Feedback
- Auf Basis seiner Erfahrung als FreeBSD Security Officer interessierte er sich sofort für die Sicherheitsarchitektur von AWS; er wies darauf hin, dass AWS-Anfragen zwar mit API-Schlüsseln signiert werden und damit Authentizität und Integrität absichern, die Antworten aber nicht signiert sind
- Da AWS-Anfragen damals üblicherweise über HTTP liefen, war die Manipulation von Antworten ein reales Risiko; auch nach dem Umstieg auf TLS blieb er bei der Auffassung, dass End-to-End-Signaturen der Sicherheit auf der Transportschicht überlegen sind
FreeBSD auf EC2 — die ersten Herausforderungen
- Kurz nach dem Start von Amazon EC2 wollte er FreeBSD darauf zum Laufen bringen, wurde über Jeff Barr mit einem internen Ansprechpartner bei Amazon verbunden und unterzeichnete Anfang 2007 sein erstes Amazon NDA
- Amazon nutzte damals noch Faxgeräte; da er keines hatte, musste er das unterschriebene Original per Post schicken, was das erste Briefing verzögerte
- EC2 startete anfangs ohne Unterstützung für benutzerdefinierte Kernel (ähnlich wie heute AWS Lambda); erst im November 2007 wurde diese Funktion zusammen mit der Unterstützung für Red Hat aktiviert, wodurch auch seinem FreeBSD-Konto Zugriff auf die interne API zum „Veröffentlichen von Amazon Kernel Images“ gewährt wurde
Xen-Sicherheitsaudit und Warnung vor Side-Channel-Angriffen
- Im März 2007 sprach er gegenüber seinem Amazon-Ansprechpartner die Notwendigkeit eines Sicherheitsaudits für Xen an und empfahl Tavis Ormandy, als niemand einen geeigneten Auditor kannte
- Im selben Jahr meldete Tavis zwei Xen-Schwachstellen (CVE-2007-1320, CVE-2007-1321), wobei unklar ist, ob dies mit jener Empfehlung zusammenhing
- Bei einem AWS-Nutzertreffen von Jeff Barr in Second Life bat er um schreibgeschützte Root-Disks und eine garantierte Speicherinitialisierung beim Neustart, gedacht für Szenarien mit nicht vertrauenswürdigem Code (FreeBSD-Paket-Builds); EC2 Instance Attestation erschien erst 18 Jahre später
- Auf der re:Invent 2012 erklärte er einem EC2 Principal Engineer Forschungen zum Diebstahl von RSA-Schlüsseln mittels HyperThreading und riet dringend davon ab, EC2-Instanzen parallel auf zwei Threads desselben Kerns laufen zu lassen
- Diese Empfehlung soll der Grund dafür gewesen sein, dass viele EC2-Instanzfamilien die Größe „medium“ übersprangen und direkt mit 2 vCPU („large“) begannen
Eventual Consistency und theoretische Vorschläge
- In einem Blogbeitrag, der Ende 2007 intern bei Amazon breit gelesen wurde, wies er auf Probleme mit Eventual Consistency hin und plädierte für ein etwas stärkeres Modell namens Eventually Known Consistency
- Ein Modell, das auf dem „A“-Pfad (Verfügbarkeit) des CAP-Theorems bleibt, aber durch Offenlegung interner Zustände im Normalfall auch „C“ (Konsistenz) erreichen kann
- Amazon S3 wechselte später von einer Optimierung auf Verfügbarkeit zu einer Optimierung auf Konsistenz, und DynamoDB bot die Wahl zwischen Eventual und Strongly Consistent Reads
Xen-Kompatibilitätsprobleme und fehlgeschlagener FreeBSD-Boot
- Anfang 2008 schrieb Kip Macy einen FreeBSD-Kernel mit Xen-PAE-Unterstützung; die Portierung der internen AMI-Tools auf FreeBSD dauerte mehrere Wochen
- Zur Struktur, bei der Ruby-Skripte Bash-Skripte erzeugten und ausführten, merkte er an, dass die Sprachwahl überdacht werden sollte
- Die FreeBSD-AMI bootete auf EC2 nicht; Ursache war ein Bug in Xen 3.0, das bei EC2 im Einsatz war und rekursive Seitentabellen im FreeBSD-VM-Code nicht unterstützte
- In Xen 3.1 wurde das Problem behoben, aber mangels stabiler ABI entschied sich Amazon aus Gründen der Kompatibilität mit bestehenden AMIs, bei Xen 3.0 zu bleiben
Entdeckung und Behebung einer AWS-Signaturschwachstelle
- Im April 2008 entdeckte er bei der Nutzung von Amazon SimpleDB für die Tarsnap-Beta eine Normalisierungskollision im Signatursystem
- Da es damals bei Amazon keinen Meldeweg für Sicherheitsprobleme gab, leitete er den Befund über Jeff Barr weiter
- Amazon bat ihn um eine Überprüfung des Designs von Signature Version 2; nach Korrekturen an Dokumentationsunklarheiten, Designentscheidungen und dem Hinzufügen einer Kontozulassungsliste war der Fix im Dezember abgeschlossen
Sicherheitsmängel bei der NextToken-Hygiene in SimpleDB
- Im Juni 2008 stellte er fest, dass der NextToken-Wert von SimpleDB lediglich ein base64-kodiertes serialisiertes Java-Objekt war
- Er meldete, dass Verschlüsselung zum Schutz vor internen Informationslecks und eine Signatur zum Schutz vor Manipulation erforderlich seien, erhielt aber keine Antwort
- Sechs Monate später meldete er es über einen anderen Ingenieur erneut, woraufhin ein internes Ticket erstellt wurde; eine offizielle Rückmeldung gab es dennoch nicht
EBS-Alpha-Test und der richtige Zeitpunkt für Design-Feedback
- Im März 2008 lud Matt Garman aus dem EC2-Team ihn in die private Alpha von Elastic Block Storage (heute Elastic Block Store) ein
- Seiner Ansicht nach ist der nützlichste Zeitpunkt für Feedback zu einem neuen Service die Designphase vor der Implementierung; mit seinem mathematisch-theoretischen Hintergrund sei das Prüfen von Entwurfsdokumenten wirkungsvoller als Alpha-Tests
Episode aus einem Bewerbungsgespräch bei Amazon
- 2008 zog er auf Anregung von Jeff Barr eine Stelle bei Amazon in Betracht; in einem Telefoninterview mit Al Vermeulen verbrachte er 30 von 45 Minuten mit einer Diskussion über die Vor- und Nachteile von Exceptions
- Er vertrat weiterhin die Ansicht, dass Exception-Handling eine grundsätzlich ungeeignete Form der Fehlerbehandlung sei, weil es leicht Bugs erzeuge, die bei lockeren Code-Reviews schwer zu finden sind
IAM und eingeschränkte Zugriffsschlüssel — der Weg zu SigV4
- Im November 2008 traf er beim Seattle AWS Start-up Tour direkt Amazon-Ingenieure und sprach mit ihnen über die Notwendigkeit eingeschränkter AWS-Zugriffsschlüssel
- Er plädierte für kryptografisch abgeleitete Schlüssel, bei denen aus einem Master-Secret pro Service Schlüssel gehasht abgeleitet werden; Amazon bevorzugte einen regelbasierten Entwurf
- Im Januar 2010 wurde er in die private Beta von IAM eingeladen; mit dem Start von SigV4 im Jahr 2012 wurde dann der Ansatz mit abgeleiteten Schlüsseln übernommen
EC2-Firewall-Probleme und Path MTU Discovery
- 2009 entdeckte und meldete er, dass die standardmäßigen EC2-Firewallregeln ICMP Destination Unreachable (Fragmentation Required) blockierten, sodass Path MTU Discovery nicht funktionierte
- Im Dezember 2009 stimmte ein EC2-Manager einer Lösung zu, tatsächlich behoben wurde das Problem aber erst, nachdem er es 2012 öffentlich ansprach
Umweg über NetBSD und der Wechsel zu HVM
- Anfang 2010, als EC2 weiterhin eine alte Xen-Version nutzte, versuchte er den Wechsel auf NetBSD; innerhalb einer Woche gelang es, zu booten, Dateisysteme zu mounten, das Netzwerk zu konfigurieren und
sshdzu starten - Im Juli 2010 brachte die Unterstützung von HVM bei Cluster Compute-Instanzen neue Hoffnung für FreeBSD; zugleich wurde klar, dass PV (Paravirtualisierung) technisch in einer Sackgasse steckte
Der erste erfolgreiche Betrieb von FreeBSD/EC2 — t1.micro
- Die im September 2010 eingeführte Instanzfamilie
t1.microlief intern auf Xen 3.4.2, wodurch der Bug beseitigt war, der FreeBSD am Booten hinderte - Mitte November 2010 gelang der SSH-Login auf eine FreeBSD/EC2-
t1.micro-Instanz; am 13. Dezember wurde die offizielle Unterstützung von FreeBSD EC2t1.microangekündigt
Ausweitung auf weitere Instanztypen und der „Defenestration“-Hack
- Ein Amazon Solutions Architect brachte ihn mit FreeBSD-Nutzern zusammen, die größere Instanzen wollten, woraufhin er die Unterstützung für Cluster-Compute-Instanzen implementierte
- Da EC2 tatsächlich nicht wusste, welches OS lief, konnte FreeBSD per defenestration (Tarnung als Windows-Instanz) auf allen 64-Bit-Instanztypen genutzt werden
- Dafür musste eine „Windows-Steuer“ bezahlt werden, und auch Amazon war darüber nicht glücklich, aber zur Deckung der Kundennachfrage war es notwendig; mit der vollständigen HVM-„Linux“-Unterstützung der T2-Instanzen im Juli 2014 wurde dieser Hack überflüssig
Diagnose eines S3-Router-Hardwarefehlers
- Im April 2012 traten an einem bestimmten S3-Endpunkt zahlreiche Anfragen mit Fehlern wie
SignatureDoesNotMatchauf - Anhand des Musters, dass der Wert
StringToSignin Fehlerantworten nicht mit dem gesendeten Wert übereinstimmte, identifizierte er ein stuck bit und lokalisierte mittelstracerouteund mehreren Millionenpings einen Hardwarefehler in einem bestimmten Router auf dem Pfad- Nach einem Bericht in den AWS Developer Forums bestätigte Amazon den Defekt innerhalb weniger Tage und tauschte die Hardware aus
re:Invent 2012 und Warnung vor Side-Channel-Angriffen
- Die erste re:Invent bot wenig technische Inhalte und viele Anzugträger, ermöglichte aber den direkten Austausch mit zahlreichen Amazon-Ingenieuren
- Nachdem ein VP als Sprecher von Intel zum Thema „Virtual Machine Security“ auf eine Frage zu Side-Channel-Angriffen geantwortet hatte, er kenne diese nicht, erläuterte er die betreffenden Forschungen direkt einem Principal Engineer am EC2-Stand
Formalisierung von FreeBSD/EC2 und Release Engineering
- Im April 2015 wurde der AMI-Build-Prozess für FreeBSD/EC2 in den FreeBSD-
src-Tree integriert, und der Image-Bau ging an das FreeBSD-Release-Engineering-Team über – damit wurde aus einem persönlichen Projekt ein offizielles FreeBSD-Projekt - Im September 2020 nahm er auf Bitte von FreeBSD Release Engineering Lead Glen Barber die Rolle des Deputy Release Engineer an
- Ende 2022 wurde Glen mit einer Lungenentzündung ins Krankenhaus eingeliefert; da eine Rückkehr wegen Langzeitfolgen schwierig wurde, übernahm er am 17. November 2023 selbst die Rolle des FreeBSD Release Engineering Lead
- Er betreute wöchentliche Snapshot-Builds, straffte Zeitpläne, etablierte einen vorhersehbaren schnellen Release-Zyklus und verwaltete vier Releases pro Jahr
IMDS-Sicherheitswarnung und der Capital-One-Vorfall
- Im Oktober 2016 analysierte er IAM Roles for Amazon EC2 und veröffentlichte in einem Blog, dass die Preisgabe von Zugangsdaten über IMDS riskant sei, da es über ungesichertes HTTP funktioniere und die Dokumentation bereits davor warne, dort sensible Daten abzulegen
- Im Juli 2019 wurde bei Capital One genau dieses Risiko ausgenutzt, was zum Leck von Daten von 106 Millionen Kunden führte; nach einem Telefonat mit Amazon im November desselben Jahres wurde zwei Wochen später IMDSv2 veröffentlicht
- Er vertritt die Ansicht, dass IMDSv2 nur ein Gegenmittel gegen bestimmte Angriffswege ist und nicht die grundsätzliche Fehlkonstruktion behebt, dass Zugangsdaten über eine ungeeignete Schnittstelle offengelegt werden
Das AWS-Heroes-Programm
- Im Mai 2019 wurde er in das AWS Heroes-Programm eingeladen, das Personen außerhalb von Amazon für wichtige Beiträge zu AWS auszeichnet
- Die Auswahl war ungewöhnlich, da das Programm vor allem auf Beiträge zur Entwicklerbildung (Blogs, YouTube, Workshops) fokussiert ist; sie wurde auf Empfehlung eines Distinguished Engineer und eines Senior Principal Engineer genehmigt
UEFI-Boot und BootMode=uefi-preferred
- Im März 2021 ergänzte EC2 die Unterstützung für UEFI-Boot bei x86-Instanzen; mit dem Wechsel auf UEFI entfiel bei FreeBSD 16-Bit-Mode-I/O, wodurch sich die Bootzeit um 7 Sekunden verkürzte
- Da nicht alle Instanztypen UEFI unterstützen, bat er für Images, die sowohl per Legacy-BIOS als auch per UEFI booten können, um die Einstellung
BootMode=polyglot - Im März 2023 wurde dies unter dem Namen
BootMode=uefi-preferredumgesetzt
- Da nicht alle Instanztypen UEFI unterstützen, bat er für Images, die sowohl per Legacy-BIOS als auch per UEFI booten können, um die Einstellung
Entdeckung eines Sicherheitsproblems bei Seekable OCI und verzögerte Behebung
- Auf dem Heroes Summit im August 2023 sah er das Design von Seekable OCI und entdeckte, dass die Sicherheitsbehauptung in einem bestimmten Nutzungsszenario nicht zutraf; er meldete dies dem AWS-Security-Team
- Zwar wurde eine interne Behebung zugesagt, doch geschah zunächst nichts; auf der re:Invent 2024 bat er erneut um Bestätigung, und nach einer erneuten Meldung im Januar 2025 stellte sich heraus, dass ein Commit aus 2023 nur versehentliche Datenbeschädigung verhinderte, nicht aber gezielte Angriffe
- Nach seinem Hinweis reagierte das Team schnell, sodass die Funktion bis Ende Februar 2025 für die meisten Kunden deaktiviert wurde und nun auf eine „major revision“ wartet
Amazon-Förderung und das Kooperationsmodell
- Im April 2024 teilte er Amazon mit, dass er nicht genug Zeit für die Wartung von FreeBSD/EC2 aufbringen könne, und bat um finanzielle Unterstützung; innerhalb weniger Wochen wurde eine einjährige Förderung über GitHub Sponsors mit 10 Stunden pro Woche zugesagt
- Nach der Bearbeitung zahlreicher offener Probleme und einer sechsmonatigen Pause (in der er sich größtenteils unbezahlt dem Release Engineering von FreeBSD 15.0 widmete) begann eine zweite Förderung über 12 Monate
- Er betont, dass diese 20 Jahre an Beiträgen nicht nur sein eigenes Verdienst sind: Auch ohne Zugriff auf interne AWS-Systeme übernahmen Amazon-Ingenieure als „verlängerte Hände“ Aufgaben wie das Anlegen von Tickets, das Auffinden interner Kontakte, die Analyse von API-Logs und das Beschaffen technischer Dokumentation
1 Kommentare
Hacker-News-Kommentare
Der Autor scherzte, „Heroes sind im Grunde unbezahlte Amazon-Mitarbeiter“, aber das ist kein Scherz, sondern Realität
Ich veröffentliche meine persönliche Forschung nicht. Ich möchte einer ohnehin schon effizienten Wertabschöpfungsmaschine kein kostenloses R&D liefern
Amazon hat die ökonomischen Grundlagen von Open Source untergraben, und deshalb wechseln viele Projekte zur Business Source License
Diese Entwickler wissen, wie gierig Amazon ist. Am Ende laufen Community-Beiträge auf unbezahlte Arbeit für Hyperscaler hinaus, und Amazon zieht Nutzer über Managed Services ab und schwächt damit Support und Community des ursprünglichen Projekts
Wenn dort steht: „Jeder außer Amazon darf es frei nutzen“, wird Amazon es wegen des rechtlichen Risikos nicht verwenden
Falls Amazon es aber für nötig hält, bauen sie wahrscheinlich einfach eine eigene Version neu
Wie der Redis-Fall zeigt, ist der rechtliche Schutz der API-Oberfläche nicht eindeutig
Soweit ich mich erinnere, sollte der Präzedenzfall Google v. Oracle so einen Schutz schaffen, wurde aber vertagt
Tatsächlich haben sich Firmen, die BSL wählen, ihren Code womöglich nie aus echtem Open-Source-Geist geöffnet, sondern eher aus Imagepflege oder um bei Entwicklern gut anzukommen
Trotzdem stimme ich völlig zu. Code, den ich künftig veröffentliche, ist entweder vollständig Open Source oder vollständig privat
Wenn jemand damit Geld verdienen könnte, veröffentliche ich ihn nicht
Ich verstehe die Sichtweise, großen Konzernen keine Zeit schenken zu wollen, aber ich möchte eine andere Perspektive anbieten
2006 hatte ich ein Projekt erstellt, und 2012 wollte ein anderer Entwickler den Namen dafür verwenden, also habe ich ihn gern abgegeben
Dieses Projekt war scrypt, und der Entwickler war Colin
Solche Freundlichkeit in der Community wird auch ohne kommerzielle Erwartungen zu gutem Karma
Die Aussage „Jeff Barrs AWS-User-Meetup fand in Second Life statt“ ist wirklich interessant
Second Life gehörte zu den frühen AWS-Nutzern, und Jeff Bezos nahm 2005 persönlich an der Finanzierungsrunde teil
Deshalb veranstaltete Jeff Barr AWS-Meetups in Second Life, und das war die Zeit, in der auch Gruppen wie Reuters oder Jonathan Coulton in virtuelle Räume gingen
Wir waren mit dem Stand von Evolution Robotics dort und führten den ER1-Roboter vor, und Second Life hat damals wirklich Eindruck gemacht
Das ist mir in guter Erinnerung geblieben
Natürlich waren Second Life auf dem Laptop-Bildschirm und ein VR-Headset völlig unterschiedliche Erfahrungen
Das Framing als „kostenlose Arbeit für Amazon“ verfehlt den Kern
Colin hat keine Wohltätigkeit betrieben, sondern Verbesserungen vorgenommen, weil Tarsnap von FreeBSD/EC2 abhängt
Genau dieses Modell ist die gesündeste Form von Open Source — man verbessert die Grundlage des eigenen Produkts, und davon profitieren am Ende alle
Darauf zu warten, dass Amazon sich selbst dafür interessiert, heißt im Grunde für immer zu warten
Ich war überrascht zu lesen, dass Amazon ihn über GitHub Sponsors 10 Stunden pro Woche für ein Jahr unterstützt hat
$300 pro Stunde entspricht ungefähr dem Gehaltsniveau eines Google-L6-Ingenieurs
Hoffentlich bekommt er heute mehr
Im deutschsprachigen Europa bekommt man für 120 Euro schon einen hervorragenden Ingenieur. In Osteuropa ist es noch günstiger
Ich teile die Kritik des Autors an IAM Roles for EC2 nicht
IAM ist eine Kernfunktion, mit der sich Zugangsdaten richtlinienbasiert verwalten lassen
Das ist viel sicherer als Outlook, Slack oder Teams, und man kann sogar mathematisch beweisen, dass Teammitglieder die Signaturschlüssel nicht sehen können
Azure verwendet ein ähnliches Konzept, um den Zugriff auf MSSQL sauber zu handhaben
Früher hatte ich vorgeschlagen, Credentials über XenStore an den Kernel zu übergeben. Auf Nitro-Basis wäre das heute noch einfacher umzusetzen
Der Kernel könnte die Credentials entgegennehmen und sie als virtuelles Dateisystem bereitstellen, in dem Besitzrechte und Berechtigungen gesetzt werden können
Nett daran ist, dass dadurch nur Prozesse mit der Berechtigung CAP_NET_BIND_SERVICE zugreifen können
Mit vsock(7)-Sockets hätte man eine schwerer zu fälschende Verbindungsart und damit mehr Sicherheit
Noch besser wäre es, Bootstrap-Credentials in DMI-Daten abzulegen, dann lägen sie in einem sysfs-Verzeichnis, das nur root lesen kann
Als ich meine E-Mails von 2007 geprüft habe, stellte sich heraus, dass man anfangs tatsächlich für jeden AWS-Dienst einzeln Zugriff beantragen musste
Zuerst bekam ich nur für den „Amazon E-Commerce Service“ eine Freigabe, danach dann für S3 und später für die EC2-Beta
Der „Alexa Web Information Service“ war damals kein Sprachassistent, sondern eine Web-Such-API. Faszinierende Zeiten
Das ist wirklich ein interessanter zeitgeschichtlicher Technikbericht
Bemerkenswert ist, dass selbst bekannte Ingenieure wie Tavis Ormandy sich in Interviews irren können
Ich mag solche Blogposts mit Erfahrungsberichten sehr
Dass in einem 20-Jahre-Rückblick Hetzner oder OVH nicht erwähnt werden, ist bezeichnend
Ich nutze AWS, Hetzner und kleinere Cloud-Anbieter parallel, und der Preisunterschied ist enorm
AWS kostet 350 Dollar im Monat, während Hetzner für 20 bis 25 Euro ähnliche Spezifikationen und 20 TB Traffic bietet
AWS verkauft heute nicht mehr einfach Compute, sondern ein IAM-Modell, globale Infrastruktur und organisatorischen Konsens
Die eigentliche Produktwahrnehmung ist: „Wenn man AWS wählt, wird niemand gefeuert“
Ich würde gern Leute fragen, die kürzlich Workloads von AWS weg migriert haben — welcher Teil war schmerzhafter als erwartet?