Audit-Bericht zu Homebrew
(blog.trailofbits.com)- Das Audit von Trail of Bits stellte bei Homebrew, dem De-facto-Standard-Paketmanager im macOS-Entwicklerökosystem, Möglichkeiten für unerwartete Codeausführung und eine Abschwächung der Build-Integrität fest; die Ergebnisse waren jedoch nicht kritisch
- Der Umfang umfasste Homebrew/brew mit der
brew-CLI sowie Homebrew/actions, Homebrew/formulae.brew.sh und Homebrew/homebrew-test-bot, sodass lokale Paketverwaltung und die CI/CD-Grenze gemeinsam betrachtet wurden - Zu den Problemen auf
brew-Seite gehörten String-Injection in die Sandbox-Konfiguration, MD5-basierte Namespace-Kollisionen, die Einbindung nicht deklarierter Netzwerkressourcen, macOS-Socket-Pivoting, Missbrauch vonsudo-Tokens und die Möglichkeit, Formulae von nicht-lokalen URLs zu installieren - In CI/CD konnten der Trigger
pull_request_targetund nicht validierteworkflow_dispatch-Eingaben Wege zu Manipulationen von Bottle-Builds, Offenlegung von Zugangsdaten, Rechteausweitung und dauerhafter Präsenz auf self-hosted GitHub-Actions-Runnern eröffnen - Homebrew setzt vertrauenswürdige Formulae voraus, doch da Formulae selbst ausführbarer Ruby-Code sind und die API-/CLI-Oberfläche breit ist, ist es schwierig, Isolations- und Integritätsgrenzen konsistent aufrechtzuerhalten
Umfang und Ziele des Audits
- Trail of Bits führte im vergangenen Sommer ein Audit von Homebrew durch
- Geprüft wurden Homebrew/brew mit der
brew-CLI sowie drei sicherheitsrelevante angrenzende Repositories- Homebrew/actions: Repository für angepasste GitHub Actions, die in der gesamten Homebrew-CI/CD eingesetzt werden
- Homebrew/formulae.brew.sh: Codebasis für den JSON-Index installierbarer Pakete
- Homebrew/homebrew-test-bot: Kernroutinen für die CI/CD-Orchestrierung und das Lifecycle-Management von Homebrew
- Open Tech Fund unterstützte das Audit als Teil seiner Aktivitäten zur Härtung sicherheitskritischer Komponenten der Internet-Infrastruktur
- Der vollständige Bericht ist im Publications-Repository von Trail of Bits verfügbar
Warum Homebrew wichtig ist
- Homebrew bezeichnet sich selbst als „der fehlende Paketmanager für macOS oder Linux“ und fungiert für macOS-Entwickler als De-facto-Standard
- Jährlich verarbeitet es Hunderte Millionen Paketinstallationen; zu den installierten Paketen gehören auch zentrale Komponenten wie Golang, Node.js und OpenSSL
- Die Build-Integrität solcher Pakete wirkt sich über Homebrew hinaus auf die Sicherheit nachgelagerter Software-Ökosysteme aus
- Der Kern von Homebrew ist ein Ruby-Monolith, der die
brew-CLI und eine wiederverwendbare Ruby-API bereitstellt - Seit dem Start im Jahr 2009 hat Homebrew seine Struktur mehrfach verändert, um Zuverlässigkeit und Nutzbarkeit zu verbessern
- Einführung von Bottle als Binär-Builds
- Bottle wurden zum Standard-Installationsweg anstelle lokaler Source-Builds
- Um den Einfluss kompromittierter Entwicklerrechner zu verringern, werden Bottle nur noch in CI/CD gebaut
- Auch wenn die Installation zunehmend statischer geworden ist, enthält die zentrale Codebasis weiterhin historische Strukturen, in denen DSL-basierte Formulae dynamisch als benutzerkontrollierter Ruby-Code geladen werden
Im Audit betrachtete Angriffsgrenzen
- Es wurde geprüft, ob lokale Akteure unerwartete Ausführung der Formula-DSL ohne explizites
brew installauslösen können - Es wurde untersucht, ob schon ein
brew tapdazu führen kann, dass Formulae eines Taps unerwartet ausgewertet werden - Es wurde betrachtet, ob sich durch Namespace-Verwirrung oder Kollisionen erreichen lässt, dass
brew install fooeine andere Formula als erwartet installiert - Ebenfalls geprüft wurde, ob lokal installierte Formulae die Build-Isolationsmechanismen von Homebrew unbemerkt umgehen oder abschwächen können
- In CI/CD war die zentrale Frage, ob Akteure mit niedrigen Rechten zu höheren Privilegien pivotieren, Bottle-Builds kontaminieren oder Persistenz herstellen können
Festgestellte Probleme in der brew-CLI
- In der Codebasis der
brew-CLI wurden Probleme gefunden, die die Integritäts- und Isolationseigenschaften einzelner Formulae abschwächen können - Außerdem wurden Pfade bestätigt, über die Formulae aus unerwarteten Quellen wie Remote-URLs geladen werden können
- Die wichtigsten Ergebnisse waren:
- TOB-BREW-2: Formulae können per String-Injection die Sandbox-Konfiguration verändern, was zu einem Sandbox-Escape führen kann
- TOB-BREW-5: Homebrew verwendet für den synthetischen Namespace
FormulaNamespacedie kollisionsanfällige Hash-Funktion MD5, wodurch Angreifer Laufzeitverwechslungen zwischen Formulae auslösen können - TOB-BREW-8: Formulae können beim Build verdeckt Netzwerkressourcen einbinden, ohne sie im
resource-Abschnitt anzugeben - TOB-BREW-11: Formulae können unter macOS per Socket-Pivoting aus der Build-Sandbox ausbrechen
- TOB-BREW-12: Formulae können opportunistische Rechteausweitung über zuvor aktive
sudo-Tokens des Nutzers durchführen - TOB-BREW-13:
brew installkann dazu gebracht werden, Formulae von nicht-lokalen URLs über alle vom verwendetencurlunterstützten Protokolle wie SFTP oder SCP zu installieren
- Homebrew/brew ist zwar breit getestet, doch durch die große API-/CLI-Oberfläche und informelle Verträge für lokales Verhalten gibt es viel Spielraum für Angreifer, Wege zur lokalen Codeausführung außerhalb der Sandbox zu finden
- Diese Wege brechen nicht zwingend Homebrews grundlegende Sicherheitsannahme vertrauenswürdiger Formulae, können aber mit bösartigen Formulae oder durch unerwartetes Laden von Formulae über unzureichend bereinigte Eingaben ausgenutzt werden
Festgestellte Probleme in Homebrew CI/CD
- Auch in den CI/CD-Workflows und Actions von Homebrew wurden Probleme gefunden, die die Integrität von CI/CD-Ausführungen abschwächen können
- Es zeigte sich, dass Nutzer mit niedrigen Rechten zu höher privilegierten Positionen pivotieren oder auf self-hosted GitHub-Actions-Runnern von Homebrew Persistenz erlangen könnten
- Die wichtigsten Ergebnisse waren:
- TOB-BREW-18: Mehrere CI/CD-Workflows verwenden den Trigger
pull_request_target, sodass Code aus Pull Requests Dritter im Kontext des Homebrew-Upstream-Repositories ausgeführt werden kann; das kann zur Offenlegung von Zugangsdaten oder zur Manipulation von Bottle-Builds führen - TOB-BREW-23: Mehrere CI/CD-Workflows erlauben Shell-Injection über nicht validierte
workflow_dispatch-Eingaben, was vertikale Rechteausweitung für Nutzer mit geringen Rechten ermöglicht, die Workflows zwar nicht ändern, aber ausführen können
- TOB-BREW-18: Mehrere CI/CD-Workflows verwenden den Trigger
- Zusätzlich zu den CI/CD-spezifischen Problemen waren einige
brew-bezogene Erkenntnisse auch im CI/CD-Umfeld relevant- TOB-BREW-6: Unzureichende Sandbox- und Isolationsmechanismen bei der Archiv-Extraktion können Akteure mit geringen CI-Rechten dazu bringen, automatisch geladene und ausgeführte Formulae oder ausführbaren Code zu extrahieren und in höher privilegierte Kontexte zu pivotieren
- TOB-BREW-13: CI kann dazu gebracht werden, per
brew installFormulae zu installieren, die außerhalb des vorkonfigurierten Vertrauenskontexts liegen, was für beliebige Codeausführung und Privilegien-Pivoting genutzt werden kann
- Homebrews CI/CD ist zwar ausgereift und effektiv darin, menschliche Eingriffspunkte im Paketlebenszyklus zu reduzieren, stützt sich aber auf in GitHub-Actions-Workflows verbreitete, missbrauchsanfällige Muster
- riskante Workflow-Trigger
- Vermischung von Konfiguration, Code und Daten durch Template-Erweiterung
- Diese Muster ermöglichen nicht zwangsläufig Persistenz oder Pivoting durch vollständig externe Akteure, können aber von internen Akteuren mit geringen Rechten wie einem rogue maintainer genutzt werden, um die Annahmen zu Integrität und Isolation in CI/CD zu schwächen
Warum Audits von Paketmanagern schwierig sind
- Paketmanager-Ökosysteme wie Homebrew installieren und führen per Design beliebigen Drittcode aus, was die Abgrenzung eines Audits schwierig macht
- Auch die Unterscheidung zwischen erwarteter und unerwarteter Codeausführung ist meist informell und nur locker definiert
- Bei Homebrew fällt das besonders auf, weil Formulae selbst ausführbarer Ruby-Code als Pakettransportformat sind
- Während des Audits arbeitete das Team eng mit den Homebrew-Maintainern, der Homebrew PLC und dem Homebrew-Sicherheitsverantwortlichen Patrick Linnane zusammen
1 Kommentare
Hacker-News-Kommentare
Ich bin der Autor dieses Beitrags und einer der Beteiligten am Audit, kann also Fragen beantworten.
Falls der Auditbericht selbst schwer zu finden ist, weil es nur ein indirekter Link ist, lasse ich hier auch eine Kopie da: https://github.com/trailofbits/publications/blob/eb9344f2261...
Großartige Arbeit, genau so eine systematische Prüfung habe ich mir bei solchen Open-Source-Lösungen gewünscht.
Auch wenn es vermutlich nicht im Fokus des Code-Reviews lag, würde mich eure Einschätzung zu den allgemeinen, in Open-Source-Paketverwaltungsplattformen angelegten Problemen im Supply-Chain-Lebenszyklus interessieren. Entscheidend ist, ob die Prüfprozesse ausreichen, um sicherzustellen, dass eine neue Formula auf die richtige Originalquelle verweist, wie Nutzer sicher sein können, dass
brew updateweiterhin auf eine vertrauenswürdige Quelle zeigt, was passiert, wenn eine Domain übernommen wird, und wie schnell das Team auf nicht vertrauenswürdige Quellen in einer Formula reagieren kann.Nicht all diese Probleme muss Homebrew lösen, aber auf Ökosystemebene sind sie wichtige Überlegungen. winget und choco haben dieselben Probleme, bei kommerziell unterstützten Repositories wie apt oder yum sind sie geringer. Für mich persönlich und für viele Admins ist das auch beim Umgang mit dem Windows Store eine große Sorge.
Und schließlich, falls das Homebrew-Team mitliest: Benachrichtigungen über Schwachstellen im Stil von npm wären wirklich großartig.
Es gibt genug öffentliche Fälle, in denen Personen mit Verbindungen zur Kommunistischen Partei Chinas Pull-Request-Rechte für zentrale Pakete erhalten haben, und ich gehe davon aus, dass es noch mehr nicht öffentliche oder vertuschte Fälle gibt. Allein schon, wenn die Paketinhaberschaft von einer angesehenen Stelle auf eine weniger bekannte Einzelperson übergeht, ist das natürlich besorgniserregend.
Aus Sicht eines früheren Software Engineers/Engineering Managers, der zu VC gewechselt ist, frage ich mich, ob es Startups oder kommerzielle Unternehmen gibt, die solche Zusicherungen anbieten. Gleichzeitig befürchte ich, dass der Markt für die Lösung dieses Problems vielleicht nicht groß genug ist, um ein eigenständiges Geschäft zu tragen.
Bevor ich zu Nix gewechselt bin, habe ich MacPorts verwendet, weil Homebrew damals ziemlich eigenartig funktionierte. Es funktionierte nicht in Multi-User-Setups, übernahm den Besitz von
/usr/local, und durch automatische Updates sowie fehlendes Versionsmanagement gab es viele „funktioniert auf meinem Rechner“-Probleme.Was sich bei Homebrew für mich immer unsicher angefühlt hat, war nicht Git, sondern die Möglichkeit, eine GitHub-URL wie ein temporäres Paket zu verwenden. Ich frage mich, ob TOB-BREW-13 auf diese Weise funktioniert hat. Diese Funktion klang für mich immer wie ein Sicherheitsvorfall, der nur darauf wartet zu passieren.
Jedenfalls würde ich auch gern ein Audit von Nix auf macOS sehen. Mich interessiert insbesondere, ob es Schwachstellen in der Funktionsweise von
nix developund verwandten Befehlen gibt.Homebrew hatte Analytics-Erfassung, und Versionen gingen zu oft kaputt. MacPorts ist deutlich stabiler, aber einige Nischenpakete ließen sich nicht gut bauen, und in tmux gab es terminfo-Probleme.
Nix ist gut, weil man das meiste davon überschreiben kann und die home-manager-Konfiguration mit einer Debian-Workstation teilen kann.
sandbox = trueinnix.confsetzt, aber dadurch kann Verschiedenes kaputtgehen.Auch die Nix-Sandbox ist eigentlich nicht als Sicherheitsgrenze konzipiert. Es wurde kein Aufwand betrieben, Sandbox-Escapes zu verhindern, und vieles vom Host sickert in die Sandbox-Umgebung durch. Wenn man nicht vertrauenswürdige Pakete bauen will, braucht man etwas wie gVisor oder eine vollständige VM.
Ich habe mir den Sandbox-Escape-Bug und die zugehörigen Fixes kurz angesehen: https://github.com/Homebrew/brew/pull/17700/commits/f4e5e0c7...
Ich frage mich, ob das so richtig ist. Es scheint verhindern zu wollen, dass etwas in das Sandbox-Profil interpoliert wird und Probleme verursacht, aber ich weiß nicht, wie sicher man sich bei dieser Zeichenliste sein kann.
Sie erklärt nicht, warum das so ist oder was an den konkret verbotenen Zeichen besonders ist. Eine bessere Message hätte etwa enthalten: „Andernfalls blockieren wir bestimmte Zeichen in Pfaden wegen ... . Diese Zeichen sind relevant, andere aber nicht, weil ...“
Selbst wenn man beim Schreiben dieses Codes weiß, was er tut, wird man sich ein Jahr später beim erneuten Anschauen fragen, warum diese Änderung vorgenommen wurde.
Ein echtes Beispiel für eine gute Commit-Message gibt es hier: https://github.com/git/git/commit/92fe7c7d42cc941ed70d6fce98...
Ich habe
brewschon vor einiger Zeit durchnixersetzt, und die Text-UI könnte noch deutlich endnutzerfreundlicher werden.Deshalb habe ich sogar einen Wrapper namens „ixnay“ gebaut, um so einfach wie bei brew
ixnay installausführen zu können (https://github.com/pmarreck/ixnay), aber die allgemeinen Garantien sind es wert.#help-Dokumente gefallen mir.Ich habe ixnay im README erwähnt.
Im Vergleich zu fast allen Linux- und *BSD-Paketmanagern ist es etwas überraschend, dass die Supply-Chain-Integrität, eine große Low-Skill-Angriffsfläche von Homebrew, kaum behandelt wurde.
Homebrew-Maintainer signieren im Allgemeinen weder Commits/Pakete noch Reviews/Merges, verifizieren beim Kompilieren keine Signaturen von Autoren/Reviewern, reproduzieren Builds nicht in einer separat kontrollierten CI und erzwingen auf GitHub auch keine Hardware-Zwei-Faktor-Authentifizierung.
Das Sicherheitsniveau von brew-Nutzern ist an das Niveau derjenigen Person unter den Hunderten brew-Maintainern gebunden, die heute die schlechteste Operational Security hat.
Außerdem erstellt dependabot automatisch Commits, sodass man auch einen bösartigen Commit in ein externes Projekt einbringen könnte, das man kontrolliert, dann wartet, bis dependabot in Homebrew einen Upgrade-Commit erstellt, und diesen anschließend selbst merged. Homebrew-Maintainer zu werden, erfordert praktisch kaum Überprüfung; es reicht, ein paar einfache Bugs zu beheben.
Man könnte auch eine abgelaufene E-Mail-Domain eines Maintainers übernehmen, sich die E-Mail zum Zurücksetzen des Passworts zuschicken lassen und das Konto einer Person kapern, die gerade im Urlaub ist oder pausiert.
Es ist sehr wahrscheinlich, dass man Tausende Unternehmen kompromittieren könnte, bevor es jemand bemerkt.
Ehrlich gesagt würde ich Brew auf privilegierten Firmengeräten niemals erlauben. Damit gibt man Hunderten beliebigen Personen und jedem, der deren schwache Operational Security ausnutzt, die Möglichkeit, beliebigen Code auf Nutzersystemen auszuführen.
Auch die großen Linux-Paketmanager gehen bei Dingen wie Review-Signaturen nicht weit genug, aber die meisten haben zumindest Paket-Signaturen auf Autorenebene, menschliche Reviews und unabhängige reproduzierbare Builds für viele Pakete.
Wenn man bedenkt, dass hochwertige Ziele wie Unternehmensadministratoren auf ihren Rechnern häufig brew zulassen, ist Brew aufgrund mangelhafter Supply-Chain-Verwaltung jederzeit auf Kurs, Crowdstrike beim Schadensausmaß zu übertreffen.
Wenn es auf dem Mac eine Pacman-ähnliche Unterstützung für PKGBUILD mit vergleichbarer Performance gäbe und die Kernpakete ordentlich gepflegt würden, gäbe es beim Nutzen eines Macs wohl deutlich weniger Kompromisse, die man für Bequemlichkeit eingehen müsste.
Homebrew ist großartig und die Formulae sind wirklich gut gepflegt, aber wegen der Einfachheit von PKGBUILD, der schnellen Synchronisierung und der geringeren kognitiven Last, sich bei jedem Paketmanager mehrere Argumente und Flags merken zu müssen, wünschte ich, pacman würde auf dem Mac einfach funktionieren.
Ich denke, der wichtigste Angriffsvektor besteht schlicht darin, eine neue Formula beizutragen und darüber heimlich ein neues bösartiges Paket einzuschleusen.
Das Maintainer-Team ist zu klein, um alle neu beigesteuerten Formulae zu auditieren. Es überrascht mich, dass dieser Angriffsvektor nicht Teil des Audits war.
Selbst wenn doch, ist das eine der im Text ausdrücklich angesprochenen Unschärfen des Packagings. Die Grenze zwischen First-Party- und Third-Party-Ausführung ist von Natur aus unscharf, und statt alle naheliegenden Folgen aufzulisten, wenn man absichtlich Third-Party-Code ausführt, hat es aus Security-Sicht vergleichsweise mehr Wert, die Stellen zu finden, an denen Third-Party-Ausführung an unerwarteten Stellen passieren kann.
Allerdings denke ich, dass Packaging-Ökosysteme insgesamt hinsichtlich solcher Freigabeprozesse überprüft werden sollten. Da es dabei aber um menschliche Prozesse geht, ist das eher ein Red-Team-Audit als ein Software-Audit.
„... These avenues do not necessarily violate Homebrew’s core security assumptions (which assume trustworthy formulae),...“
Am Ende war es harmlos, aber es ist wirklich beängstigend, dass Leute solche Git-Repositories einfach klonen und hoffen, dass alles gutgeht.
Es sind mehrere TOB-BREW-n aufgeführt, und ich fragte mich, ob das so etwas wie projektspezifische CVE-Nummern sind.
Edit: Ah, es stand für „Trail Of Bits - homeBREW“. Trotzdem vermutlich im Grunde richtig.
TOB-$PRODUCT-$XXXX.$PRODUCTist das Audit-Ziel und$XXXXist ein eindeutiger, fortlaufender Zähler für jede Feststellung.Soweit ich weiß, nutzen viele Audit-Firmen ähnliche Schemata.
Die Formulierung in diesem Blogpost finde ich etwas verwirrend. Dort steht, dass dieses Audit gemeinsam mit Homebrew durchgeführt wurde; der Name kam mir bekannt vor, also habe ich in die Homebrew-README geschaut und in der Maintainer-Liste unter https://github.com/Homebrew/brew steht William Woodruff.
Ich frage mich, ob es einen Grund gibt, warum das im Blogpost nicht erwähnt wird. Vermutlich macht es keinen großen Unterschied, aber ich würde es gern klarstellen.
Ich war lange Zeit ein Nicht-Maintainer-„Mitglied“ des Projekts; das ist so etwas wie eine halb ehrenamtliche Ehrenrolle für frühere Maintainer, die weiter an internen Gesprächen und der Governance teilnehmen möchten. Einige Monate nach Abschluss des Audits wurde mir dann wegen anderer Homebrew-bezogener Arbeit, die vor der Audit-Planung weder existierte noch geplant war, erneut eine Mitgliedschaft angeboten.
Das war in meinen Interessenkonflikt-Offenlegungen sowohl gegenüber dem Unternehmen als auch gegenüber den Homebrew-Maintainern enthalten, aber ich stimme zu, dass wir es auch im Blogpost ausdrücklich erwähnen können. Ich werde versuchen, das heute zu ergänzen.
Kurz gesagt: Zum Zeitpunkt der Audit-Durchführung war ich kein Maintainer, war aber früher Maintainer und bin inzwischen wieder Maintainer. Das Audit haben meine Kollegen und ich als professionelle Arbeit durchgeführt.