Apples curl-Sicherheitsvorfall 12604

Apples curl-Sicherheitsvorfall 12604

• Am 28. Dezember 2023 wurde im curl-Issue-Tracker der Bug-Report 12604 eingereicht.
• Der Titel des Problems lautete "flag –cacert behavior isn’t consistent between macOS and Linux" und wies darauf hin, dass sich das --cacert-Flag unter macOS und Linux nicht konsistent verhält.
• Der Reporter zeigte, dass die mit macOS gebündelte curl-Version sich anders verhält als ein curl-Binary, das vollständig aus Open Source gebaut wurde.

Apples Version prüft den System-CA-Speicher als Zweites

• Die Kommandozeilenoption --cacert bietet Nutzern eine Möglichkeit, curl anzuweisen, nur einem bestimmten Satz von CA-Zertifikaten zu vertrauen.
• Unter macOS scheint die von Apple bereitgestellte curl-Version den System-CA-Speicher als zweiten Schritt zu prüfen, wenn die Verifikation mit dem bereitgestellten Satz von CA-Zertifikaten fehlschlägt.
• Das ist nicht dokumentiert und für Nutzer ein unerwartetes Verhalten.

Das ist ein Sicherheitsproblem

• Wenn ein Nutzer die Prüfung mit einer von ihm angegebenen CA-Zertifikatsdatei ausführt und sich im System-CA-Speicher ein Zertifikat befindet, das den Server verifizieren kann, schlägt die Prüfung nicht fehl.
• Dadurch entsteht ein Sicherheitsproblem, bei dem Zertifikatsprüfungen erfolgreich sind, obwohl sie nicht erfolgreich sein sollten.

Apple sagt, es gebe kein Problem

• Am 8. März 2024 antwortete Apple Product Security, dass die OpenSSL-Version (LibreSSL) absichtlich den eingebauten System-Trust-Store als Standard-Vertrauensquelle verwendet.
• Da das Serverzertifikat mithilfe des eingebauten System-Trust-Stores erfolgreich verifiziert werden könne, sehe man darin kein Problem.

Ich bin anderer Meinung

• Durch diese undokumentierte Funktion ist die CA-Zertifikatsverifikation mit curl unter macOS nicht vollständig verlässlich und entspricht nicht der Dokumentation.
• Das kann Nutzer verwirren.
• Für dieses Problem wird keine CVE vergeben, da es sich nicht um eine Sicherheitslücke in der curl-Version handelt, die wir ausliefern.
• Das Problem liegt streng genommen nicht im curl-Code, sondern in der LibreSSL-Version, die Apple bereitstellt und für den curl-Build verwendet.

Meinung von GN⁺

• Dieser Vorfall unterstreicht, wie wichtig Sicherheit und Verlässlichkeit von Software sind. Wenn Nutzer nur explizit vertrauenswürdige CA-Zertifikate verwenden möchten, kann es erhebliche Sicherheitsbedenken auslösen, wenn das System implizit andere Zertifikate akzeptiert.
• Apples Reaktion zeigt, dass es eine Lücke zwischen den von Unternehmen selbst definierten Sicherheitsstandards und den Erwartungen der Open-Source-Community gibt. Das kann eine Diskussion darüber anstoßen, wie Nutzer und Entwickler Sicherheit auf der jeweiligen Plattform wahrnehmen und handhaben sollten.
• Solche Probleme heben Abhängigkeits- und Integrationsprobleme hervor, die bei der Nutzung von Open-Source-Software auftreten können. Entwickler sollten sich dieser Unterschiede bewusst sein und angemessen darauf reagieren, wenn sie Bibliotheken und Tools verwenden, die auf einer bestimmten Plattform bereitgestellt werden.
• Andere Projekte mit ähnlicher Funktionalität sind OpenSSL oder GnuTLS; sie verfolgen jeweils eigene Sicherheitsphilosophien und Implementierungsansätze. Nutzer und Entwickler können diese Alternativen in Betracht ziehen.
• Bei der Einführung von Technologie sollten das Sicherheitsmodell der jeweiligen Technik und die plattformübergreifende Kompatibilität sorgfältig geprüft werden. Dieser Vorfall macht deutlich, dass Apples LibreSSL-Implementierung anders arbeitet als das Standardverhalten von curl, und unterstreicht damit die Bedeutung technologischer Entscheidungen.

[GN⁺]

Hacker-News-Kommentare

• Kritik an einer bestimmten „Funktion“ von Apple

  • Diese Funktion kann unnötige Berechnungen hinzufügen oder das erwartete Validierungsmodell aufbrechen.
  • Der Grund, warum ein Nutzer seine eigene CA bereitstellen möchte, kann sein, dass die CA nicht im OS-Bundle enthalten ist oder dass er gegenüber einer bestimmten CA validieren möchte.
  • Dieses Verhalten von Apple ist nicht das erwartete Ergebnis.

• Apples Richtlinien haben Vorrang, unabhängig von der Absicht des Besitzers eines Apple-Geräts

  • Dass Apples Richtlinien Vorrang haben und ignoriert wird, was der „Besitzer“ eines Apple-Geräts will, ist ein gewöhnliches Phänomen und nicht überraschend.

• Erläuterung zur Nutzung des CA-Speichers von libcurl

  • Wenn die Option CURLSSLOPT_NATIVE_CA gesetzt ist, verwendet libcurl den standardmäßigen CA-Speicher des Betriebssystems zur Zertifikatsvalidierung.
  • Wenn eine CA-Zertifikatsdatei oder ein Verzeichnis gesetzt wurde, werden diese zusammen mit dem standardmäßigen CA-Speicher durchsucht.
  • In Kombination mit der Option --cacert könnte libcurl versuchen, beide Einstellungen zu berücksichtigen, was darauf hindeutet, dass sie sich gegenseitig ausschließen könnten.

• Eine ähnliche Situation wie beim SQLite-F_BARRIERFSYNC-Vorfall

  • Apple scheint sich nicht dafür zu interessieren.

• Notwendige Korrektur von curl entsprechend Daniels Hinweis

  • Wenn Daniel auf ein Problem in curl hinweist, sollte Apple es beheben.

• Probleme in der curl-Dokumentation und ein Sicherheitsmangel in libcurl

  • curl implementiert nicht alle Protokolle direkt selbst, sondern unterstützt verschiedene Bibliotheken.
  • Der Nachteil dieses Ansatzes ist, dass sich ein konsistentes Verhalten zwischen unabhängigen Backends nur schwer garantieren lässt.
  • libressl ist keine vollständige Reimplementierung von openssl und ist nicht verpflichtet, dessen API vollständig nachzuahmen.
  • curl hat zwei Möglichkeiten: die Unterstützung für diese Bibliothek einzustellen oder das Problem zu dokumentieren.
  • Um zu vermeiden, dass Nutzer-Code kaputtgeht, sollte zumindest das Problem dokumentiert werden.
  • Der Ansatz von libressl ist aus Sicherheitssicht mangelhaft, und es könnte Gründe geben, eine CVE zu eröffnen.

• Misstrauen gegenüber in macOS enthaltener Software

  • Mit MacPorts werden die in macOS enthaltenen Tools (z. B. curl) überschrieben, da sie oft veraltet sind oder Probleme haben.

• Apples Standardverhalten könnte als Backdoor betrachtet werden

  • Es soll nicht behauptet werden, dass es absichtlich oder böswillig ist, aber es kann faktisch wie eine Backdoor wirken.
  • Dem Authentifizierungssystem eines Nutzers einen Schlüssel hinzuzufügen, kommt dem Hinzufügen einer Backdoor gleich.

• Kritik daran, dass Apple die Sicherheit der Nutzer nicht wichtig sei

  • Standardverhalten und alternatives Verhalten sind nicht dasselbe.
  • Es wird angedeutet, dass Apples Security-Team Probleme mit dem Leseverständnis haben könnte.