3.6 zero.day

Secunia hat auch schon einen Vorschlag zur Lösung

Zitat

Solution
Do not visit untrusted websites or follow untrusted links.

Und zur Abwechslung mal nicht als Admin unterwegs sein. Könnt vielleicht helfen.

Zitat

Der russische Sicherheitsdienstleister Intevydis hat seinen Kunden einen Windows-Exploit für eine bislang unbekannte Sicherheitslücke in Firefox 3.6 zur Verfügung gestellt.
[...]Mittlerweile ist die Mozilla Foundation auf das Problem aufmerksam geworden

Das Beschämende an der Sache ist doch, dass eine russische Firma ihren "Kunden" den Exploit zukommen lässt, statt Mozilla darüber zu informieren, ob nun durch responsible oder full disclosure. Ein schneller Patch wäre für Mozilla sicher kein Problem. So erfahren sie scheinbar aus den Medien davon und dürfen sich dann auf die Suche machen. Eine fragwürdiges Geschäftsmodell und alles andere als vertrauenerweckend!

Aber genau so ist das W(ilde) W(esten) W(eb). Bugcatchers Rat (vermutlich mit ironischem Unterton bei "zur Abwechslung") zeigt auf, daß Millionen von ahnungslosen und in Bezug auf ihre Sicherheits-Suiten gut-(blau-)äugige Self-made-Admins sich verhalten wie jemand, der tagtäglich nackt in einem Gehege mit Schlangen und Skorpionen lebt. (Ich kenne keinen geistig gesunden Menschen, der so etwas in Betracht zöge.)

Nee. aber guck mal hier Immunity Forum: da hat's wohl jemand getestet -

Alter Hut und somit unter XP SP3 - sowie auch unter Vista SP2 - weitgehendst von Irrelevanz.

a. Programmorientierte Buffer-Overflow-Angriffe (z.B. der erzwingte Absturz eines Browsers) scheitern - meinen bisherigen Erkenntnissen nach – stets auch immer an der „System-Shell“ (dem abgesicherten Betriebssystem zur Basis) selber. Eine Infektion der genannten Betriebssysteme wäre weitgehendst ausgeschlossen, da Anwendungs-Prozesse im Kontext dieser gepatchten Betriebssysteme bereits ansatzweise schon nach Privilegien selektiert werden.

b. Da die sog.“Rücksprungadresse“ eines Objektes (einer Anwendung) nicht immer genau der „Anfangsadresse“ des eingeschleusten Codes selber entsprechen kann, gestaltet sich - nach meinem bisherigen Wissen - von daher eine erfolgreiche Ausführung des implizierten Codes innerhalb der privilegierten Ausführungsumgebung (Prozesse-Erweiterungen / engl. Elevation of Privileges) eher als „zufällig“ - nicht jedoch als „garantiert“.

Ein netter Versuch, der vermutlich bloss die „Marketing-Maschinerie“ fördern sollte. Die Technik spricht – meiner Ansicht nach - jedoch eine andere Sprache...

Oliver

Zitat

daß Mozilla anscheinend noch garnicht weiß was überhaupt Sache ist

Wie auch? Siehe dazu oben sowie das Statement von Mozilla:
http://blog.mozilla.com/security/2010/…visory-sa38608/

Zitat

Mozilla is aware of the claim of a zero-day in Firefox
[...]
We cannot confirm the report as we have received no details regarding the reported vulnerability
[...]
We’ve attempted to contact the researcher who discovered the issue but have not received a response.

Profilierung und Wichtigtuerei auf dem Rücken der Anwender!Bravo!Solche "Sicherheitesexperten" braucht die Welt.

Wenn das Netzwerk die notwendige Ausdehnung hätte. Wenn das nicht so ist, helfen auch keine Sprüche.

Zitat

habe ich halt auf eine größere "Ausdehnung" gehofft.

Grundsätzlich ist die Annahme durchaus möglich. Allerdings werden hier wohl monetäre Gründe dagegen sprechen. Für die Info will das Unternehmen Geld und die Kundschaft selbst wird das erkaufte Wissen wohl nicht einfach so herschenken.

Zitat

daß das Ding zum Hoax2010 gekürt wird

*gg*

Technisch betrachtet besteht der Browser (Firefox) in der heutigen Zeit immer noch aus einer Ableitung der inzwischen „veralteten“ und somit auch „kompromittierbaren“ C# Entwicklungsumgebung.

Diese veraltete Programmiersprache (C#) gilt somit im Zuge einer möglichen „Bereichsgrenzenüberschreitung“ (also eines möglicher Buffer-Overflows) scheinbar als angreifbar, da durch diese Schnittstelle sog. „Eingabestrings“ ungeprüft auf die „Zieladresse“ (ohne quantitative Zeichenüberprüfung) innerhalb eines Programms (z.B. des Firefoxes) übertragen werden können, was dann u.U. wiederum den Absturz einer solchen Anwendung erzwingen könnte. Hierbei spielt – meiner Einschätzung nach - jedoch auch der Zufall eine Rolle.

Platt ausgedrückt, läge das Problem somit an der „Wurzel“ und nicht in der aktuellen Erkenntnis der Schöpfer...

a. Java wäre u.U. in der heutigen Zeit als Programmiersprache vielleicht als geeigneter und sicherer zu bezeichnen.

b. Habe darüberhinaus mal irgendwo gehört, dass es unter UNIX dennoch möglich sein soll, „Kontrollzeichen“ in den bereits „offen liegenden Quellcode“ so eines Programms (wie den Firefox) einzufügen. (z.B. über das Stack-Guard-Tool > GNU C-Compiler > Patch (Canary / Frühwarnsystem) > Rücksprungüberprüfung).

Nichts weiter als "native" Code-Manipulation.

Oliver

Zitat

Der Browser (Firefox) besteht – meines Wissens nach – in der heutigen Zeit immer noch aus einer Ableitung der inzwischen „veralteten“ und somit auch „kompromittierbaren“ C# Entwicklungsumgebung.

Diese inzwischen veraltete Programmiersprache (C#)

Der Zusammenhang mit C# erschließt sich mir nicht so ganz.
https://developer.mozilla.org/En/Developer_G…s_Prerequisites
Zwar kann mit Visual Studio 2005, aus dem der momentan genutzte Windows-Compiler stammt, auch C# entwickelt werden, aber der Fx-Code selbst ist zum großen Teil in C++ gehalten.

Boardraider erklärte u.A. Folgendes:

Zitat

[...]aber der Fx-Code selbst ist zum großen Teil in C++ gehalten.

Richtig. `C` entspricht jedoch weitgehendst `C++`.

a. Unter den Programmiersprachen C sowie auch C++ kann es – meines bisherigen Wissens nach - somit zu Problemen in der Verarbeitung von Zeichenketten kommen, wobei gewisse Programmfunktionen dieser Sprachen ungeprüft in die abgesicherten Eingabebereiche der Anwendungen (z.B. Firefox) eingespeist werden können, was wiederum einen unmittelbaren „Shutdown“ (also eine erzwungene Abschaltung / Buffer-Overflow) des Programms selber zur Folge hätte.

b. Der C++ Funktionsaufruf (strcpy ( )) wäre als Beispiel in der Lage, einzelne Zeichen sequenziell in einen Zielstring hinein kopieren zu dürfen, ohne dabei prüfen zu müssen, ob der dafür zur Verfügung stehende Speicherbereich auf dieser Zieladresse überhaupt für so eine mengenmässige Einspeisung von Zeichenketten ausreichen könnte. (Die (unzureichende) Terminierung würde dann erst bei dem ASCII – Wert 0 enden).

Solche unzureichende Programmieransätze (z.B. Buffer-Overwlows unter C, C++) könnten – meiner Ansicht nach - bloss compilerseitig ausgeglichen werden.

Ich glaube schon, dass sich die Mozilla-Entwickler dieses Problems bewusst sind.

Oliver