Apples curl-Sicherheitsvorfall 12604

• Das von Apple mit macOS gebündelte curl verarbeitet die Option --cacert anders als Open-Source-Builds und durchbricht damit die Erwartung bei der TLS-Prüfung, dass nur die vom Nutzer angegebenen CAs vertraut werden
• --cacert ist eine Option, die Serverzertifikate nur anhand der angegebenen CA-Zertifikatsmenge prüfen soll; schlägt die Prüfung fehl, muss curl einen Fehler zurückgeben
• Das von Apple bereitgestellte curl scheint bei fehlgeschlagener Prüfung mit der angegebenen CA zusätzlich noch den System-CA-Speicher zu prüfen; dieses Verhalten wurde nicht angefordert und ist nicht dokumentiert
• Apple Product Security antwortete, dass Apples OpenSSL, LibreSSL, absichtlich den eingebauten System-Vertrauensspeicher als Standard-Vertrauensquelle verwende und dies daher nicht als zu behebendes Problem gelte
• Da es sich nicht um eine Schwachstelle in den vom curl-Projekt verbreiteten Builds handelt, wurde keine CVE vergeben; die Ergebnisse der CA-Prüfung im mit macOS gebündelten curl können jedoch von der Dokumentation abweichen

---

Der Beginn von Issue 12604

• Am 28. Dezember 2023 wurde im curl-Issue-Tracker bugreport 12604 eingereicht
• Der Titel des Issues lautete „flag --cacert behavior isn’t consistent between macOS and Linux“, gemeldet von Yuedong Wu
• Selbst bei derselben curl-Version auf demselben macOS-Rechner unterschied sich das Verhalten zwischen dem von Apple gebündelten curl und einem aus dem Open Source gebauten curl-Binary

Welche Zusicherung --cacert erwarten lässt

• Die curl-Kommandozeilenoption --cacert ist die Methode, mit der curl bei nachfolgenden Übertragungen ausschließlich der exakt angegebenen CA-Zertifikatsmenge vertrauen soll
• Wenn ein TLS-Server kein Zertifikat vorlegt, das sich mit dieser Zertifikatsmenge verifizieren lässt, muss curl fehlschlagen und einen Fehler zurückgeben
• Diese Option wurde curl im Dezember 2000 hinzugefügt und dient dazu sicherzustellen, dass der Nutzer mit einem Server kommuniziert, den er kennt und dem er vertraut
• Letztlich berührt dies direkt die grundlegende Rolle, die TLS erfüllen soll

Das abweichende Verhalten des mit macOS gebündelten curl

• Das von Apple für macOS bereitgestellte curl scheint bei Verwendung von --cacert nach einer fehlgeschlagenen Prüfung mit der angegebenen CA-Zertifikatsmenge zusätzlich den System-CA-Speicher zu prüfen
• Diese Zusatzprüfung wurde vom Nutzer nicht angefordert und ist in der Dokumentation nicht beschrieben, wodurch sie schwer vorhersehbar ist
• Selbst wenn der Nutzer mit einer reduzierten, dedizierten CA-Zertifikatsdatei prüfen will, schlägt die Prüfung nicht fehl, sofern sich im System-CA-Speicher ein Zertifikat befindet, das den Server verifizieren kann
• Dadurch kann eine Zertifikatsprüfung erfolgreich sein, obwohl sie es nicht sein dürfte, was als Sicherheitsproblem angesehen wird

Die Antwort von Apple Product Security

• Am 29. Dezember 2023 um 08:30 UTC wurde eine Meldung zum Sicherheitsproblem per E-Mail an Apple Product Security gesendet
• Apple Product Security antwortete am 8. März 2024
• Apples Antwort lässt sich in zwei Punkten zusammenfassen
  • Apples OpenSSL, LibreSSL, verwendet absichtlich den eingebauten System-Vertrauensspeicher als Standard-Vertrauensquelle
  • Da das Serverzertifikat erfolgreich mit dem eingebauten System-Vertrauensspeicher verifiziert werden kann, betrachtet Apple dies nicht als ein Problem, das auf Apple-Plattformen behandelt werden müsse
• Apple schloss den Fall damit ab

Einschätzung des curl-Projekts und Auswirkungen auf Nutzer

• Diese nicht dokumentierte Funktion unter macOS führt dazu, dass die CA-Zertifikatsprüfung von curl nicht mit der Dokumentation übereinstimmt
• Nutzer erwarten, dass nur die per --cacert angegebene CA-Zertifikatsmenge verwendet wird, doch das von Apple bereitgestellte curl verhält sich anders
• Dieses Problem ist keine Sicherheitslücke in den vom curl-Projekt ausgelieferten curl-Versionen
  • Das curl-Projekt vergibt für dieses Problem keine CVE
  • Die Ursache liegt nicht im curl-Code selbst, sondern in der von Apple für die Plattform bereitgestellten und für den curl-Build verwendeten Version von LibreSSL
• Bei Verwendung des von Apple bereitgestellten curl unter macOS können die auf --cacert basierenden Prüfergebnisse von denen eines Open-Source-Builds von curl abweichen

[GN⁺]

Meinungen auf Hacker News

• Dieses Verhalten ist völlig unsinnig. Wenn ich selbst eine CA angebe, dann aus einem von zwei Gründen: Entweder ist meine CA nicht im Bundle des Betriebssystems enthalten, oder ich möchte nur gegen eine bestimmte CA prüfen.
  Das heißt, Apples „Feature“ fügt entweder unnötige Berechnungen hinzu oder bricht das erwartete Verifizierungsmodell. Beides ist kein wünschenswertes Ergebnis.

  • Kleine Korrektur: Auf den Apple-CA-Speicher wird erst zurückgegriffen, wenn die erste Prüfung fehlschlägt. Es dürfte also keine unnötige zusätzliche Berechnung stattfinden.
    Trotzdem stimme ich zu, dass es ein schlechtes Verhalten ist, weil es nicht das erwartete Ergebnis liefert. Da Apple normalerweise Änderungen bevorzugt, die die Abwärtskompatibilität brechen, und diese Funktion in curl hinzugefügt wurde, scheint es da noch Umstände zu geben, die Apple nicht offengelegt hat. Vielleicht wird es für Entwickler-Diagnosetools oder die AppStore-Prüfung verwendet.
  • Es heißt zwar, man solle nicht Böswilligkeit unterstellen, wenn Dummheit als Erklärung reicht, aber wenn ein böswilliger Akteur Hanlons Rasiermesser als Verteidigungsargument verwendet, sollte man besonders vorsichtig sein.

• Leider ist ein solches Verhalten, bei dem immer Apples Richtlinien Vorrang haben, egal was der „Eigentümer“ eines Apple-Geräts tun will, nicht überraschend und bei Apple stets zu erwarten.

  • Deshalb nutze ich kein Apple mehr. Die Geräte scheinen wirklich gut gebaut zu sein und das Betriebssystem ist auch ausgereift, aber dass sie einen in ihre eigene Art und ihr Ökosystem einsperren und sogar den Zugriff auf die eigene Hardware verhindern, passt nicht dazu, im HN-Sinne ein Hacker zu sein.
    Zumindest nicht in diesem Teil des digitalen Lebens, und angesichts des Preises ist es auch schwer, sich so ein Gerät einfach noch daneben zu stellen. Ich habe immer wieder darüber nachgedacht, Apple-Produkte auszuprobieren, zuletzt auch beim AR-Headset, aber bisher wirkten sie für Entwickler und Bastler viel zu feindselig.
  • Wenn du das Open-Source-curl ausführst, bekommst du das gewünschte Verhalten.
  • Leider gibt es immer Leute, die niedrige technische Entscheidungen überinterpretieren, um ihre eigenen Vorurteile zu „beweisen“.
    Zu glauben, ein Unternehmen von Apples Größe habe eine solche Entscheidung im Dienst einer größeren Vision getroffen, „die Geräte der Nutzer zu besitzen“, schreibt Apple ein enormes Maß an organisatorischer und koordinativer Fähigkeit zu. Ein Niveau, von dem ich nicht einmal in Organisationen gehört habe, die ein Zehntel so groß sind wie Apple. Aber es ist ja Apple, nicht wahr!?
  • Der Eigentümer ist Apple, du bist nur der Nutzer ;)

• Vielleicht setzt Apple genau das hier?[0] Hervorhebung von mir.
  CURLSSLOPT_NATIVE_CA
  Weist libcurl an, für die Zertifikatsprüfung den Standard-CA-Speicher des Betriebssystems zu verwenden. Wenn diese Option gesetzt ist und zusätzlich eine CA-Zertifikatsdatei oder ein Verzeichnis gesetzt wird, werden diese Zertifikate während der Prüfung zusammen mit dem Standard-CA-Speicher durchsucht.
  Wenn --cacert mit dieser Option kombiniert wird, scheint libcurl zu versuchen, beides zu respektieren. Sollten die beiden nicht gegenseitig exklusiv sein?

  • Nein, das ist hier nicht der Fall. Das curl-Binary weiß, wie es die libcurl-Bibliothek aufrufen muss.

• Das ist eine Backdoor.
  Ich sage nicht, dass es absichtlich oder böswillig ist. Aber faktisch ist es eine Backdoor. Wenn man anfängt, Schlüssel zum Authentifizierungssystem des Nutzers hinzuzufügen, hat man eine Backdoor hinzugefügt.

  • Das sieht exakt nach etwas aus, wozu die NSA große US-Tech-Unternehmen drängen würde.

• Das Standardverhalten ist zwar verdächtig, aber dieser Einschätzung stimme ich überhaupt nicht zu. Eigentlich ist das ein Dokumentationsproblem von curl.
  curl ist eine Multiprotokoll-Bibliothek und implementiert nicht alle Protokolle selbst, sondern verlässt sich in den meisten Fällen auf transitive Abhängigkeiten, also „Backends“, die die Low-Level-Bitinterpretation übernehmen. Einige Protokolle enthalten aus guten Gründen Unterstützung für mehrere alternative Bibliotheken.
  Der Nachteil dieses Ansatzes ist, dass es schwierig oder unmöglich ist, gemeinsames Verhalten zwischen unabhängigen Backends zu garantieren. Sie bieten möglicherweise nicht alle dieselben Funktionen, ihre APIs können unvollständig sein, oder sie bieten — wie hier — keine Möglichkeit, Teile des Standardverhaltens zu patchen. LibreSSL ist keine bitgenaue Neuimplementierung von OpenSSL und ist auch nicht verpflichtet, dessen API vollständig nachzuahmen.
  Wenn Upstream sich in solchen Fällen gegen eine Korrektur sträubt, bleiben curl zwei Optionen: die Unterstützung für diese Bibliothek aufgeben oder dieses Sonderverhalten dokumentieren. Ersteres könnte Nutzercode brechen, also sollte zumindest Letzteres passieren.
  Trotzdem stimme ich der grundsätzlichen Einschätzung zu, dass dies aus LibreSSL-Sicherheitssicht ein Mangel ist und es vermutlich einen Grund geben könnte, ein CVE zu eröffnen. Ziel sollte aber LibreSSL sein.

  • Wenn die eigentliche Ursache in der System-SSL-Bibliothek liegt, verstehe ich nicht ganz, wie das Bauen von curl aus dem Quellcode dieses Problem umgeht.

• Das erinnert an die F_BARRIERFSYNC-Sache bei SQLite.
  Es ist ihnen einfach egal.
  https://bonsaidb.io/blog/acid-on-apple/

  • Das erinnert mich an eine frühere Sache, bei der Apple eines der alten Unix-Tools, die sie tatsächlich mitliefern, durch das schlampige Hineinpfuschen irgendeiner Option kaputtgemacht hat.
    Ihre Wartungshaltung liegt ungefähr zwei Stufen unter der des Debian-Menschen, der OpenSSL kaputtgemacht hat.

• Wenn Daniel sagt, dass euer curl kaputt ist, dann repariert es, Apple. So einfach ist das.

  • Auch Daniel kann falschliegen. Sogar bei curl.
    In diesem Fall scheint er nach zwei Minuten Nachprüfen wahrscheinlich recht zu haben, aber „weil es Daniel ist, stimmt es“ ist die schlechteste Begründung.
    Das erinnert an die alte Diskussion über die Geschichte von C, insbesondere Eric S. Raymonds „Beiträge“: https://scienceblogs.com/deltoid/2011/10/14/dennis-ritchie-h...

• Danke für die Warnung. Zur Info: Ich ersetze auf macOS viele der mitgelieferten Tools durch MacPorts. curl gehört dazu.
  Die gebündelten Tools sind meist veraltet oder auf andere Weise kaputt. Das Vertrauen in von Apple gebündelte Software habe ich schon vor langer Zeit verloren.

• Ich frage mich, ob Apple sich bei irgendetwas Wichtigem auf dieses Verhalten verlässt.

  • Ich weiß nicht, ob das sarkastisch gemeint ist, aber das ist eindeutig sehr wichtig.
    Es ist völlig vernünftig, dass jemand ein Skript schreibt, das nur eine interne private CA verwendet. Wenn man diesen Befehl ausführt, weiß man, dass er nur mit internen Unternehmensressourcen spricht, weil es eine interne Unternehmens-CA ist.
    Apple fügt hier jedoch eine Backdoor hinzu, die so groß ist wie die Domainvalidierung.
    Darüber hinaus ist es auch völlig legitim, einen Dummy-Namen zu verwenden und allein anhand der Tatsache, dass die Unternehmens-CA signiert hat, zu bestätigen, dass man mit einem Unternehmensserver verbunden ist. Apple bricht diese sehr vernünftige Annahme und erzeugt damit eine Sicherheitslücke. Nicht gut.
  • Es könnte dazu dienen, TLS-Intercepting durch Unternehmen und Behörden zu erleichtern.
  • Es ist entweder extrem dumm oder böse.

• So viel also dazu, dass Apple sich um die Sicherheit der Nutzer kümmert.