Thema: Firefox ...

[SiLæncer]

Die Mozilla-Entwickler haben ein bekanntes Loch im Passwort Manager von Firefox & Co gestopft – und doch ein Tor für Missbrauch offen gelassen. Der eingebaute Passwort Manager des Open Source Browsers speichert auf Wunsch des Benutzers Passwörter und füllt die entsprechenden Formularfelder beim nächsten Besuch dann automatisch aus. Dies geschieht nicht nur auf der Seite, auf der man das Passwort gespeichert hat, sondern auch auf jeder anderen Seite auf diesem Server, die ein ähnliches Formular enthält.

Dürfen Anwender auf einem Server eigene Webseiten erstellen, wie das beispielsweise bei vielen Community-Sites der Fall ist, kann ein Angreifer das Login-Formular nachbauen und sich die automatisch eingesetzten Zugangsdaten auf seinen eigenen Server schicken lassen. Dazu konnte er früher ein Login-Formular sogar so gestalten, dass es die Daten beim Klick auf "Anmelden" direkt auf seinen eigenen Server überträgt. Trotzdem setzte Firefox die Daten automatisch ein. Das haben die Entwickler mittlerweile geändert. Sie überprüfen jetzt das Ziel der Übertragung, mit dem Resultat, dass die Demo von heise Security nicht mehr funktionierte. Einem Leser fiel jedoch auf, dass man das Ziel der Formularübertragung gar nicht ändern muss, sondern man die automatisch eingesetzten Daten via JavaScript auslesen und dann verschicken kann. Dazu muss die Seite lediglich via DOM (document.<form>.<field>.value) darauf zugreifen. Die aktualisierte Browsercheck-Seite von heise Security/UK demonstriert dies.

Von heise Security befragt, bestätigte Mozilla-Entwickler Gavin Sharp, dass man sich des Problems bewusst sei. In der Tat hat man es bereits in der Fehlerdatenbank kontrovers diskutiert und weitergehende Maßnahmen verworfen. Das automatische Einsetzen von Passwörtern auf anderen Seiten erhöhe den Komfort auf Sites, die mehrere Login-Seiten enthalten. Und selbst wenn man diese Funktion entferne, sei die Gefahr des Passwortdiebstahls nicht gebannt. Denn sobald ein Angreifer Script-Code auf einem Server platzieren kann, sei er ohnehin in der Lage, die Seiten nach seinem Gusto zu manipulieren und dem Anwender Zugangsdaten abzuluchsen.

Die Argumentation der Mozilla-Entwickler ist durchaus nachvollziehbar, verlässt sich das Sicherheitsmodell von JavaScript doch nahezu vollständig auf die Herkunft des Codes (Same Origin Policy). Wenn es einem Angreifer gelingt, seinen "bösen" Code auf einem Server zu platzieren, kann er im Browser des Anwenders alle Seiten dieses Servers nahezu beliebig manipulieren. Es bleibt dennoch ein flaues Gefühl, wenn ein Passwort Manager ganz ohne User-Interaktion Passwörter in gefälschte Formulare einträgt. Das erinnert doch sehr an eine Geldbörse mit einem Loch.

Aus Anwendersicht heißt das auf alle Fälle, dass man dem Passwort Manager sein Passwort nicht anvertrauen darf, wenn eine Web-Site es anderen Usern erlaubt, eigene Seiten mit Script-Code zu erstellen. Sonst könnte jemand ganz einfach eine Seite basteln, die schon beim Öffnen heimlich das Passwort klaut. Zu dieser Kategorie von Sites gehören beispielsweise viele Content Management Systeme. Daran ändern auch spezielle Filterfunktionen wenig, die versuchen, zwischen gutem und bösem Code zu unterscheiden. Denn sie lassen sich erfahrungsgemäß meist irgendwie umgehen. Alternativ kann man JavaScript abschalten oder mit Erweiterungen wie NoScript reglementieren, was jedoch gerade im Zeitalter von Web 2.0 dazu führt, dass viele Seiten gar nicht mehr funktionieren. Ob hingegen der völlige Verzicht auf einen Passwort-Manager die Sicherheit letztlich erhöht, darf ebenfalls bezweifelt werden. Denn dies führt häufig dazu, dass Passwörter aus Bequemlichkeit zu einfach gewählt und oft wiederverwendet werden.

Quelle : www.heise.de

[SiLæncer]

Seit Version 2.0.0.5 verfügt der Open-Source-Webbrowser Firefox über eine Sicherheitsfunktion, die es Angreifern erschweren soll, mittels JavaScript Cookies bestimmter Seiten zu kopieren und sich damit unter falscher Flagge anzumelden. So genannte HttpOnly-Cookies lassen sich nicht mehr durch JavaScript auslesen, sodass beispielsweise Cross-Site-Scripting-Attacken, die die JavaScript-Methode document.cookie nutzen, nicht mehr funktionieren.

Ursprünglich untertützte nur der Internet Explorer seit Version 6 SP1 die Erweiterung des Cookie-Formats um dieses Attribut (Set-Cookie: VAL=023; expires=Tuesday, 24-Jul-07 23:12:40 GMT; httpOnly). Bis dato setzen aber nur wenige Seiten aus Kompatiblitätsgründen HttpOnly-Cookies. Für Tests auf dem eigenen Server reicht etwa unter PHP folgender Code-Schnippsel:

Code: [Auswählen]

<?php
header("Set-Cookie: hidden=value; httpOnly");
?>
<html>
<body>
<script>
alert(document.cookie);
</script>
</body>
</html>
Bei Aufruf des Skripts bleibt die Alert-Box leer.

Leider lässt sich diese Sicherheitsfunktion mit Tricks aushebeln, die Amit Klein zwar bereits Anfang 2003 in einem Posting auf Bugtraq beschrieben hat, die aber erst jetzt auf breiteres Interesse stoßen. Mit der JavaScript-Methode XMLHTTPRequest lassen sich die zu übertragenden Cookies im HTTP-Header direkt auslesen – ganz ohne document.cookie. Voraussetzung bleibt aber weiterhin, dass eine Seite ein XSS-Lücke aufweist, damit ein Angreifer eigenen JavaScript-Code in den Browser des Anwenders schleusen und starten kann. Eine Demo dazu findet sich auf ha.ckers.org.

Siehe dazu auch:

    * XS(T) attack variants which can, in some cases, eliminate the need for TRACE, Fehlerbericht von Amit Klein
    * Round-up: Ways to bypass HttpOnly (and HTTP Basic auth), Fehlerbericht von Amit Klein

Quelle und Links : http://www.heise.de/security/news/meldung/93178

[SiLæncer]

Das Hickhack zwischen Microsoft und der Mozilla-Foundation um registrierte Protokoll-Handler und die daraus resultierenden Sicherheitsprobleme geht weiter. So wurde eine neue Demo veröffentlicht, die zeigt, wie die aktuelle Firefox-Version unter Windows XP SP2 über präparierte Links zum Starten einer Anwendung missbraucht werden kann. Dabei öffnet sich beim Klick auf einen manipulierten mailto:-, nntp:-, snews:- oder news-Link die Eingabeaufforderung und der Windows-Taschenrechner startet. Prinzipiell ließe sich so jeder beliebige Befehl ausführen und Code über eine Webseite einschleusen und starten.

Damit die neue Demo funktioniert, muss allerdings der Internet Explorer 7 installiert sein. Ist nur der Internet Explorer 6 installiert, öffnet sich nur der Standard-Mailclient Outlook Express. Welche Rolle der Internet Explorer 7 dabei spielt, ist nicht ganz klar. Nach seiner Installation ändert sich jedoch offenbar die Art, wie Windows eine URI verarbeitet. Das zeigt sich auch daran, was pssiert, wenn man den "bösen" Link über "Ausführen" im Startmenü direkt an die Windows Shell übergibt. Mit IE6 startet Outlook Express, mit IE7 cmd.exe und der Taschenrechner.

Dem dazugehörigen Bugzilla-Eintrag zufolge ist ein Grund für die neue Lücke, dass Windows XP URIs mit der Zeichenfolge %00 falsch interpretiert. In der Folge wird statt des URL-Protokoll-Handlers der Filetype-Handler mit der kompletten URL aufgerufen, worüber es dann offenbar möglich ist, weitere Programme mit eigenen Argumenten aufzurufen. Um das Problem zu entschärfen, wollen die Firefox-Entwickler nun Links mit Nullbytes (%00) nicht mehr zu öffnen. Ein enstprechender Patch ist bereits in die Entwicklerversion eingepflegt. Einen praktikablen Workaround bis zum Erscheinen eines neuen offizellen Firefox-Release gibt es nicht.

Auch bei dieser Lücke dürfte die Schuldfrage wieder für heiße Diskussionen sorgen. Bei der letzten Cross-Browser-Lücke reichte der Internet Explorer präparierte URLs an Firefox weiter. Damals wies das IE-Team alle Verantwortung von sich und konstatierte: Es ist die Verantwortung der empfangenden (aufgerufenen) Applikation, sicher zu stellen, dass sie die übergebenen Parameter korrekt behandeln kann. Dem zu Folge wäre nun eigentlich weniger Mozilla als Microsoft unter Zugzwang, das gefährliche Verhalten abzustellen.

Die Autoren der Demo weisen darauf hin, dass es noch viele weitere Beispiele für derartige Lücken über registrierte URIs gäbe. Derzeit sei nur die Spitze des Eisberge zu sehen. Registrierte URIs seien so etwas wie ein Remote Gateway in den eigenen Rechner. Anwender sollten nach Meinung der Autoren sicherheitshalber alle unnötigen URIs deregistrieren – ohne allerdings darauf einzugehen, welche nun überflüssig sind.

Bei der Suche danach soll das Windows-Scripting-Host-Tool "Dump URL Handlers" helfen, dass die Registry durchforstet und alle registrierte URIs nebst zugehöriger Anwendung anzeigt. Auch die Autoren der Exploits haben das Tool nach Angaben des Programmierers für ihre Fehlersuche verwendet.

Quelle : www.heise.de

[SiLæncer]

Bei der Einschätzung, wer der eigentliche Verursacher aus der im Zusammenspiel von Firefox und Internet Explorer 7 resultierenden Lücke ist, gehen die Meinungen auseinander. Das US-CERT macht Firefox als den Schuldigen aus, da er übernommene Links nicht filtere, bevor er sie an den dafür registrierten URI-Protokoll-Handler weitergibt. Als Workaround schlägt das US-CERT vor, einen Warndialog im Firefox zu aktivieren, der den Anwender beim Aufruf etwa einer mailto-URI benachrichtigt und die Möglichkeit zum Abbruch gibt. Um die Konfigurationsseite aufzurufen, gibt man in der Adresszeile des Firefox about:config ein. Anschließend sind die Optionen:

network.protocol-handler.warn-external-default
network.protocol-handler.warn-external.mailto
network.protocol-handler.warn-external.news
network.protocol-handler.warn-external.nntp
network.protocol-handler.warn-external.snews

auf true zu setzen.

Auch das französische FrSIRT meldet auf seinen Seiten einen Fehler in Firefox beziehungsweise Mozilla und Netscape. Der Dienstleister macht ebenfalls die fehlende Filterung im Browser der Mozilla-Foundation bei der Übergabe der URIs für das Problem verantwortlich.

Einzig Secunia ist nach selbst angestellten Analysen der Meinung, dass der Fehler in Windows zu finden sei. Zudem hat Secunia herausgefunden, dass eine präparierte URI nicht die Zeichenfolge %00 enthalten muss, es genügt, wenn nur ein Prozentzeichen dort zu finden ist. So startet auf Windows XP mit Internet Explorer 7 ein Klick in Firefox auf

mailto:test%../../../../windows/system32/calc.exe".cmd

den Taschenrechner. Demzufolge wäre der von den Firefox-Entwicklern erstellte Patch wirkungslos, da er nach %00 in URIs sucht, um sie zu blockieren.

Quelle : www.heise.de

[Jürgen]

Der Grund-Tenor ist schon richtig, dass, wer Daten von anderen Anwendungen zu übernehmen bereit ist, sich selbst um eine notwendige Filterung zu kümmern hat.
Das entlastet allerdings den IE keinesfalls, es sei denn, eine zweite Instanz dessen würde ganauso reagieren.

Grundsätzlich halte ich es für keine gute Idee, zwei Browser in Reihe zu schalten, weil sich damit die Sicherheits-Lücken und -Denkfehler beider multiplizieren.
Und es ist nicht davon auszugehen, dass das M$ wirklich stört...
Also sollte man sich konsequenterweise für die Nutzung eines einzigen Browsers entscheiden, sofern das irgend geht.
Den IE kann man ja immer noch mit den Dingen beschäftigen, die er halbwegs hinkriegt oder nur selbst darf, Explorer-Erweiterung, Windoze-Update, Windoof-Hilfe, Active-eXploit, klei-mi-an-mors...

[SiLæncer]

Das letzte Woche bekannt gewordene Problem bei der Behandlung spezieller URLs zieht immer weitere Kreise. Neben Firefox kann auch Skype oder das Instant Messenging Programm Miranda als Einfallstor dienen. Das spricht sehr dafür, dass die eigentliche Ursache des Problems die verwirrende Behandlung von URLs unter Windows ist. Fühlt sich ein Programm für einen URL-Typ wie mailto: nicht zuständig, reicht es die URLs zur weiteren Behandlung an das Betriebssystem weiter. Was da jedoch passiert, unterscheidet sich bei Windows XP, je nach dem, ob Internet Explorer 7 installiert ist oder nicht (selbst wenn IE mit dem Protokoll nichts am Hut hat).

So kommt es, dass URLs, die ein %00 oder ein nacktes Prozentzeichen enthalten – also ein %, das nicht zu einer gültigen Escape-Sequenz wie %FF gehört – direkt Programme mit Parametern starten können. Klickt man in Firefox oder in einer Chat-Nachricht auf eine URL der Form

mailto:test%../../../../windows/system32/calc.exe".cmd

startet der Taschenrechner – zumindest auf einem Windows XP mit IE 7. Unter Vista oder mit dem alten IE6 funktioniert das jedoch nicht. Andere Programme, die sich in die URL-Behandlung einklinken, beeinflussen das Verhalten ebenfalls. Welche Protokolle außer den bislang bekannten mailto:, news:, snews:, nntp: und telnet: eventuell ebenfalls betroffen sind, ist nicht ganz geklärt. Alternativ kann man dies auch testen, indem man die Zeichenkette über "Ausführen" im Start-Menü direkt an das Betriebssystem übergibt. Angreifer könnten dieses Verhalten ausnutzen, um beliebige Befehle auf dem System ihrer Opfer auszuführen, denen sie entweder eine speziell präparierte Web-Seite unterjubeln oder etwa eine Skype-Nachricht senden.

Die Mozilla-Entwickler haben nach der Benachrichtigung durch heise Security, dass auch % den Fehler auslöst, eingesehen, dass ihr erster Ansatz %00 aus URLs herauszufiltern, hinfällig ist. Der Eintrag in der Fehlerdatenbank steht zwar noch auf "RESOLVED/FIXED", aber Mozilla-Entwickler Dan Veditz hat gegenüber heise Security bestätigt, dass man den aktuellen Patch als wirkungslos betrachte, da auch % allein das Problem auslösen kann.

Die Entwickler diskutieren derzeit, wie sie Anwender effizient schützen können, ohne legitime Programme unnötig zu behindern. Dabei stehen sie vor dem Problem, dass immer noch nicht ganz klar ist, wie Windows URLs tatsächlich behandelt. Zumindest gibt es mittlerweile erste Informationen von Microsoft, wie Windows welche URLs behandelt.

Wie Dan Veditz gegenüber heise Security erläuterte, überlegen die Entwickler derzeit, ob sie nicht besser den bereits nahezu fertigen Release Candidate für Version 2.0.0.6 auch ohne diesen Patch ausliefern sollen. Denn der enthält bereits einen anderen Patch für ein ähnlich gelagertes Problem, nämlich die nicht gefilterten Anführungszeichen, auf die manche Programme allergisch reagieren. Das würde nämlich auch schon alle bisher bekannten %-Exploits unterbinden. Damit gewänne man Zeit, um in Ruhe eine saubere Lösung für dieses Problem zu entwickeln, räsoniert Veditz.

Dass Programme wie Skype und Miranda ebenfalls betroffen sind, macht aber deutlich, dass nun definitiv Microsoft in der Pflicht ist, Klarheit in dieses Wirrwarr zu bringen und auch möglichst schnell die Behandlung von URLs durch Windows zu vereinheitlichen. Denn jetzt nur abzuwarten, bis alle Applikationen sich auf das aktuelle Chaos eingestellt haben, hieße, das Problem auf dem Rücken der Anwender auszusitzen.

Update:
Nach Tests von heise Security sind auch Anwender des IM-Clients Miranda gefährdet. Durch einen Klick auf eine Chat-Nachricht startete direkt der Taschenrechner. Somit ist davon auszugehen, dass alle Applikationen, die URLs entgegennehmen und an das Betriebssystem zur Bearbeitung weitergeben, potentiell anfällig für dieses Problem sind.

Quelle : www.heise.de

[SiLæncer]

Die Mozilla-Entwickler haben Version 2.0.0.6 des Webbrowsers Firefox freigegeben. Sie bringt eine weitere Korrektur für das Problem, das bei der Behandlung spezieller URLs auftritt, die bei installiertem Internet Explorer 7 unter Windows XP dazu führen, dass Angreifer beliebige installierte Programme aufrufen können. Dadurch könnten bösartige Individuen mit manipulierten Links in Webseiten oder E-Mails auch schädliche Aktionen ausführen.

Firefox 2.0.0.6 enthält den von Daniel Veditz bereits am gestrigen Montag angekündigten Patch, der eine Sicherheitslücke bei der Verarbeitung von URLs mit eingebetteten Anführungszeichen schließt. Der Patch löst auch das Problem bei der Verarbeitung von URLs mit integrierten %00- oder %-Zeichen, durch die installierte Anwendungen aufgerufen werden können. Die Entwickler erläutern in der Sicherheitsmeldung, dass die Lösung noch nicht sauber ist, aber alle bisher bekannten Exploits nicht mehr funktionierten – bei Tests von heise Security passierte beim Folgen der bekannten präparierten Links in der Tat nichts mehr. Wie Veditz am gestrigen Montag gegenüber heise Security äußerte, gewinnen die Entwicker durch die Veröffentlichung der neuen Version Zeit, um eine bessere Lösung für das Problem zu erarbeiten.

Die aktuelle Version behebt ein weiteres Sicherheitsleck, das die Entwickler in der Vorgängerversion mit einem Patch für eine Frame-Spoofing-Sicherheitslücke aufgerissen haben. Dadurch können Angreifer die Rechte etwa für JavaScript-Code mit präparierten Webseiten erhöhen. In den Sicherheitsmeldungen kündigen die Mozilla-Entwickler auch Thunderbird 2.0.0.6, 1.5.0.13 und SeaMonkey 1.1.4 an, die die Schwachstellen ebenfalls beheben. Bislang sind die neuen Versionen allerdings noch nicht auf den Download-Servern aufgetaucht.

Quelle : www.heise.de

[SiLæncer]

Mozilla-Entwickler stopfen URI-Lücke auch in ihrem E-Mail-Client

Nachdem die Mozilla-Entwickler die URI-Lücke im Zusammenspiel zwischen Firefox und Internet Explorer 7 eindämmten, folgt nun auch ein entsprechendes Update für den E-Mail-Client Thunderbird. Die Sicherheitslücke erlaubt es Dritten, Applikationen auf fremden Rechnern zu starten und ist nicht auf die Mozilla-Produkte beschränkt.
Die Sicherheitslücke die unter Window XP im Zusammenspiel mit dem Internet Explorer 7 auftritt, erlaubt es, fremden Code auf Windows-Rechnern auszuführen. Dabei kommen zwei Sicherheitslücken zusammen. Das eine von Billy Rios und Nate McFeters entdeckte Problem: URIs für bestimmte Protokolle lassen sich nutzen um eine Applikation auf dem System des Nutzers zu öffnen, je nach angegebener Datei-Endung. Dazu müssen die URIs mit "%00" bzw. "%" versehen werden, dann werden sie an einen Datei-Handler übergeben. So lassen sich Programme, deren Pfad bekannt ist, starten.

Das Problem tritt dann auf, wenn URIs für Protokolle in einer Applikation aufgerufen werden, die für diese nicht zuständig ist und sie stattdessen an eine andere übergibt. Bei Firefox ist dies beispielsweise "mailto", was eigentlich den E-Mail-Client aufrufen sollte, bei zum Beispiel Thunderbird "http".

Zusätzlich gefährlich wird dies durch eine zweite von Jesper Johansson entdeckte Lücke, durch die sich der aufgerufenen Applikation in begrenztem Rahmen Parameter übergeben lassen.

Firefox 2.0.0.6 und nun auch Thunderbird 2.0.0.6 sollen die bisher bekannten Möglichkeiten, eine dieser Sicherheitslücke zu nutzen, beseitigen - das eigentliche Problem bleibt aber bestehen, so die Mozilla-Entwickler. Das problematische Verhalten sei Teil des Windows-Shell-API und daher auch andere Internet-Applikationen neben Firefox betroffen. Heise Security dokumentiert die Probleme bei der URI-Übergabe auch bei Skype und Miranda.

Thunderbird 2.0.0.6 steht ab sofort unter www.mozilla.com zum Download bereit. Details zu den Änderungen finden sich in den Release Notes ( http://www.mozilla.com/en-US/thunderbird/2.0.0.6/releasenotes/ ) .

Quelle : www.golem.de

[Jürgen]

Beide 2.0.0.6er sind auch über die jeweils eingebaute Aktualisierungs-Funktion erhältlich (falls noch nicht automatisch geschehen).
Die dafür zu übertragende Datenmenge ist gering.

[SiLæncer]

Billy Rios and Nate McFeters, die Entdecker der URI-Lücke im Open-Source-Browser Firefox, haben in ihrem Blog darauf hingewiesen, dass das eigentliche Problem mit der Veröffentlichung von Firefox 2.0.0.6 Ende Juli nicht beseitigt wurde. So wollen sie einen neuen Weg gefunden haben, um über File-Handler und präparierte Pfade trotzdem weitere Anwendungen zu starten.

Allerdings haben die Firefox-Entwickler bereits mit der Veröffentlichung der aktuellen Browserversion deutlich gemacht, dass das Update nur ein Workaround darstellt, um Zeit zu gewinnen und zumindest vor den bekannten Exploits mit %00- oder %-Zeichen zu schützen. Rios und McFeters haben außer einem Screenshot deshalb auch keine genauen Angaben über das neue Problem veröffentlicht, damit die Entwickler in Ruhe an der Behebung des Fehlers arbeiten können. Wann eine überarbeitete Firefox-Version erscheinen wird, ist nicht bekannt.

Die URI-Lücke tritt bei der Behandlung spezieller URLs auf, die bei installiertem Internet Explorer 7 unter Windows XP dazu führen, dass Angreifer beliebige installierte Programme aufrufen können. Dadurch lassen sich mittels manipulierter Links in Webseiten oder E-Mails auch schädliche Aktionen ausführen. Bislang ist allerdings nicht gänzlich geklärt, was die eigentliche Ursache des Problems ist. Unter anderem ist die verwirrende Behandlung von URLs unter Windows Teil des Problems. Auch Skype, Miranda und wahrscheinlich weitere Anwendungen weisen die URI-Lücke auf.

Quelle : www.heise.de

[SiLæncer]

Der Sicherheitsspezialist Alexander Klink hat über eine Möglichkeit berichtet, PCs über eine Art Super-Cookie wiederzuerkennen. Betroffen sind nach bisherigem Kenntnisstand aber nur PCs, deren Anwender den Webbrowser Firefox in seinen Standardeinstellungen nutzen. Die Idee die hinter dem Cookie steckt, beruht auf TLS-Client-Zertifikaten, die auf dem PC beim Besuch einer präparierten Webseite mittels "Signed Public Key And Challenge" (SPKAC) generiert und gespeichert werden.

Diese Zertifikate dienen normalerweise zur bidirektionalen TLS/SSL-Authentifizierung, durch die sich ein Server von der Echtheit eines Clients überzeugen kann. Allerdings lässt sich solch ein Zertifikat ohne viel Zutun des Anwenders von jedem Server mit beliebigen Inhalten installieren. Alles was der Firefox-Anwender sieht, ist eine kurze Meldung "Key generation in progress ... This may take a few minutes ... Please wait ...", die auf schnellen Rechnern innerhalb von Sekundenbruchteilen wieder verschwindet.

Anschließend kommt noch der Hinweis "Your personal certificate has been installed. You should keep a backup copy of this certificate." Die wenigsten Anwender dürften bei derlei Meldungen Verdacht schöpfen oder dazu in der Lage sein, den Vorgang nachzuvollziehen, um das gespeicherte Zertifikat wieder löschen zu können. In Fällen, in denen mit dem Firefox noch kein einziges Passwort im Passwort-Manager gespeichert wurde, erscheint zusätzlich ein Dialog zur Eingabe eines Kennwortes für das Zertifikat. Allerdings dürften auch diesen Dialog nur noch wenige zu Gesicht bekommen.

Da Firefox in der Standardeinstellung versucht, ein vom Server angefordertes Client-Zertifikat automatisch auszusuchen, kann jeder beliebige Server – auch aus einer anderen Domain – beim Besuch das Zertifikat herunterladen und so den Rechner wiedererkennen. In einer Diskussion zu dem Problem wurde hervorgehoben, dass auch sehr sicherheitsbewußte Anwender des Anonymisierungsnetzes Tor davon betroffen sind, da sich so zumindest die besuchten Seiten nachvollziehen ließen. Auch Pivoxy soll nicht vor den Super-Cookies schützen.

Anders als von Klink zunächst angenommen, funktioniert solch ein Cookies sowohl in Firefox 2.0 als auch in Firefox 1.5 (jeweils unter Windows und Linux). Andere Browser sollen laut Bericht von dem Problem nicht betroffen sein: Opera und Konqueror öffnen mehrere Dialoge, die den Anwender misstrauisch werden lassen sollten, der Internet Explorer unterstützt kein SPKAC, und bei Safari ist es dem Autor nicht gelungen, ein Zertifikat zu übermitteln. Eine Online-Demo führt das Problem vor: Firefox 2.0.x TLS client certificate tracking POC. In der Demo ist zwar noch die Angabe eines Namens erforderlich, bei einem echten Tracking-Versuch könnte dies ein JavaScript jedoch automatisch übernehmen. Abhilfe bringt derzeit nur, unter "Einstellungen/Erweitert/Verschlüsselung/Zertifikate" die Option "Jedes mal nachfragen" zu setzen. Dann erscheint immerhin ein Dialog, dass ein Server ein Zertifikat abfragen möchte, was sich im Zweifel unterbinden lässt.

Siehe dazu auch:

    * Firefox 2.0.x: tracking unsuspecting users using TLS client certificates, Fehlerbericht von Alexander Klink
    * Firefox 2.0.x TLS client certificate tracking POC, Demo zum Super-Cookie

Quelle und Links : http://www.heise.de/security/news/meldung/96229/Benutzer-Tracking-mit-SSL-Zertifikaten-in-Firefox

[SiLæncer]

Nach einer Benachrichtigung durch heise Security hat Skype in der aktuellen Version 3.5.0.239 ein Sicherheitsproblem bei der Behandlung spezieller URLs stillschweigend behoben. Andere Programme wie Adobes Acrobat Reader, der Netscape-Browser und das Instant-Messaging-Programm Miranda starten hingegen immer noch bei einem einfachen Klick auf spezielle URLs mit einem %-Zeichen beliebige Programme und installieren damit möglicherweise Spyware auf dem System der Anwender. Ein ähnliches Problem haben die Mozilla-Entwickler kürzlich in Firefox zumindest provisorisch beseitigt.

Doch während das Mozilla-Team die Lücke als kritisch einstufte, dazu eine eigene Sicherheitsnotiz herausgab und vor allem die Anwender über den Update-Mechanismus mit der verbesserten Version versorgte, hielt Skype nichts von alledem für nötig. Lediglich der nichtssagende Hinweis "bugfix: Links with invalid % encodings were executed" in den Release Notes, die kein normaler Anwender zu Gesicht bekommt, kündet von dem behobenen Sicherheitsproblem. Skype-Nutzer sollten deshalb so schnell wie möglich selbst die aktualisierte Version einspielen. Das geht recht einfach über "Hilfe/Auf Aktualisierung prüfen".

Es lässt sich trefflich darüber streiten, ob wirklich Skype oder nicht etwa Windows für das Problem verantwortlich ist. So betonte auch Jüri Shamov-Liiver, Skypes Leiter der Abteilung Produktsicherheit gegenüber heise Security, dass dies eigentlich ein Windows-Problem sei. Skype reiche die URL lediglich an das Betriebssystem weiter. Tatsache ist, dass Microsoft mit der Installation des Internet Explorer 7 unter Windows XP offenbar die Behandlung von URLs durch das Betriebssystem so geändert hat, dass spezielle Links, die ein %-Zeichen enthalten, direkt zum Aufruf beliebiger Programme führen können.

Skype und Firefox haben dieses Problem jetzt durch zusätzliche Filter behoben – aus der Welt ist es damit keineswegs. Theoretisch sind alle nicht von Microsoft stammenden Applikationen gefährdet, die URLs an Windows weiterreichen, weil sie sich nicht zuständig fühlen. Eine kurze Stichprobe von heise Security zeigte, dass beispielsweise Adobes aktueller Acrobat Reader durchaus auch praktisch als Einfallstor für Schädlinge dienen könnte. Ein Klick auf einen Link in einer entsprechend präparierten PDF-Datei startete bei einem schnellen Test den Taschenrechner. Auch der aktuelle Netscape-Browser und die soeben veröffentlichte Version 0.7 des Instant Messengers Miranda erwiesen sich als anfällig; die Liste lässt sich vermutlich mit etwas Suchen weiter verlängern.

Microsoft sieht jedoch weiterhin keine Veranlassung, an Windows nachzubessern. Auf eine diesbezügliche Anfrage von heise Security an Microsofts Security-Team kam die lapidare Antwort, dass dies keine Schwachstelle in einem Microsoft-Produkt sei. Dass viele Windows-Anwender von einem Problem betroffen sind, das erst durch die Installation des Internet Explorer 7 hervorgerufen wird, und unter Vista erst gar nicht auftritt, reicht offenbar nicht aus, ein Update für Windows XP zu rechtfertigen. Vielmehr sieht es so aus, als wolle man in Redmond das Problem auf dem Rücken der Anwender aussitzen.

Quelle : www.heise.de

[SiLæncer]

Adobe warnt in einer Sicherheitsnotiz vor einem kritischen Sicherheitsproblem und beschreibt, wie sich Anwender davor schützen können. Betroffen sind Adobe Reader, Adobe Acrobat Standard, Professional und Elements bis einschließlich 8.1 und Adobe Acrobat 3D.
Anzeige

Bei der Lücke handelt es sich offensichtlich um das bereits geschilderte URI-Problem von Windows. Wie viele andere Applikationen auch, reichen Adobes Viewer URLs, für die sie sich nicht zuständig fühlen, via ShellExecute() an das Betriebssystem weiter. Windows XP mit Internet Explorer 7 reagiert auf eine URL der Form

mailto:test%../../../../windows/system32/calc.exe".cmd

indem es den Taschenrechner startet. Ohne IE7 startet der zuständige URL-Handler Outlook Express und unter Vista erscheint eine Fehlermeldung. Dieses verwirrende Verhalten lässt sich nachvollziehen, indem man diese Zeichenkette unter "Start/Ausführen" eingibt; es ist nicht auf mailto-URLs beschränkt.

Mit entsprechend präparierten URLs lassen sich unter Windows XP mit IE7 viele Applikationen als Einfallstor zum Beispiel für Spyware missbrauchen, die ohne Internet Explorer 7 noch sicher waren. Firefox und Skype haben bereits reagiert und dementsprechende Updates veröffentlicht, um ihre Anwender zu schützen. Im Fall der Adobe-Software ist das Problem besonders kritisch, da viele User PDF-Dateien bedenkenlos öffnen und die gefährlichen URLs dabei automatisch gestartet werden können.

Der von Adobe beschriebene Workaround setzt im Registry-Zweig

Acrobat: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Adobe Acrobat\8.0\FeatureLockDown\cDefaultLaunchURLPerms

beziehungsweise

Reader: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Acrobat Reader\8.0\FeatureLockDown\cDefaultLaunchURLPerms

in tSchemePerms den Wert von mailto:2 auf mailto:3, was das Ausführen von mailto-URLs unterbindet. Die von heise Security erstellte Demonstrationsdatei lieferte damit nur noch eine Fehlermeldung.

Demnächst will Adobe auch ein Update der Software bereitstellen, das vor diesem Problem schützt. Netscape, Miranda, mIRC und vermutlich eine ganze Reihe weiterer Applikationen können jedoch ebenfalls als Einfallstor dienen. Nachdem der Internet Explorer 7 – seit neuestem auch ohne WGA-Prüfung – über die automatische Update-Funktion an Windows-XP-Systeme ausgeliefert wird, dürfte sich die Zahl der betroffenen Anwender noch weiter erhöhen.

Die einzige Möglichkeit, das Problem grundsätzlich aus der Welt zu schaffen, wäre ein Patch von Microsoft, der das Verhalten von Windows XP beispielsweise dem von Vista angleicht. Doch wie eine Nachfrage von heise Security ergab, ist der derzeit nicht in Aussicht.

Quelle : www.heise.de

[SiLæncer]

Wie der Sicherheitsdienstleister Secunia meldet, ist auch Outlook Express und 2000 vom Windows-URI-Problem betroffen. Somit kann nicht nur in Firefox, Skype, Adobe Reader, Miranda, mIRC und Netscape sondern auch in Microsoft-Applikationen ein falscher Klick dazu führen, dass beliebige Programme auf dem System des Anwenders gestartet werden. Bislang hatte Microsoft Forderungen nach einem Patch, der das Problem an der Wurzel, nämlich in Windows behebt, mit dem Verweis gekontert, man sehe kein Sicherheitsproblem in Microsoft-Produkten.

Ursache des Problems ist das inkonsistente Verhalten von Windows beim Öffnen bestimmter URLs mit ungültigen Zeichenfolgen. Während Windows XP mit Internet Explorer 6 zu deren Bearbeitung den zuständigen URL-Handler – bei "mailto:" beispielsweise Outlook Express – startet, führt es mit installiertem Internet Explorer 7 direkt eine Applikation aus; in den harmlosen Demos meist den Taschenrechner. Windows Vista hingegen erzeugt bei den gleichen URLs lediglich eine Fehlermeldung. Der Sicherheitsdienstleister Secunia war einer der ersten, der beim Bekanntwerden dieses Problems nicht Firefox, sondern Windows als eigentliche Ursache ausmachte.

Viele Applikationen reichen URLs, für die sie sich nicht zuständig fühlen, einfach an das Betriebssystem weiter. So auch Outlook Express und Outlook 2000, wenn es die in einer VCard angegebene URL öffnen soll. In einem kurzen Test von heise Security startete beim Klick auf "Gehe zu" im Adressbuch ohne Nachfrage der Taschenrechner. Das kann unter Windows XP mit IE7 dann dazu führen, dass Angreifer über speziell präparierte VCards beispielsweise Spyware auf einem System einschleusen könnten.

Erst gestern hatte Adobe vor einem ähnlichen Problem in Adobe Reader/Acrobat gewarnt und einen Patch für Ende Oktober in Aussicht gestellt. Firefox und Skype hatten bereits davor Updates veröffentlicht, die ihre Anwender schützen sollen; mIRC, Netscape und Miranda sind immer noch anfällig. Mit der Veröffentlichung der Tatsache, dass auch Outlook in die URI-Falle tappt, steigt die Hoffnung, dass Anwender nicht über Monate hinweg kritische Lücken in dutzenden Applikationen beheben müssen, sondern sich Microsoft nun doch des Problems annimmt und das Verhalten von Windows etwas berechenbarer gestaltet.

Quelle : www.heise.de

[SiLæncer]

Nach einer 180-Grad-Kehrtwende bestätigt Microsoft nun die Existenz einer "URL-Handling-Sicherheitslücke in Windows" in einem Knowledge-Base-Artikel und stellt einen Patch in Aussicht. Der Hauptgrund für den Sinneswandel ist laut Security Response Center, dass Microsoft in der Diskussion um das Problem selber zur Verwirrung beigetragen habe, indem es heise Security in einer Stellungnahme zu der Lücke das falsche "Set of Talking Points" geliefert habe, also laut Wikipedia den falschen Satz an PR-Phrasen. Die sich an eine diesbezügliche Meldung anschließende Diskussion auf der Sicherheitsmailingliste Full Disclosure habe die Redmonder dann bewogen, doch zu reagieren. Ein weiterer Grund könnte allerdings sein, dass sich kürzlich heraussstellte, dass auch Microsoft-Anwendungen wie Outlook Express und Outlook 2000 von dem Problem betroffen sind.

Im Blog des MSRC wird auch erklärt, wieso das Problem nur in Kombination mit dem Internet Explorer 7 unter Windows SP und Server 2003 auftritt. Mit der Installation des IE7 werden aufgerufene URIs zuerst genauer vom Browser auf ihre Gültigkeit untersucht und im Zweifel verworfen. Laut Microsoft versucht anschließend aber noch die Windows-Funktion ShellExecute() die URI zu interpretieren. Unter Vista wird dabei eine fehlerhafte URI, etwa mit Prozent- und Anführungszeichen an bestimmten Stellen, verworfen – unter XP allerdings nicht, was dazu führt, dass sich installierte Programme über ShellExecute() mit beliebigen Parametern starten lassen. Mit dem Internet Explorer 6 unter XP läuft die Verarbeitungsreihenfolge einer URI andersherum, weshalb der Fehler dort nicht auftritt.

Durch den geplanten Patch soll die URI-Verarbeitung der Funktion ShellExecute() sicherer werden. Daneben empfiehlt Microsoft Herstellern von Anwendungsprogrammen aber ebenfalls, die Gültigkeit der übergebenen URI zu prüfen, wie es Firefox und Skype bereits getan haben und Adobe demnächst tun will.

Quelle : www.heise.de