Google Chrome: 27 von 100 Erweiterungen mit Sicherheitslücken
Nein, den Chrome-Entwicklern mache ich jetzt keinen Vorwurf – warum auch? Es sind eher die Entwickler von Erweiterungen, die unsauber arbeiten sollen. Insgesamt 27 von 100 untersuchten Erweiterungen sollen Sicherheitslücken enthalten, eine alarmierende Zahl. Es wurden 50 zufällige und 50 der beliebtesten Erweiterungen unter die Lupe genommen. Die Erweiterungen wurden dahingehend getestet, ob sie via Web oder WLAN angreifbar waren. Gut zu wissen: die beliebten Erweiterungen XMarks und LastPass sind laut Aussagen der Tester sicher.
Interessanterweise wurde auch mitgeteilt, dass sich die Sicherheitslücken von insgesamt 51 auf 2 verringern würden, hätten die Entwickler die Content Security Policies von Google eingehalten. Welche Erweiterungen genau betroffen sind, wird in sechs Wochen mitgeteilt – man möchte den Entwicklern Zeit geben, ihre Löcher zu stopfen. Übrigens: stellt euch vor, diese Info habe ich aus einem Blog bei Microsoft.
„Nein, den Chrome-Entwicklern mache ich jetzt keinen Vorwurf – warum auch? Es sind eher die Entwickler von Erweiterungen, die unsauber arbeiten sollen.“
=> Damit macht man es sich aber sehr einfach. Es ist Aufgabe von Google, eine sichere Umgebung für Add-ons zu schaffen und genauso Aufgabe von Google, Sicherheits-Reviews bei den Erweiterungen durchzuführen. Nicht grundlos gibt es derart hohe Zahlen bei Mozilla nicht.
Es ist immer ein Trade-Off zwischen Sicherheit der Umgebung und der Möglichkeiten die man den Entwicklern einräumt. Also mag es sein wenn man eine sichere Umgebung schafft es unter Umständen sein kann, dass einige sinnvolle Möglichkeiten für Entwickler ausgeschlossen werden müssen.
Aber ich sehe, dass auch so wie Sören! Google müsste für eine sichere Umgebung sorgen. Denn es gibt immer „Bösewichte“ die auch absichtlich so Sicherheitslücken unterjubeln wollen um sie dann auszunutzen. Also sehe ich Google in der Pflicht!
Naja, wenn 49 von 51 Lücken durche eine Zeile Code verhindert werden würden kann man nicht von einem Fehler von Google sprechen. Klar, praktischer wäre es wenn Google von Anfang an strikt nur nachladen von ’self‘ erlaubt hätte und alles andere erst per Whitelist, aber nun kann man das nicht mehr so einfach ändern ohne das gar keine Erweiterung mehr funktioniert
wie ist das mit denn Addons bei Firefox? ist es da evtl. schlimmer…
Nö, ist es nicht. Wäre sonst ja wohl bekannt. Sicherheit wird da groß geschrieben.
…Damit macht man es sich aber sehr einfach. Es ist Aufgabe von Google, eine sichere Umgebung für Add-ons zu schaffen und genauso Aufgabe von Google, Sicherheits-Reviews bei den Erweiterungen durchzuführen…
Ihr wollt also den gleichen „goldenen Käfig“ wie bei Apple?
Es ist die alte „Leier“ Freiheit gegen vermeidliche Sicherheit eintauschen zu können, was aber nicht Funktioniert nur den Anwender Entmündigt.
Zudem tendensiöser Artikel gegen Chrome vom Microsoft Bloggern ohne Vergleiche zu anderen Plattformen.
Denke MS bekommt etwas Panik wegen den steigenden Marktanteilen von Chrome
Das hat doch nichts mit goldenem Käfig zu tun. oO Hörst du bei Mozilla (die den deutschen Markt nun einmal bestimmen und daher nicht das schlechteste Beispiel sind) von so hohen Zahlen? Nein. Opera? Safari? Selbst IE? Die schaffen es also auch irgendwie. Der Browserhersteller MUSS dafür sorgen, dass Add-ons keinen Schaden anrichten können. Wie Klaus bereits sagte: Es gibt genug Leute, die absichtlich Sicherheitslücken einprogrammieren um damit Schaden anzurichten. Und Sicherheit ist das absolute A und O eines Browsers, noch vor der Rendering-Qualität.
Tja,
anscheinend ist es nach langem mal wieder Zeit ein wenig zu trollen.
Zitat:“Interessanterweise wurde auch mitgeteilt, dass sich die Sicherheitslücken von insgesamt 51 auf 2 verringern würden, hätten die Entwickler die Content Security Policies von Google eingehalten.“
Na super, dahinter verbirgt sich das gute alte XSS. Der alte Kampf Webservice vs. XSS. Google scheint sich für eine Policy Variante entschieden zu haben. Normalerweise stehen Entwicklern ja nur JSONP oder CROS zur Verfügung, welche aber serverseitig dies explizit unterstützen müssen.
Durch die Policy Variante stehen dem Einbinden von externen Webservices keine Schranken im Weg. Der Entwickler muss halt bloß angeben, welche Services er nutzen will (bzw. dass er keine externen nutzen möchte).
BTW. Bla bla blub Mozilla ist viel besser (sprich sicherer), Content Security Policy ist als Draft Paper im W3C im Netz zu finden und in Mozilla „Produkten“ enthalten, sprich Firefox, SeaMonkey, Thunderbird.
Insgesamt ist es positiv zu bewerten, dass Chrome dies auch jetzt unterstützt. Es fehlt nämlich dringend eine sicher Methode externe Webservices zu nutzen. Durch Googles Beteiligung und Implementierung in Chrome steigt die Chance, dass sich ein Standard durchsetzt.
So, normalerweise würde ich sagen, „Macht mich rot“, geht hier aber nicht, also bin ich auf Gegenkommentare gespannt.
Komischerweise sprichst du von Trollen, tust es aber als einziger, denn anders kann ich dein „bla bla blub“ und deine aus dem Zusammenhang gezogenen Aussagen nicht interpretieren. Niemand hier sagt, dass Mozilla *besser* als wer anderes wäre, das ist hier nämlich gar nicht das Thema. Es geht um Sicherheitslücken in Add-ons und darum, dass andere Browserhersteller (da zählen genauso Safari und Opera, wie du lesen könntest, würdest du den kompletten Beitrag lesen) nicht so extreme Zahlen an Add-ons mit Schwachstellen aufweisen. Und dass es, vollkommen unabhängig davon, Aufgabe des Browserherstellers ist, für ein sicheres Umfeld zu sorgen. Bevor du also anderen Worte in den Mund legst, solltest du erst einmal lesen, was wirklich geschrieben steht. Das ist nämlich nicht das gleiche wie das, was du unterstellst.
Mit trollen meinte ich MICH. So gesehen liegst Du genau richtig!
Entschuldige, falls ich mich missverständlich diesbezüglich ausgedrückt habe.
Fakt bleibt aber:
49 der 51 Sicherheitslöcher sind den Entwickler zuzuschreiben, die es nicht schaffen sich auf dem neusten (naja schon seit Firefox 4 enthalten) Stand zu halten!
Content Security Policy ist eine wichtige und *längst* nötige Maßnahme.
Btw. Du hast explizit Mozilla genannt und Mozilla nutzt diese Technik auch (Gottseidank!), wenn Opera und Safari dies nicht nutzen, bleibt Ihnen nur die Möglichkeiten über JSONP (vielleicht auch CORS). Das macht es nicht sicherer sondern diese Browser eingeschränkter und anfälliger für XSS!
Und zu Deiner letzten Aussage: “ Bevor du also anderen Worte in den Mund legst, solltest du erst einmal lesen, was wirklich geschrieben steht. Das ist nämlich nicht das gleiche wie das, was du unterstellst.“
Siehe Deinen ersten Post:“Nicht grundlos gibt es derart hohe Zahlen bei Mozilla nicht.“
Ist ja nicht wirklich überraschend und das man durch Plugins die Angriffsfläche erhöht sollte auch jedem klar sein.
Denke aber nicht das sich ein Angriff lohnen würde, weil die Zielgruppe doch ziemlich klein ist.
Außerdem finde ich es ganz schön gewaagt, die anderen Erweiterungen als sicher zu bezeichnen. Die Frage ist genau wie bei Bugs eher: Wie viele Sicherheitslücken und wie schwerwiegend sind die?
Das ganze ist wohl eh weniger tragisch, wenn man sich die erste Grafik im Orginalartikel anschaut:
http://www.adrienneporterfelt.com/blog/?p=226
Der allergrößte Teil der Lücken scheint „nur“ in öffentlichen Netzen wirklich auswirkungen zu haben. Wer dort unterwegs ist hat eh ganz andere Probleme 😀
Die im Report geschilderten Angrffsvektoren sollten zum Großteil auf allen Browser, die nicht ähnliche Maßnahmen wie Content Security Policy (CSP) ergreifen existieren. Mit 57% der Szenarien dominiert ja, das exploiten von HTTP Skript Tags; also das ein Angreifer mittels Man-In-The-Middle Attacke (MITM) im WLAN/LAN das extern gezogene Skript manipuliert oder austauscht.
Auch der 1 Fall (im Report 2% der Vulnerabilities) ist schön, da wird ein eval() zum parsen von JSON-formatierten Daten genutzt! Eval() sollte bekanntermaßen nur mit äußerster Vorsicht genutzt werden! Also ich kann Google immer noch keine Schuld zuweisen, ich weiß aber auch nicht wie Entwicklerwerkzeuge für Mozilla Add-On’s dies handhaben, u.U. gibt es da ja automatische Einstellungen/ Hinweise an den Entwickler in der IDE, die ihn auf das Konfigurieren der CRS hinweisen. Der Rest liegt aber auf jeden Fall in der Zuständigkeit des Entwicklers.
– Google Mail-Checker – Version: 3.2
– AdBlock – Version: 2.4.28
mehr Erweiterungen habe ich nicht. Wenn AdBlock betroffen wäre, dann wären gleich 2 Mio User betroffen 😉