Firefox gibt Informationen preis

Zitat

Als Beispiele für Erweiterungen, die das Ausnutzen der Schwachstelle ermöglichen, nennen die Mozilla-Entwickler Download Statusbar und Greasemonkey. Der Entwickler von Download Statusbar hat inwischen ein aktualisiertes Paket bereitgestellt, das als .jar verpackt ist. Nutzer des Add-ons sollten die installierte Version rasch aktualisieren.

Wichtig scheint mir dies zu sein, da hier viele mit Greasemonkey arbeiten!
Gruß
Börsenfeger

In der Tat, das ist ein Problem. Ich verstehe nicht ganz, warum Webseiten überhaupt auf chrome://-URIs zugreifen dürfen. Was spricht dagegen, diese Verbindung völlig zu kappen?

NoScript ist zwar nicht primär dafür gedacht, tut aber genau dies, und ich kenne Seite, die deswegen nicht korrekt arbeitet.

Zitat von Holzwurm

http://www.heise.de/newsticker/meldung/102271

Update [1] hatte ich am 20080121.
[1] http://www.greasespot.net/

So dürfte man bei der Greasemonkey-Version 0.7.20080121.0 dieses Problem beseitigt haben!?? ... und bei Download Statusbar 0.9.5.3 (laut Heise) ohnehin.

Klingt zwar diesbezüglich einigermaßen beruhigend, aber der Heise-Artikel führt die beiden o.a. Add-ons nur als Beispiele an; bei wie vielen Add-ons sind die Versionen nicht als .jar verpackt? (wenn dies denn z.Z. die einzige Lösung zu sein scheint!?)

Zitat von PIGSgrame

In der Tat, das ist ein Problem. Ich verstehe nicht ganz, warum Webseiten überhaupt auf chrome://-URIs zugreifen dürfen. Was spricht dagegen, diese Verbindung völlig zu kappen?

... das frage ich mich allerdings auch.

Grüße - doubletrouble

Diese Sicherheitslücke soll im zeitnah erscheinenden Fx 2.0.0.12 [1] behoben sein. Die Schwere dieser Anfälligkeit wurde zwischenzeitlich bei Mozilla von niedrig auf hoch gestuft. Grundsätzlich ist der Firefox- Browser für diese Lücke nicht anfällig. Betroffen können Fx- Nutzer mit Verwendung div. Extension sein. Eine Liste ist in der angefügten Quelle verlinkt.

Als Workaround bis dahin wird die Deaktivierung der Extension und das Zurücksetzen auf Default- Theme empfohlen!

Quelle: http://blog.mozilla.com/security/2008/…raversal-issue/
[1] http://tinyurl.com/2szcey

Btw. wurde das Problem mit dem GM-Update für GM nicht gelöst. Die dort erwähnte Sicherheitslücke bezog sich auf eine GM-interne Schwachstelle.

Zitat von boardraider

Btw. wurde das Problem mit dem GM-Update für GM nicht gelöst. [...]

Korrekt!

http://greasemonkey.devjavu.com/changeset/651

Der Fix ist für GM bereits eingearbeitet und wird mit der nächsten Version wohl veröffentlicht. Gut möglich, dass die neue Version des Fx früher kommt.

Genau genommen verhinderte GM schon länger den Zugriff auf die eigenen Chrome-URLs, allerdings nicht im deaktivierten Status. Die Nennung von GM in dem Zusammenhang scheint eher der Tatsache geschuldet, dass der Code nicht in einer jar-Datei verpackt ist. Ich bezweifle, dass es wirklich mit GM getestet wurde.

"Mozilla-Entwickler korrigieren Risikoeinschätzung von Lücke", heißt es in einem aktuellen Heise-Artikel; demnach wird etwa um den 5. Feb. herum die finale Version 2.0.0.12 verfügbar sein.

Zudem ist im o.a. Artikel eine Liste von Add-ons verlinkt, die bei bugzilla veröffentlicht wurde, in denen offenbar die Schwachstelle eingebaut ist, da nicht in .jar verpackt wird.

Der Liste zufolge dürfte die aktuelle Greasemonkey-Version nicht mehr davon betroffen sein!? Zudem ist aber auch eine ältere Stylish-Version in der Liste enthalten. Nun stellt sich die Frage, ob sich die Liste auf die Add-ons an sich oder auf die Versionsnummern bezieht!?

Zudem geht meiner Meinung nach nicht klar aus dem Artikel hervor, inwiefern denn das kommende Fox-Update überhaupt an der Schwachstelle in den Add-ons was ändert, bzw. etwas daran ändern kann, dass diese sich auswirken!?

Grüße - doubletrouble

http://www.firefox-browser.de/forum/viewtopi…p=427958#427958

Zitat von doubletrouble

Nun stellt sich die Frage, ob sich die Liste auf die Add-ons an sich oder auf die Versionsnummern bezieht!?

Die Addons mit der jeweiligen Versionsnummer.

Zitat

Zudem geht meiner Meinung nach nicht klar aus dem Artikel hervor, inwiefern denn das kommende Fox-Update überhaupt an der Schwachstelle in den Add-ons was ändert, bzw. etwas daran ändern kann, dass diese sich auswirken!?

Die Schwachstelle ist im Fx-Code zu finden, nicht in den Addons. Dieser Fehler wird korrigiert, so dass solche Addons nicht mehr dazu ausnutzen lassen. Ein Update der Erweiterungen ist nach dem Fx-Fix nicht mehr notwendig.

Zitat

Dieser Fehler wird korrigiert, so dass solche Addons nicht mehr dazu ausnutzen lassen. Ein Update der Erweiterungen ist nach dem Fx-Fix nicht mehr notwendig.

Deswegen finde ich den Fuchs und seine Entwickler so toll. Problem erkannt, Gefahr gebannt!

Wenn wir gerade dabei sind:
http://www.hiredhacker.com/2008/01/19/fir…tory-traversal/

Dort wird darauf hingewiesen, dass NoScript an der Stelle davor schützen soll. Das wurde wohl von Giorgios hackademix-Blog übernommen. Er verweist auf das Update 1.1.6.15 von NoScript aus dem letzten August. Dort fand der Schalter noscript.forbidChromeScripts Einzug, der diese Schwachstelle patcht. Allerdings wird außer Acht gelassen, dass in der Folgeversion der Schalter wieder deaktiviert wurde. Ich habe es aktuell nicht damit getestet, aber ich würde nicht darauf wetten, dass NoScript wirklich davor schützt, wenn die Seiten auf der Whitelist stehen.

Was ich nochmal ansprechen möchte, weil es mich echt interessiert: Gibt es irgendeinen sinnvollen Grund, warum Webseiten auf Chrome-URIs zugreifen dürfen? Ich kann mir einfach keinen vorstellen, aber normalerweise ist man bei Mozilla doch sehr auf sicherheitsorientiertes Desgin bedacht. Wissen vielleicht die Erweiterungsentwickler hier mehr?

Remote-XUL
http://developer.mozilla.org/en/docs/Using_Remote_XUL

Hmmm... Ich habe mich noch nicht damit befasst, aber nach dem ersten Einlesen würde ich sagen: Braucht keiner, nutzt keiner, ist potentiell unsicher. Sowas kennt man doch eigentlich nur von Microsoft, zum Beispiel in Form von VBScript oder AFC.

XUL ist ja schön und gut, aber Idee, dass eine Website Applikationsmenüs rendern soll, finde ich nicht nur unnütz, sondern sie widerspricht in meinen Augen auch eklatant der üblichen Mozilla-Philosophie. Wenn man sowas (vielleicht für das lokale Intranet) explizit freigeben könnte, fände ich das ja in Ordnung, aber jeder Website standardmäßig(!) diese Möglichkeit einzuräumen, finde ich sehr unüberlegt.

Das wird mit Sicherheit genutzt, nur nicht in offenen Webseiten. Aber denk mal an Intranet-Anwendungen. Weshalb soll das "der" Mozilla-Philosophie widersprechen? Welcher Philosophie?

Auf die Idee mit dem Intranet bin ich selbst noch gekommen, wahrscheinlich hat sich mein Edit gerade mit deinem Post überschnitten. Wie (nachträglich) gesagt: Mit der Möglichkeit, diese Funktion per Whitelist freizugeben, wäre ich einverstanden, auch wenn mir in freier Wildbahn noch kein Anwendungsfall begegnet ist. Für ein Intranet-Portal scheinen mir diese Möglichkeiten wie geschaffen zu sein, aber eine offene Website hat nichts an meinem Browser zu verändern.

Und damit sind wir auch schon bei dem, was ich als "Mozilla-Philosophie" bezeichnet habe. Beispielsweise weigert man sich seit Jahren standhaft, die Möglichkeiten zum Einfärben der Scrollbars in Gekko zu integrieren. Viele Anwender wünschen sich dies, die meisten Browser unterstützen es inzwischen, obwohl es ursprünglich eine proprietäre Erweiterung von Microsoft war. Ich würde inzwischen sogar sagen, dass es sich um einen "Quasi-Standard" handelt, ähnlich wie robots.txt und favicon.ico.

Das Argument der Mozilla-Entwickler ist nun aber auch gar nicht, dass diese Möglichkeit nicht standardisiert ist, sondern man reitet immer wieder darauf herum, dass die Scrollleisten dem Anwender gehören und eine Website daran nichts zu verändern hat. Dies ist den Entwicklern scheinbar derart heilig, dass sie (anders als Opera) dem Anwender die Entscheidung, ob man das als Eingriff betrachtet, nicht überlassen möchten. (Die sehr lange Bugzilla-Diskussion dazu müsste ich heraussuchen, aber du kennst die Geschichte ja sicher.)

Auch die Tatsache, dass man alle Cookies nur als "Session Cookies" annehmen kann, dass man bestimmte JavaScript-Features entweder direkt oder per Policy blocken kann und dass man nach (zugegebenermaßen sinnloser) Diskussion wieder von <a ping=...> abgerückt ist, sind für mich Teil dessen, was ich "Mozilla-Philosophie" nenne: Dem Anwender bei größtmöglichem Komfort maximale Selbstbestimmung zu geben, notfalls lieber auf ersteres als auf letzteres zu verzichten.

Angesichts dieser Tatsache erscheint es mir einfach unverständlich, dass jede beliebige Seite einfach Menüs zu meinem Browser hinzufügen kann, ich dies (ohne NoScript!) weder per Whitelist noch per Blacklist steuern kann und dass man für solchen (wie ich finde) Unsinn in Kauf nimmt, dass man potentielle, inzwischen schon mehrmals reale, Sicherheitslöcher aufreißt. Ein vergleichbares Unverständnis bringe ich nur dem standardmäßig aktivierten(!) DOM Storage entgegen. Diese Idee ist aus meiner Sicht sicherheitsmäßig und auch was die Notwendigkeit anbelangt, ein Griff ins Klo gewesen.

Remote-XUL kann dir eine Anwendung innerhalb des Browsers schaffen. Eine Veränderung des Browsers selbst wird durch Sicherheitsbeschränkungen verhindert. Die Anmerkungen bzgl. der App-GUI beziehen sich nur auf Elemente innerhalb des Content Panes, also der Fläche der Webseite. Schau dir mal http://games.mozdev.org/xultris/play/xultris.xul an.