Firefox: ungepatchte 17 Jahre alte Sicherheitslücke

Wie uns die TheHackerNews heute mitteilen, gibt es im Firefox eine ungepatche Sicherheitslücke, die streng genommen, seit 17 Jahren im Firefox schlummert.

Same-Origin-Policy versagt

Die Same-Origin-Policy versagt bei Zugriffen auf „file://“ URLs. Was andere Browser schon vor Jahren behoben haben, ist für die Firefox Entwickler nicht wichtig, da es bislang keinen Exploit dafür gab. Das hat sich geändert:

Was wir hier sehen, wenn das Bild denn scharf wird (runterladen per youtube-dl hilft dabei), ist folgendes:

Eine Email mit einem HTML Attachment wird in einem Webmail geöffnet.
Die HTML Datei wird von Firefox abgespeichert, wie man sieht im HOME des Users!
Die HTML Datei wird mit Firefox über file://…  geöffnet und ..
präsentiert uns den Inhalt des Verzeichnisses.

Die HTML Seite enthält Javascriptcode, der über die File und Fetch Api vom Browser das Verzeichnis und die Dateien ausliest und dann mit AJAX die Daten exfiltriert.

Ein Patch dafür ist nicht in Arbeit, da Mozilla die Lücke nicht als solche anerkennt. Mal sehen ob sich das jetzt ändert 😉

Quelle: https://thehackernews.com/2019/07/firefox-same-origin-policy-hacking.html

Firefox – Bugs auf die lange Bank geschoben

Wer weiß noch, was er vor 11 Jahren gemacht hat? Bugtracker z.B. wissen es, sollten sich aber nicht 11 Jahre zurück erinnern müssen. Im Fall des Firefox-Bugs #435013 weiß ich dies auch und der Bugreport befindet sich in guter Gesellschaft 😉

Uralte Bugreports auf die lange Bank geschoben

Ein bisschen stolz darf man bei den Firefox Devs ruhig sein, ihr Produkt gibt es schon min. 11 Jahre, denn genau solange  ist der Bug #425013 bereits offen. Dabei handelt sich um eine echt knifflige Sache, nämlich die Frage: „Wann darf ein Computerprogramm es besser wissen, als der Mensch der es bedient?

In dem obigen Bugreport geht um einen technisch gesehen einfache Sache: Wenn jemand ein SSL-Zertifikat ausstellt, dann bekommt dies eine Seriennummer. Keine zwei SSL-Zertifikate des gleichen Ausstellers sollten die gleiche Seriennummer haben. Sagt die Theorie.

Die Praxis

In der Praxis kann man sich immer noch selbst Zertifikate ausstellen, und wenn man das macht, fängt das Programm, das dies für einen durchführt, bei  Eins an zu zählen. Das sind die Selbst-Signierten-SSL-Zertifikate. Die kann man ganz leicht mit OpenSSL selbst erstellen. Dauert keine zehn Sekunden.

Jetzt stellen wir uns mal vor, daß zehn Leute  Ihrem OpenSSL-Befehl sagen, mach mir ein Zertifikat für „localhost“ oder 127.0.0.1. Dann geht das jeweilige OpenSSL-Tool „openssl“ hin und macht das. Bei jedem der Zertifikate, die sich ja auf zehn verschiedenen Computern befinden, schreibt OpenSSL als Seriennummer eine Eins rein, denn auf dem jeweiligen Computer ist es das erste Zertifikat, das dort erstellt wurde.So weit, so gut.

Diesen Vorgang kann man auch automatisch durchführen. Wenn man ein Softwareprodukt verteilt, welches ein SSL-Zertifikat braucht, kann dies beim Start eines automatisch erstellen. Prima. Wir haben Verschlüsselung, den privaten Schlüssel des Zertifikates gibt es nur auf dem einem Produkt, nennen wir das mal spaßeshalber „IPMI-Modul“ und damit ist die Verbindung für die dies Zertifikat benutzt wird sicher.Genial, oder?

Die Sache mit dem Erfolg

Mal sehen. So ein „IPMI“ Modul verkauft sich, weil es für Server benutzt wird, recht gut. Es wird zig tausendmal verkauft. Bei zigtausend Servern wird beim ersten Start so ein SSL-Zertifikat mit der Seriennummer Eins (in Zahlen „1“) erzeugt und wenn man sich dahin als Käufer verbindet ist alles gut. Jetzt soll es vorkommen, daß Käufer, die dies Produkt gut fanden, gleich noch eins kaufen, ..oder zwei, …drei, .. hundertneunzehn oder tausende (Hostingunternehmen z.B.).

Auf jedem der Server wird ein Zertifikat mit der Seriennummer Eins erzeugt, aber keins der Zertifikate hat den gleichen Schlüssel drin, ergo nicht die gleichen Checksummen wie die anderen Zertifikate der anderen Server. Jetzt kommt wieder Firefox-Bug #435013 ins Spiel. Wenn man aus so einem Haufen von Servern auf das erste IPMI-Modul per HTTPS zugreift, das liegt daran, daß es Remote-Adminpanels sind, die als Webseiten recht praktisch zu benutzen sind, dann ist die Welt noch in Ordnung.

Will man jetzt aber nach dem ersten Server auch den zweiten Server so besuchen, meckert FireFox, daß es da vom selben Aussteller ( vermutlich die Default-CA von OpenSSL ) bereits ein Zertifikat mit der Seriennummer und dem Hostnamen ( der ist auch immer gleich ) gibt und man ja jetzt einer Fälschung aufgesessen wäre. Bei „normalen“ SSL-Zertifikatsproblemen, wie abgelaufenen Gültigkeitsdaten, kommt  jetzt eine Nachfragemöglichkeit, ob man das ausgelaufene Zertifikat trotzdem benutzen will. Per Definition geht es bei den meisten SSL-Zertifikaten um Verschlüsselung der Datenübertragung. Bei WebShops geht auch schon einmal um Authentifizierung, also den Beweis, daß man der ist, der man vorgibt zu sein.

Jetzt ist ein zeitlich ausgelaufenes Zertifikat im Bezug auf Verschlüsselung nicht so schlimm (kann auch schlimm sein, aber bei Otto-Normal-Webseiten eher nicht), weil der Schlüssel wird ja nicht dadurch schlechter oder „ungeheim“, nur weil in dem Zertifikat das Datum von Vorgestern drinsteht.

Bei Seriennummern ist das anders…

Bei Seriennummern ist das anders, weil eine Seriennummerkollision wie oben beschrieben der Versuch sein kann, ein anderes Zertifikat so geschickt nachzuahmen, daß ein Man-in-the-Middle-Angriff auf den Webseitenbesucher nicht bemerkt würde. Beim MITM-Angriff setzt sich der Angreifer zwischen Besucher und Webseite und simuliert beiden Seiten, daß er jeweils der Andere wäre, um so an die verschlüsselten Daten zu kommen, da er den Endpunkt der jeweiligen Kommunikation darstellt.

Das kann nur funktionieren, wenn das Zertifikat, daß der Angreifer präsentiert, vom Browser als das alte, bereits bekannte, Zertifikat eingestuft wird und daher muß es min. die gleiche Seriennummer haben. Ergo, findet man zwei gleiche Seriennummern in Zertifikaten, die den gleichen Namen und Aussteller haben, aber einen anderen Inhalt (Public-Key), so kann es sich nur um eine Fälschung handeln. Das ist Browserlogik und an sich stimmt das auch so. Es ist also Zeit Alarm zuschlagen und dem Benutzer mitzuteilen, daß da was ganz böse im Argen ist und das macht Firefox auch.

Nicht alles was rot blinkt, ist ein Atomsprengkopf im Anflug

Das Problem im Falle der zwei+X IMPIs ist nun, daß es kein Angriff ist, sondern eine Folge der oben beschriebenen Umstände, daß die Zertifikate automatisch erstellt wurden und mangels Vorgänger, die Seriennummer Eins haben. Das kann der Browser nicht wissen, aber der Admin vor dem Monitor schon, und der erwartet von FireFox, daß er das als Mensch besser wissen darf und einen „Mach trotzdem“-Button zur Verfügung bekommt. Bekommt er aber nicht.

„Früher“(tm), als alles noch besser war ;), gab es den Button, der flog dann aber raus, weil die Masse der Menschen nun einmal kein Admin ist und Dumm&Unerfahren noch dazu. Die Mozilla-Entwickler haben entschieden, die „Mach Trotzdem“-Button zu entfernen, weil 99,5% oder mehr Prozent der Nutzer in dem Fall nicht wüßten, wann Sie den Button nicht benutzen dürfen. Kann man verstehen die Überlegung. Wieso es dann aber keine Konfigurationseinstellung gibt, die es Experten erlaubt, trotzdem einen „Mach Trotzdem“-Button zu bekommen, ist Inhalt des Firefox-Bugs #435013 .

Wenn das schon…

… solange eine getroffene Entscheidung der Devs ist, wieso gibt es dann den Bugreport noch? Jetzt könnten böse Zungen schreiben, daß dies ja die übliche Masche ist bei Mozilla, unangenehme Dinge aus zu sitzen. Dafür ist die Beweislage dann doch etwas dünn 🙂 Ja dünn, weil Indizien sind ja da sehr wohl vorhanden, wie man hier sieht:

https://bugzilla.mozilla.org/show_bug.cgi?id=479520

Das ist der berüchtigte Bugreport zu IDNA2008, den Internationalen Domainnamen und dem Kampf der deutschen Benutzer von Firefox um das ß im Domainnamen. Da ich bei der Argumentation nicht ganz unbeteiligt war, an dieser Stelle schöne Grüße an die Kollegen von DENIC, weiß ich auch noch, wie lange und vor allem zäh dieser Bugreport behandelt wurde. Die Teergruben in Los Angeles sind ein Witz dagegen 🙂 Dabei war die Sachlage eigentlich ganz einfach, ß wurde beim Original IDNA  ausgespart, weil es ein Sonderfall war, denn es gab damals kein großes ß im Deutschen Zeichenvorrat. Im ersten IDNA Regelwerk war dann auch der Sonderweg ß -> ss   vorgesehen, was im Nachhinein wirklich keine gute Idee war. Straße.de und Strasse.de waren damit gleich, was aber nicht geht, weil Domainnamen keine Aliase haben können.

Naja, langer Rede kurze Pointe, mit genug Druck haben wir es geschafft und vor drei Jahren hat Firefox endlich die Regel ß -> ss durch die korrekte IDNA2008 Punycodeumwandlung des Strings ersetzt. Seit dem Tag kann man endlich die Straße.de aufrufen 😀

Über die Gründe, warum der Bugreport zu dem Seriennummernproblem so lange offen bleibt, wo doch eine Entscheidung getroffen wurde, kann man nur spekulieren. Ich denke, dies liegt daran, daß Chrome das nicht macht. Bei Chrome kann man auf dem „Machs doch“ Button klicken, weil einer da ist. Damit hat man argumentativ schlechte Karten, wenn das große Google das anders als das viel kleinere Mozilla macht. Also schieben wir es als „Wir denken dran“ auf die Bank und irgendwann wird sich das von selbst erledigen. Persönlich glaube ich ja, daß es das nicht wird.

Wie kam ich jetzt eigentlich darauf?

Weil ich ja auch im CC stehe, bekomme ich alle Kommentare zugemailt, die es zu dem Fall gibt, und heute kam der hier rein:

Comment # 208 on Bug 435013 from at 2019-06-10 12:46:51 PDT

Problem still exists. Is there a bug associated with „devs are using the browser to try to improve the world of security, exception would hinder that. User attempts to justify unique situation, devs in denial that such a situation warrants a change.“ ???

#egotistical, #broken, #savetheworld, #thanksmom, #papersplease

I don’t have a war on hackers or viruses anymore. The new battleground features users and devs, with the devs costing us all way more lost time than viruses or hacking ever has, and I’ve been using computers since my commodore 64. If the devs don’t care, then I do know ways to make them care. Or at least see that they can’t win at this.

Wer es nicht verstanden oder gesehen hat, ich übersetze mal den Satz:

Wenn die Entwickler sich nicht kümmern, dann habe ich Wege, daß sie es doch tun, oder wenigsten merken, daß sie den Kampf nicht gewinnen können.

Das drückt den Benutzerstandpunkt eigentlich ganz gut aus, weil auch ich sehe es so, daß der Button wieder her muß, weil FF sonst unbenutzbar ist in diesem speziellen Fall. Für Admins kommt sowas nämlich überproportional oft vor und ist damit echt nervig. Ich würde ja genau wie #209 den Mittelweg wählen und einfach eine about:config Option einbauen, aber  auf mich hört ja keiner 🙁 (beim ersten mal 😀 )

Wir dürfen gespannt sein, wie lange der Bugreport noch offenbleibt. Möglicherweise ja bis Mozilla den AskFedora pullt und alle alten Bugs beim Wechsel zu einem neuen System, auf dem alten System läßt 🙂

FireFox: Das NetFlix-Linux-FullHD-Paradox

Was muß ich da lesen, Firefox würde unter Linux keine NetFlix HD Streams anzeigen? Ja, wenn man das so macht wie Heise.de dann geht das auch nicht 🙂

Wie man FULL HD 1080p in FireFox mit Linux ansieht

Bestimmt habt Ihr Euch mehr darunter vorgestellt, als jetzt wirklich nötig ist. Zwei Dinge müssen zusammenkommen, damit  Ihr FullHD mit NetFlix genießen könnt:

1. Ihr braucht das Netflix HD Addon für FireFox

2. und Ihr braucht einen Film, der auch wirklich FullHD ist.
( 3. und einen FireFox der die Addons aktiviert hat 😉 )

Wie bekommt man jetzt die Statistikansicht ?

Nicht so wie Heise das sagt, die STRG+SHIFT+ALT+D ist veraltet, für Linux braucht Ihre STRG+SHIFT+ALT+Q und schon klappt es mit den Filmstats von NetFlix 😉Scene aus NetFlix: Star Trek Discovery mit StatistikenWichtig ist, daß bei DFR ( unten ) 1080p steht, weil NetFlix, logischerweise, das Bild auf die FullHD vom Monitor hoch skaliert und das teilweise sehr gut aussieht, so daß man gar nicht merkt, daß es nicht FullHD ist.

Beispiel:

Last Action Hero z.b. ist nur „853×480“ aber wenn man das nicht anders gewohnt ist, merkt man das nicht sooooofort. Naja 😉 An einigen Stellen merkt man eher den Digitalmatsch des schlechten Codecs an, als die mangelnde Auflösung 🙂

Sobald Ihr einen echten FullHD Streifen vor Euch habt, mehrt ihr das sofort 😀

Firefox Addon Bug geht in Runde 2

Oh ja, Ihr dachtet es wäre vorbei? Der Zertifikatbug bei Mozilla wäre behoben? Weit gefehlt! Muahahar

Gegen 23:10 Uhr MESZ: Rückspiel

kam der Gegenschlag. Mozilla hat seit einigen Stunden signalisiert, daß das Problem behoben wäre. Mozillas Automatismus sollte das Problem genauso leicht beheben, wie es verursacht wurde.

Leider flogen gerade (23:10 Uhr) alle Plugins wieder in den Legacy Modus und liessen sich nur durch das Aktivieren und erneute Deaktivieren des KeySignings wieder zum Laufen bringen!

Also erneuerte Anleitung:

In der about:config einfach die Signaturenprüfung wieder anschalten:
xpinstall.signatures.required = true

und wieder abschalten:
xpinstall.signatures.required = false

Der FireFox braucht nicht neugestartet zu werden, aber die einzelnen Tabs müssen ggf. neu geladen werden.

1.Update: 5.5.2019

FireFox für Android schaltet alle Addons in den Legacy-Modus um, auch hier hilft wieder der Workaround von oben. Spannend daran ist, daß FireFox das erst beim Zweiten Start heute morgen gemacht hat. Aus Entwicklersicht ist das etwas merkwürdig.

2.Update: 6.5.2019

Seit gestern kursiert die FireFox Version 66.0.4 durch die Medien, diese soll das Problem jetzt endgültig lösen.

3.Update: 6.5.2019 15:00 Uhr

Ganz frisch aus dem Build Ofen von Fedora, FireFox 66.0.4-1 FC28 … geht!

Download:

Fedora 28: https://koji.fedoraproject.org/koji/taskinfo?taskID=34672367
Fedora 29: https://koji.fedoraproject.org/koji/taskinfo?taskID=34672363
Fedora 30: https://koji.fedoraproject.org/koji/taskinfo?taskID=34672350

Firefox Bug schaltet Plugins ab

3.UPDATE zum aktuellen Firefox-AddOn-Signing-Problem

\o/ Der Workaround aus Update 1 lässt auch Neuinstallationen wieder zu:

Armagadd-on-2.0 abgewendet 😀

2.UPDATE zum aktuellen Firefox-AddOn-Signing-Problem

Der Discourse Server von Mozilla mit den Infos zum aktuellen Firefoxproblem ist immer noch down bzw. überlastet, aber der Bugtracker ist erreichbar. Da könnt Ihr entnehmen, wenn es wieder „normal“ geht.

Und ich habe gestern, oder wars schon vorgestern, noch über den Umzug von AskFedora zum eigenen Discourseserver erzählt. Soooo belastbar scheinen die nicht zu sein, denn Mozilla kann sich bestimmt einen Cluster davon leisten 😉

1.UPDATE

Man kann doch was machen. In der about:config einfach mal die Signaturenprüfung abschalten:

xpinstall.signatures.required = false

und Firefox neustarten. Im Anschluß sind die Plugins wieder da. Voilà.

Hauptmeldung

Na, heute Morgen auch beim Start von Firefox die Meldung bekommen, daß einige oder alle Plugins nicht mehr zur Verfügung stehen ? Man könnte ihn den Quantum-Bug nennen 🙂

„One or more installed add-ons cannot be verified and have been disabled“

Was ist passiert? Ein Zertifikat für die Plugin und Extentionverwaltung ist abgelaufen und hat damit alle Plugins/Extentions effektiv als Legacy gekennzeichnet. Wer jetzt hofft, daß ein einfach Neuinstallieren der Addons hilft, weit gefehlt. Das führt nur zu weiteren Fehlern.

Wer auf dem Laufenden bleiben will bekommt … „429 Too Many Requests“. genau, die Mozilla Webseiten werden grade mit Anfragen geflutet! \o/ Das Internet im Partymodus!!! Verzweiflung macht sich breit! Die Familienadmins bekommen Anrufe von Leuten, die Sie nicht mal an Weihnachten zu Gesicht bekommen! Wenn Mozilla Mist macht, dann merkt man das richtig!

Mozilla arbeitet an einem Fix, aber bis der verteilt ist, kann es noch eine Weile dauern. Siehe unten.

Impakt

NoScript abgeschaltet! Hacker & Tracker freut Euch! NoScript UMatrix und alle anderen Schutzaddons sind tod!

Was könnt Ihr tun?

Nichts! Laßt es einfach. Das ist von Mozilla verursacht worden, ergo wird es auch dort gelöst.

Infos

Bugtracker: https://bugzilla.mozilla.org/show_bug.cgi?id=1548973
Mozilla Forum: https://discourse.mozilla.org/t/certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047