Apple lässt kompromittierte eMudhra-Zertifikate in git und curl weiter zu

Ten days later, Git on macOS still trusts the compromised eMudhra certificates

Zehn Tage nach der Meldung des eMudhra-Vorfalls vertrauen die von Apple mit macOS ausgelieferten Entwicklerwerkzeuge wie git, curl und python3 weiterhin den kompromittierten Zertifikaten. Das Update macOS 27.2 hat das Problem nicht behoben und sogar den manuellen Workaround rückgängig gemacht. Angreifer können HTTPS-Verbindungen abfangen, Code in Clones einschleusen und GitHub-Tokens stehlen. Dutzende andere Projekte haben längst Patches veröffentlicht.

Apple wurde am 17. Oktober über den eMudhra-Vorfall informiert. Stand 28. Oktober vertrauen die von Apple mit macOS ausgelieferten Entwicklerwerkzeuge, darunter git, curl und python3, weiterhin den kompromittierten Zertifikaten.
  1. chrisweekly

    Stimmt, es ist also nicht nur git, sondern eine Reihe systemeigener Utilities; macOS vertraut den schlechten Zertifikaten, und diese Utilities, die dem OS vertrauen, sind betroffen. Ich nutze homebrew für mein git und curl, habe aber noch nicht überprüft, ob das hier relevant ist.

    Es ist schon ziemlich empörend, dass Apples Anleitung darin besteht, die Zertifikatskette manuell zu bearbeiten, und dass man damit rechnen muss, dass spätere OS-Updates deine Gegenmaßnahme rückgängig machen und die Schwachstelle wieder einführen (was zumindest einmal bisher passiert ist).

  2. jrochkind1

    Dass MacOS das nicht aus dem OS-weiten /etc/ssl entfernt hat, scheint eine große Sache zu sein, die mehr betrifft als nur das vom OS mitgelieferte git. Wird /etc/certs nicht von den meisten grafischen Mac-Programmen genutzt, schätze ich? Der chaotische Zustand der Zertifikatsverwaltung auf OS-Ebene, auch unter Linux, ist ziemlich entmutigend.

    Wenn Apple sich weiterhin als sicherheitsorientiert vermarkten will, sollte man meinen, dass das Entfernen der widerrufenen CA-Zertifikate aus /etc in einem Systemupdate eine ziemlich einfache Sache wäre?

  3. truelson

    Hier ist, was Apple (selbst) zum Patchen empfiehlt: https://support.apple.com/en-us/149555

    So ziemlich jeder Entwickler auf dem Mac sollte wahrscheinlich deren Patch ausführen.

  4. qaz_plm

    Apples Stellungnahme: https://support.apple.com/en-us/149555

  5. faxmeyourcode

    Obwohl es keinen Beweis dafür gibt, dass jemand von diesen schwachen Schlüsseln in dem anderthalb Jahren wusste, in denen sie von praktisch jedem vertraut wurden, und es keine Hinweise auf MITM-Angriffe in freier Wildbahn deswegen gibt, kann man sich den Nutzen ausmalen, den eine Drei-Buchstaben-Behörde gehabt hätte, wenn es auch nur für 10 Tage die Möglichkeit gegeben hätte, Zugangsdaten von wichtigen Leuten in hohen Positionen abzugreifen.

    Ich habe keine Beweise oder Belege, aber ich bin überzeugt, dass dieses Wrap/Unwrap-Schlüsselgenerierungs-Debakel absichtlich war und die schwachen Schlüssel von den Behörden oder Regierungen entdeckt und geheim gehalten wurden, um ihre Gegner auszunutzen.

    Man muss keinen traditionellen MITM-Angriff durchführen, _wenn man den Flughafen besitzt_ oder _das kostenlose öffentliche WLAN besitzt_. Der Verkehr kann im Klartext abgegriffen werden, und wir müssen uns mit der _entfernten Möglichkeit_ abfinden, dass das über anderthalb Jahre lang so lief. Wenn nicht so lange, dann sicherlich in den letzten 10 Tagen.

  6. kryptiskt

    Ich sage das nicht sarkastisch: Apple sollte Windows Update kopieren. Ich habe keine Ahnung, wie sie es so weit gebracht haben, ohne eine Methode, kleine Patches außerhalb monolithischer OS-Updates hinzuzufügen.

  7. commandlinefan

    Es scheint, als hätten wir alle einfach ... die Zertifikatssperrung aufgegeben? CRLs und OCSP wurden genau für so etwas entwickelt, aber beide scheinen als undurchführbar aufgegeben worden zu sein, ohne Ersatz.

  8. gringofyx

    Eine flache cert.pem-Datei (oder ähnliches) kann nicht sagen: „Vertraue dieser Intermediate nicht“.

    macOS hat bereits den nötigen Verifier (den Security.framework/trustd-Pfad, der Safari geschützt hat). Es wäre gut, wenn MacOS CLIs durch diesen leiten würde.

  9. kd913

    Sie haben gerade erst vor ein paar Tagen MacOS 27.2 veröffentlicht? Wie und warum haben sie nicht zumindest dann einen Patch gemacht?

  10. mFixman

    Frage an Leute, die sich damit auskennen: Warum haben wir Hunderte von Root-Zertifizierungsstellen, wenn eine Schwachstelle bei einer einzigen die Verschlüsselung brechen kann?

    Wäre es nicht sinnvoller, etwa 5 zu haben, die genauer überwacht werden können, sodass so etwas wie die eMudhra-Zertifikate wahrscheinlich entdeckt würden, bevor die Zertifikate eingesetzt werden?

Mehr von diesem Tag

2026-10-28