Googles Heuchelei mit Project Zero

Google verdient sein Geld vornehmlich mit Werbung im Web. Wenn die User sich sicher fühlen im Web, gibt es mehr Einnahmen für Google. Also hat Google beschlossen, Fehler in aller Art Software aufzufinden, die mit dem Internet in Kontakt kommt. Dazu haben sie ein paar eigene Hacker und ein paar neu rekrutierte Hacker im Project Zero zusammengefaßt. An manche Namen in dem Team, wie den von Tavis Ormandy, erinnere ich mich gut. Das Project Zero liefert seit 2014 Ergebnisse.

Google fühlte sich zuvor so ohnmächtig, weil die Hersteller von Software außerhalb von Google für dermaßen viel Unsicherheit sorgen. Und das geht ja nicht. Da macht Google jetzt den Batman und rettet die Welt vor den Bugs in der Software der Loser.

Sicherheit wird jedoch nicht in erster Linie durch Bugs bedroht, sondern durch grundsätzliche Architektur- und Design-Fehler. Wenn Architektur und Software-Design top sind, erst dann werden Bugs relevant. Denn wo keine Mauer ist, um Eindringlinge aufzuhalten, braucht man auch nicht nach Löchern zu suchen, durch die sie heimlich schlüpfen könnten.

Den Splitter im fremden Auge …

… sehen sie, aber nicht den Balken im eigenen. Hier sind ein paar von Googles größeren Versäumnissen, die ihre Bugsuche ad absurdum führen.

Keine Verschlüsselung

Google war lange Zeit so naiv, daß sie eigene und angemietete Glasfaserkabel, über die die Kommunikation zwischen den Google Rechenzentren läuft, unverschlüsselt benutzt hatten. Erst nachdem herauskam, daß mehrere Geheimdienste diese Kabel praktisch auf der Kuhwiese in aller Ruhe abhören, sah sich das Sicherheits-Genie Google dazu genötigt, die Kommunikation zu verschlüsseln.

Da hier die völlig unverschlüsselte Kommmunikation zwischen Googles Rechenzentren lange Zeit ungestört mitgeschnitten wurde von mindestens dem amerikanischen und dem britischen Geheimdienst, kann man davon ausgehen, das NSA und GCHQ alle Interna über Google und alles über Googles User wissen. Alles.

Googles Project Zero würde Sinn ergeben, wenn hier verschlüsselt worden wäre (also kein Design-Fehler bestanden hätte) und man nach möglichen Bugs in der Verschlüsselung gesucht hätte. Aber wo null Sicherheit eingeplant ist, braucht es keine Bugs. Hätten sie hier einfach mal überhaupt verschlüsselt, wäre mehr gewonnen gewesen als durch 2000 Jahre Project Zero. Sie sollten sich mal lieber mit den wesentlichen Punkten beschäftigen als mit Kleinscheiß.

Keine Ende-zu-Ende-Verschlüsselung

Google erzählt hier, daß sie nach dem oben beschriebenen Desaster die Kommunikation zwischen ihren Servern verschlüsseln. Geile Idee, leider viel zu spät. Ein Netzwerkadmin ohne Schulabschluß wäre da eher draufgekommen und zwar im besoffenem Zustand. Googles Genies und hochbezahlte Spezialisten waren nicht ganz so schnell beim Lernen der Grundlagen von Sicherheit.

An derselben Stelle erzählt Google auch stolz, daß Gmail nun nur noch mit HTTPS arbeitet. Für einen Anfänger ist das ja ganz toll, aber damit sind die Emails nicht sicher, denn sie sind höchstens zwischen dem User und Google verschlüsselt. Google kann die weiterhin komplett lesen. Und Jürgen Schmidt sagt auch ganz richtig, warum: Mit Ende-zu-Ende-Verschlüsselung könnte Google unsere Daten nicht mehr mitlesen und gewinnbringend für seine Werbung auswerten. Allein mit HTTPS geschützt liegen die Mails ja entschlüsselt auf Googles Servern.

Ich hatte "höchstens" geschrieben. Und das bedeutet, wenn ein fauler Proxy dazwischensitzt, dann kann der die HTTPS-Verbindung im Klartext lesen. Ich mache das selbst jeden Tag, um den Daten-Verkehr eigener iOS-Apps während der Entwicklung zu überprüfen. Das einzige, was hilft, ist Ende-zu-Ende-Verschlüsselung wie es Apples iMessage / Messages / Nachrichten macht und wie es Apples Mail leicht unterstützt. Das sind grundlegende wichtige Design-Entscheidungen, die Google absichtlich nicht macht. Ihre Bugsuche können sie sich dann auch schenken.

Keine Bugfixes

Google läßt 2/3 seiner Android-User, also fast eine Milliarde Menschen, in Zahlen 1.000.000.000 Kunden im Regen stehen. Google hat zwar Zeit und Geld, um seinem Project Zero zu frönen, aber bekannte Fehler in eigener Software, die vom größten Teil seiner Android-User verwendet wird, ist ihnen nicht wichtig genug. Das wäre zuviel Arbeit.

So Google sehen also Eure Prioritäten aus? Wenn Ihr das Ziel von Project Zero, Euren Usern mehr Sicherheit zu bieten im Web, selber ernstnehmen würdet, dann würdet Ihr alles daran setzen, diese Unmenge an Usern, den Großteil Eurer Stammkundschaft mit entsprechenden Sicherheits-Updates zu versorgen.

Mit Android 4.4 wurde ein anderer Webbrowser und damit auch ein anderer zugehöriger WebView eingeführt, der allen Apps zur Verfügung steht. Alle älteren Android-Versionen haben einen verwundbaren Standard-Browser und verwundbare Apps, die Webseiten anzeigen (mit dem WebView). Das machen sehr, sehr viele Apps. Auch Werbe-Einblendungen werden damit gerne umgesetzt. Google setzt damit seine User in seinem ureigenen Kerngeschäft Angriffen aus, nur weil sie zu faul sind. Kohle genug haben sie ja. Aber die ist besser im Marketing-wirksamen Project Zero aufgehoben. Und damit ist das Project Zero einfach nur noch Heuchelei. Statt "Don't be evil" wäre hier ein "Don't be a fool" wünschenswert. Wenn Apple 2/3 seiner User in der Schußlinie stehen lassen würde, dann wäre die Hölle los. Aber bei Google? Och, die sind doch so niedlich, die grünen Männchen!

Ungenutzte Security-Features

Ich schaue mir ja nicht nur Apples Systeme an, was sie so an Sicherheit bieten, sondern auch die Konkurrenten wie Windows und Android. Und bei Googles Android stellte sich heraus, daß Android hinterherhinkt, was die Verwendung von aktueller Sicherheits-Technik angeht. Das geht von im Vergleich mit Apple nutzloser Code-Signierung (siehe u.a. Seite 392 bis 394 im Android Hacker's Handbook) bis zu fehlendem Kernel-ASLR. Wobei ASLR nicht so viel bringt, die zwingende Code-Signierung, wie Apple sie umsetzt, hingegen schon. Warum ASLR allgemein, aber insbesondere im Kernel nicht viel nützt, habe ich hier beschrieben.

Dem interessierten Leser sei hierzu das Android Hacker's Handbook empfohlen.

Neben obigen Kritikpunkten, die man dort nachlesen kann, findet sich auf den Seiten 394 bis 396 etwas Erstaunliches: Google hat extra die Library safe_iop entwickelt, die vor Speicherüberläufen sichere Integer-Operationen bietet. Diese Library wird allerdings fast gar nicht in Android benutzt, eine der Funktionen sogar tatsächlich überhaupt kein einziges Mal. Und darüber hinaus verwendet Android auch nur eine alte Version dieser Library.

Hier hat Google einen einfachen Sicherheits-Gewinn einfach brachliegen lassen. Sieht so eine Firma aus, die die Sicherheits-Nummer konsequent durchziehen will zum Schutz ihrer Nutzer, wie sie es mit Project Zero vorgibt? Wohl kaum. Google hat in Wirklichkeit andere Prioritäten. Wie sie auf Seite 422 schreiben, würde Code-Signing, wie iOS es macht, auch Android einen echten Sicherheitsgewinn bringen, aber Google macht das nicht, weil das "einen negativen Effekt auf die offene Natur der Android-App-Entwickler-Community hätte". Na denn. Da ist offensichtlich die Sicherheit der eigenen User weniger wichtig. Und im Project Zero tönt Google, daß das jedoch oberstes Ziel wäre. Haben wir da einen kleinen internen Interessenkonflikt, Google?

Trauriges Fazit

So sehr ich mich auch über jeden gefixten Bug in Apples Systemen freue, die Project Zero zu verdanken sind, so sehr stimmt es mich traurig, daß Googles Vorgehen bei eigener Software in vielen Bereichen weit hinter Apples Systemen herhinkt. Google macht aus kleinen Bugs eine große Nummer und läßt die wirklich wichtigen Arbeiten, die sie in Punkto Sicherheit zu erledigen hätten, links liegen. Mir sind zudem solche Show-Veranstaltungen bezüglich Bug-Hunting zutiefst zuwider. Apple hingegen macht seinen Sicherheits-Job gut und vor allem leise. Allerdings machen Googles Marketing-Leute einen erstklassigen Job :-p

Valid XHTML 1.0!

Besucherzähler


Latest Update: 13. September 2015 at 14:55h (german time)
Link: www.macmark.de/blog/osx_blog_2015-02-a.php
Backlinks-Statistik deaktiviert; kann rechts im Menü eingeschaltet werden.