Firfox 3.0.8 Schedule: . Also Release Datum wird demnach wohl der 30.März oder 1.April sein.
Ein erster Build ist unter [url]ftp://ftp.mozilla.org/pub/firefox/nightly/3.0.8-candidates/[/url] bereits fertig. Erfahrungsgemäß kommt wohl in den nächsten Stunden oder Tagen noch ein Build2 hinzu. Und jener 2. Build wird dann am 30.03./01.04. als 3.0.8 veröffentlicht werden, bzw. er wird umetikettiert und dann ins Release-Verzeichnis kopiert.

Der Bug #485217 , um den es sich hier im übrigen in der Newsmeldung dreht, der scheint bereits gefixt (Status: RESOLVED FIXED) zu sein.

apple sollte von mozilla lernen und sobald bugs gefunden wurden diese auch so schnell wie möglich veröffentlichen !!!

mike_s:

Zustimmung.

mike_s & ssierkb
Ich bin dagegen die Schwachstellen zu veröffentlichen bevor sie einen Patch haben.
Ich würde es eher begrüßen wenn sie so schnell wie möglich eine Lösung vorlegen.

Lord_Kodak:

Selbstverständlich pflichte ich Dir da bei. Darum geht es bei dem geäußerten Wunsch aber nicht.

Genau darum geht es. Denn für so manche Sicherheitslücke existieren doch recht zeitnah Patches. Nur scheint sich Apple darauf verstiegen zu haben, hier immer erstmal wochen- und monatelang zu sammeln und dem Anwender gegenüber das Ganze dann gleich als Paket abliefern zu wollen, statt bestimmte Patches (vor allem sicherheitskritische) gleich und sofort zum Anwender durchzureichen, wenn ein Patch da und getestet ist. Dass Apple hier sehr lahm ist in dieser Praxis und der Anwender dann teilweise monatelang auf bestimmte kritische Patches warten darf, ist hinlänglich bekannt und wird von vielen Sicherheits-experten auch regelmäßig angemängelt.

Vor allem bei Sicherheits-Patches, die das Unix-Userland betreffen, also Programme und Bibliotheken, die identisch sind mit denen anderer Unix- und Linux-Distributoren, wird das besonders deutlich. Während andere Hersteller die der Allgemeinheit zur Verfügung stehenden Patches für ein- und dasselbe Programm schon längst zum Benutzer durchgereicht haben, passiert bei Apple erstmal lange Zeit nix an der Front.

Irgendwann, meistens kurz nachdem die Nutzerbasis, einschlägige Blogs und News-Seiten dann mal ungeduldig mit den Füßen gescharrt haben und so einen leichten Handlungsdruck bei Apple erzeugt haben, ja dann kommt auf einmal wenige Stunden oder Tage später das langersehnte Security-Fix-Paket, indem man sich dann endlich auch jenen Lücken widmet, die andere Unix- und Linux-Distributoren schon längst gefixt und diese Fixes zu den Nutzern weitergegeben hat.

In dieser Zeit haben Apple-Nutzer das Nachsehen und bleiben auf den bekannt gewordenen Sicherheitslücken sitzen bzw. können nur hoffen und beten, dass nicht irgendein Schadprogramm (die betreffenden Programmierer sind ja auch nicht blöd) genau diese Situation mal ausnutzt und genau dann in Richtung Macs zuschlägt, während die Mac-Anwender noch ohne Patch dastehen.

Und wie wir wissen, kann dieses Zeitfenster zuweilen mal Monate betragen. Genug Zeit und Anreiz für die Schadprogramm-Hersteller, es mal zu versuchen. Bei wachsender Verbreitung der Macs wohl erst recht.

Also das wäre keine gute Idee und das macht auch Mozilla normalerweise nicht so
Der Bug wurde ja gestern veröffentlicht - und nicht von Mozilla.
Normalerweise meldet man sowas zuerst dem Hersteller ... der hat dann Zeit ein Update zu erstellen .. und erst dann wird der auch veröffentlicht.

Und allgemein geht ja Mozilla sehr tranparent mit diesen Dingen um. Aber rein aus einem Marketingblickwinkel betrachtet, ist das zumindest auch keine wirklich gute Idee bzw. die Transparents wird ehr um Bumerang
Siehe auch:
http://blog.mozilla.com/security/2009/03/06/beware-the-security-metric/

Wohl auch ein Grund, warum sich Apple hierbei ehr bedeckt hält bzw. nichts zugeben, was nicht ohnehin bereits bekannt ist, ist die Devise
So machen es übrigens auch alle anderen .. bis auf Mozilla eben.

Aronnax:

Oder der Hersteller lässt sich, obwohl er rechtzeitig informiert ist, mit dem Fixen so viel Zeit (z.B. mehrere Monate), dass es langsam unverantwortlich würde, hier noch weiter den Mund zu halten. Dann kann ich denjenigen aber auch verstehen, der mit dem Bug bzw. mit näheren Informationen dazu an die Öffentlichkeit geht, erst recht, wenn es sich um einen sehr kritischen Bug handelt. Einfach, um den Handlungsdruck beim Hersteller zu erhöhen. Und sehr oft verlässt ja auch kurz nach so einer kleinen "Druckerhöhung" eigenartigerweise dann auch ein betreffender Patch das Hersteller-Labor.
So geschehen beim zuletzt gefundenen Safari-Bug von Brian Masterbrook.

Ist mir auch schon mehrmals aufgefallen: Apple scheint oft erst zu reagieren und wirklich in Wallung zu kommen, wenn der Handlungsdruck spürbar erhöht worden ist. Diese Binsenweisheit ist mir übrigens auch mal von einem Apple-Manager bei einer Entwickler-Veranstaltung unter 4 Augen mitgeteilt worden: wenn man was von Apple will bzw. will, dass Bug xyz oder Feature xyz endlich angepackt werden, dann muss man Apple ggf. nerven und denen auf die Füße treten, wenn's einem zu lange dauert. Erst dann passiert da spürbar was. Spürbar heißt vor allem: beim Anwender angekommen.

@sierkb
Es gibt ja sowas wie einen Verhaltenskodex hierbei.
Also erst den Hersteller etwas melden ... Wochen oder Monate dem Hersteller Zeit geben (kein Ahnung, was aktuell so üblich ist)
Und wenn der Hersteller dann noch kein Update herausgebracht hat, kann man den Bug .. ja sollte sogar unbedingt den Bug veröffentlichen, um eben Druck zu erzeugen.
Erfahrungsgemäß funktioniert es ja leider nicht anders, bei vielen Herstellern.

Allerdings, bei diesem Fall und diesem Hersteller hier, der ja bekanntlich so schnell reagiert, wie kein anderer. Keine Ahnung, warum der schon veröffentlicht wurde, aber eigentlich ist das ein Foulspiel bzw. ein nicht beachten, des üblichen Verhaltenskodex.

Aronnax:

Da gebe ich Dir recht. Im Fall dieses Firefox Bugs #485217 sieht das eigenartig aus: Mozilla darf von erfahren, dass da bereits ein Exploit existiert. Anstatt dass man Mozilla mit angemessenem Zeitfenster vorher über die Lücke informiert und dann erst nach angemessener Karenzzeit den Exploit öffentlich zugänglich macht.

Immerhin hat man seitens Mozilla schnell reagiert (innerhalb weniger Stunden) und den Bug gefixt.

Ob der angeplante Veröffentlichungstermin von FF 3.0.8 angesichts dieser Situation (eben weil ein Eploit bereits veröffentlicht und zum Download angeboten worden ist) evtl. sogar vorgezogen wird oder ist? Ich meine, mich erinnern zu können, dass FF 3.0.8 ursprüngl. für 14. April angedacht gewesen ist, dieser Termin zu Ende März also bereits schon der vorgezogene Termin ist. Immerhin ist ja FF 3.0.8 soweit fertig (habe mir vorhin den Build1 installiert), alle dafür anvisierten Bugs sind gefixt.

Um sich davor schützen zu können, wäre es nett, wenn man etwas mehr erfahren würde. Wie werden die Leute denn dazu gebracht, eine XML-Datei aufzurufen? Wenn ich keine XML-Datei aufrufe, kann mir also nichts passieren? Normalerweise rufe ich Dateien nicht aus dem Browser heraus auf. Was ist also los? Bitte mal konkret werden.

Einerseits,
man könnte es in jede Seite einbauen.
Deshalb ist der auch als kritisch eingestuft.

"Exploit code at the link iframes a little xml file with an xslt transform that causes a crash"

Anderseits,
man könnte dann Firefox gezielt zum Absturz bringen und währenddessen eigenen Code in den Arbeitsspeicher schreiben .. und ausführen.

Ansonsten,
die meisten Sicherheitsbugs sehen in etwa so aus:
Eine Methode gefunden den Browser absaufen zu lassen.
Erfahrungen mit älteren vergleichbaren Bugs haben gezeigt, dass es nun eventuell möglich sein könnte Code auszuführen.
Ob das wirklich geht ist aber noch offen .. bzw. genaues weiß man nicht .. Beispiele die demonstrieren das es geht, gibt es auch nicht.

Dieser hier gehört auch in diese Kategorie.
Oder anders gesagt:
Bis auf weiteres ist das alles eine theoretische Bedrohung und ob der jemals ausgenutzt wird, oder ob es über diesen Bug überhaupt jemals möglich sein wird, ist unbekannt.

Aronnax
Danke für die Antwort. Bei Firefox werden bei mir durch das No-Script-Add-on jegliche Skripts unterbunden, die ich nicht ausdrücklich erlaube. Das sollte einen doch schützen, oder? Vorsichtshalber bin ich jetzt jedenfalls mal vorübergehend zu Safari gewechselt.

Nöö,
ist zwar schon so, dass die meisten Sicherheitslöcher über JavaScript ausgenutzt werden. Aber hier wäre JS wohl nicht nötig und No-Script demzufolge nutzlos.

Bevor man das undenkliche tut, also Safari benutzen
In der Firefox 3.1 Beta 3 ist der Bug nicht drin. Sowieso sehr empfehlenswert

Oder eben ftp://ftp.mozilla.org/pub/firefox/nightly/3.0.8-candidates/


Und wie gesagt .. ist bisher alles theoretisch.

Hahaha. Okay, danke.

Aronnax

Okay, die Beta ist installiert und läuft. Ich habe gerade gesehen, dass du feine Themes für Firefox anbietest. Werde ich gleich mal testen.

erko:

XSLT ist eine XML-basierte Stylesheetsprache, um aus XML-Rohdaten andere Inhalte oder/und Dateien zu erzeugen bzw. diese durch Transformation der Rohdaten zu gewinnen. Das können PDfs sein, SVGs, RDF, RSS, XHTML, HTML, etc. Mehr dazu u.a. bei Wikipedia: .

Diese Transformation läuft meistens auf dem Server ab, kann aber auch im Client (also in diesem Fall im Browser ablaufen). Letzteres bedeutet in der Regel eine Entlastung des Servers. Deshalb haben moderne Browser neben ihrem SGML-Parser (zur Wiedergabe von HTML) nicht nur einem XML Parser (zur Wiedergabe für XML, wozu auch ordentlich ausgeliefertes XHTML gehört), sondern auch einen eigenen XSLT-Prozessor mit an Bord. Mit dieser Kombination lassen sich clientseitige Transformationen im Browser durchführen, ohne dass die Server davon belastet werden.

Wichtig für den Anwender ist dabei das Ergebnis, das dabei herauskommt. Denn i.d.R. bekommt der Anwender von derlei automatisch ablaufenden Transformationen nichts mit. Der Anwender sieht entweder nur eine generierte HTML-Seite oder bekommt ein generiertes PDF etc.
Auch die clientseitig eingesetzte Hardware ist inzwischen dazu geeignet, derlei Transformationen on-the-fly und direkt bei Aufruf durchzuführen.

Es ist die Entscheidung des Inhalte-Anbieters, ob derlei XSLT-Transformationen auf seinem Server stattfinden oder auf den Browser des aufrufenden Anwenders ausgelagert werden. In der Regel findet Ersteres statt, vor allem auch deswegen, weil man sich lange Zeit nicht sicher sein konnte, ob der eingesetzte Browser überhaupt umfänglich XSLT-fähig ist. Moderne Browser sind das inzwischen, aber schon bzgl. IE6 & Co. kann man das sicher vergessen.

Du kannst Dir angesichts solcher Informationen sicher leicht ausmalen, wie eine solche Sicherheitslücke bzgl. des XSLT-Prozessors im Browser ausgenutzt werden kann: Ein Klick auf einen entsprechende Web-Adresse, welche eine XML-basierte Webseite anbietet, die wiederum den XSLT-Prozessor des Browsers in Anspruch nimmt, genügt. Von außen nicht ohne Weiteres für den Laien vorher erkennbar, denn XML-Inhalte kann man im Browser so präsentieren wie der Anwender es von HTML gewohnt ist (und soll es auch können dürfen), bestes Beispiel: als XML mit dem empfohlenen Mimetype "application/xhtml+xml" ausgeliefertes XHTML, welches eine entsprechende Stylesheet-Anweisung mit "<xsl:stylesheet ..." in seinem Header hat und eine betreffende XSLT-Datei nachlädt, um den Inhalt im Browser zu transformieren. Gar nicht mal so unüblich. Statt der XHTML-Datei kann dies auch eine XML-Datei sein, die durch eine solche Transformation on-the-fly erst zu jenem HTML- oder XHTML-Inhalt wird, den der Anwender dann in seinem Browser zu Gesicht bekommt. Das geht normalerweise innerhalb weniger Sekundenbruchteilen und ist einer der bestechend tollen Eigenschaften von XML in Kombination mit XSLT.

Das potentielle Bedrohungs-Szenario dieses Firefox-Bugs ist also einigermaßen konkret, weil es da draußen im Netz mit Sicherheit so einige XML-Inhalte gibt, die die XSLT-Transformation nicht auf dem Server stattfinden lassen, sondern im Browser.
Ich bin jedenfalls schon so manches Mal auf solche Inhalte gestoßen, es gibt sie.

sierkb
Ja, Wahnsinn. Danke.
Da wäre es doch eingentlich klug, wenn man in den Einstellungen seines Browsers solche automatisierten Abläufe unterbinden könnte.

erko:

Wozu das? Damit der Browser dann nicht mehr das machen kann, wozu er eigentlich da ist? XSLT ist an und für sich keine gefährliche Technologie, sie ist wie alle anderen Markup-Sprachen auch, formell eine in XML-Syntax gekleidete Sprache mit Script-ähnlichen Möglichkeiten, um aus einem Markup-Dokument ein anderes Dokument erzeugen zu können (wiederum ein Markup-Dokument, wird XSL-FO benutzt, so können auch andere Objekte/Dokumente damit erzeugt werden). Die betreffende Syntax von XSL geht nicht über diese Belange hinaus. Folglich ist da eigentlich auch kein Sicherheitsrisiko.

Das Problem mit diesem konkreten Firefox-Bug ist ein Fehler in der Implementation des XSLT-Prozessors im Browser, der dazu führen kann, dass der Browser abstürzt bzw. diese Instabilität von einem entsprechend konstruierten Schadprogramm mutwillig erzeugt und abgefangen werden kann, um im Dunstkreis dieser Instabilität des Browsers seinen Schadcode einzuschleusen.
So ein Problem kann aber mit jeglicher im Browser verbauten Komponente/Technologie passieren, hier ist es eben der XSLT-Prozessor. Es könnte theoretisch aber auch den für HTML zuständigen SGML-Parser oder den XML-Parser treffen oder irgendeine andere Komponente. Die kann und soll der User nicht alle abstellen können, weil er dem Browser sonst wichtige Kernkomponenten wegnähme und ihn dann quasi unbenutzbar machen würde.