Safari ist nicht betroffen?

Die Frage hatte ich mir auch gestellt – und daraufhin den Original-Artikel gelesen. Da sticht dann noch dieser Satz ins Auge: Das impliziert natürlich nicht, dass Safari betroffen ist, denn man muss ja nur fixen, wenn man das Problem jemals hatte. Dennoch klingt es fast so, als seien alle Browser außer FF3.5 betroffen.

Wirklich schlauer bin ich nun auch nicht. Safari wird im Artikel halt nicht erwähnt.

g-kar:

Richtig gelesen, richtig verstanden.

Allerdings steht in diesem u.a. vom CVE referenzierten Artikel bei Wired u.a.:

und weiter:

Der aktuelle Firefox 3.5.x (dieser Tage steht abgesehen davon ein reguläres, weiteres Update auf 3.5.2 an) scheint also von diesem Problem als einziger Browser nicht betroffen zu sein, die Vorgängerlinie 3.0.x (die durchaus noch im Einsatz ist und in der nächsten Woche sowieso noch ein reguläres Update erfahren wird und danach nochmal eines für Anfang September geplant ist) dagegen wohl ja (an einem Patch für diese 3.0.x-Linie wird entweder schon gearbeitet, oder er ist schon fertig).

Bzgl. der Eingangsfrage und Safari kann nur spekuliert werden: es kommt drauf an, wie bei Safari die SSL-Implementierung ist. Das in MacOSX verwendete OpenSSL ist derzeit jedenfalls bei Version 0.9.7l (nachprüfbar mit 'openssl version' im Terminal), welches (ungepatcht) von diesem Problem betroffen ist (gefixt ist das Problem erst in Version 0.9.8 bzw. 0.9.8k, auf diese aktuelle stabile Version muss Apple (wie die meisten Unix- und Linux-Distributoren auch) sein OpenSSL also demnächst updaten oder um diesen aktuellen Patch erweitern -- oder gleich auf die Version 1.0 gehen, die derzeit noch im Beta3-Stadium ist, demnächst aber wohl released werden wird). Schaue ich mir die Sourcen von Apples derzeitiger OpenSSL-Version unter an, so kann ich bisher jedenfalls keinen solchen nachträglichen Patch entdecken, der das derzeitige Problem von OpenSSL behebt.

Und dann wären dann noch die GnuTLS- und die NSS-Bibliothek, welche verbreitete Schnittstellen-Bibliotheken zu OpenSSL sind und auf die viele Programme zugreifen, wenn sie SSL-Support bzw. sichere Verbindungen anbieten.

Der aktuelle Firefox 3.5.x ist nur deshalb nicht betroffen, weil er nach jetzigem Kenntnisstand als einziger Browser hier auf eine sehr aktuelle NSS-Bibliothek (Version 3.12.3 vom April 2009) setzt, und mit der NSS-Version das MD2-Zertifikatsproblem insofern gelöst ist, als der fragwürdige MD2-Support dort komplett deaktiviert ist.
Alle anderen Browser, Programme und Betriebssysteme, die von diesen beiden Bibliotheken und von OpenSSL frühere Versionen einsetzen, sind von dem Problem also weiterhin betroffen.

Ob und auf welche Weise Safari nun Gebrauch macht von einer evtl. diesbzgl. fehlerbehafteten NSS- oder GnuTLS-Bibliothek oder eine neuere oder eine ganz andere Version einsetzt, ist bisher (zumindest für mich) nirgends nachlesbar. Das OpenSSL von MacOSX ist auf jeden Fall von dem Problem betroffen, ob Safari mit seiner Schnittstellen-Bibliothek (die entweder eine neuere der Genannten oder eine völlig eigene ist) so gerüstet ist, trotzdem diese Schwachstelle in der derzeitig in MacOSX verwendeten OpenSSL-Grundlage zu übergehen, das weiß ich derzeit nicht.

Gehen wir mal sicherheitshalber vom Negativen aus (siehe auch das erste Zitat von Marlinspike: "almost everybody who has ever tried to implement SSL has made the same mistake") und lassen uns positiv überraschen, wenn irgendwann die Meldung kommt: "Safari definitiv ebenfalls (wie Firefox 3.5.x) nicht betroffen"...

siehe auch:
CVE-2009-2409
CVE-2009-2408
und
Red Hat Bug 510197
Red Hat Bug 510251

Ebenfalls dem Red Hat Dokument (Red Hat Bug 510197 ) zu entnehmen ist folgender (beruhigender?) Hinweis:

Letzteres sollte Apple wohl auch tun -- sowohl für sein verwendetes OpenSSL als auch für die Schnittstellen, die drauf zugreifen.