Mitarbeiter von Security Explorations haben nach eigenen Angaben mehrere schwerwiegende Sicherheitslücken in der Java-Umgebung der Google App Engine gefunden. Die Google App Engine ist die Platform-as-a-Service-Lösung (PaaS) des Unternehmens und damit ein Teil der Google Cloud Platform. Sie erlaubt die Ausführung eigener Anwendungen und unterstützt zahlreiche Programmiersprachen und Frameworks. Viele davon basieren auf der Java-Umgebung.
Den Forschern zufolge ermöglichen die Anfälligkeiten das Einschleusen und Ausführen von Schadcode. Dabei werden die Sicherheitsfunktionen der Sandbox der Java Virtual Machine vollständig ausgehebelt. Die Gesamtzahl der sicherheitsrelevanten Fehler geben sie mit mehr als 30 an. Sie seien nicht in der Lage gewesen, alle Tests abzuschließen, da Google ihr Testkonto für die Google App Engine deaktiviert habe, so die Forscher weiter.
Allerdings räumt Security Explorations Versäumnisse ein, weswegen Googles Vorgehen nicht unbegründet sei. „Das ist ohne Zweifel ein Fehler auf unserer Seite. Diese Woche haben wir etwas aggressiver in der zugrunde liegenden OS-Sandbox herumgestochert und verschiedene Systemaufrufe gestartet, um mehr über den Fehlercode 202 und die Sandbox selbst zu erfahren.“
Das Sicherheitsunternehmen hofft nun, dass Google es ihnen ermöglicht, die Versuche fortzuführen. Generell unterstütze der Internetkonzern die Bemühungen von Sicherheitsforschern.
Die Google App Engine erlaubt lediglich den Zugriff auf einen Teil der Klassen der JRE Standard Edition, die JRE Class White List genannt werden. Die Forscher waren jedoch in der Lage, diese Whitelist zu verlassen und auf alle Klassen der Java Runtime Environment (JRE) zuzugreifen. Insgesamt entdeckten sie 22 Bugs in der Sandbox, von denen sie 17 benutzen konnten, um nativen Code außerhalb der Sandbox auszuführen.
[mit Material von Larry Seltzer, ZDNet.com]
Tipp: Wie gut kennen Sie Google? Testen Sie Ihr Wissen – mit dem Quiz auf silicon.de.
Neueste Kommentare
14 Kommentare zu Mehrere Schwachstellen in Google App Engine entdeckt
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
An alle die irgendwas schrieben und keine Ahnung vom programmieren haben, Java ist eine Programmiersprache. Jeder kann diese nutzen, jedoch kannst die die Sicherheit nicht selbst bestimmen, da du nicht dazu befugt bist, weswegen es
1. Unter anderem NIE vorinstalliert war/ist auf Windows
2. Apple die Möglichkeit aufzeigt es unter OSX zu deaktivieren.
Am WebKit z.B. darf jeder der es benutzt auch Korrekturen ausführen und/oder eigenen code einfügen, was auch so ziemlich alle tun, siehe update logs von z.b. ios 8.x.x.
Man kann natürlich etwas programmieren und dabei selbst ziemlich viele Anfälligkeiten wie z.B. an für Konstanten sinnvollen Stellen Variablen anzulegen, um mal was einfaches zu nennen, das auch Laien schnell nachvollziehen können. ABER Google programmiert auch nicht erst seit gestern, daher bezweifle ich das und denke, das die Sicherheitsforscher durch den Ausbruch aus der Klasse White list eher einen Schutzmechanismus von Java geknackt haben.
Das werden wir in nächster Zeit dann sehen.
Warum wird schon wieder über Appple diskutiert, es geht um GOOGLE und seine verbugte Engine. Meine Güte, was soll der Mist?
Es wird über Apple diskutiert, weil der erste Kommentator Apple in’s Spiel gebracht hat und es war kein Androide, sondern ein Appler!
@Namenlosen
NACHTRAG:
Apple liefert mit OS-X auch JAVA aus.
D.h. ein Java Fehler in der Sandbox wird beim Fix durch Oracle auch ein Fix für Java für OS-X nach sich ziehen….
So viel zu Deinem OS-X Kenntnissen…
Link:
http://support.apple.com/kb/DL1572?viewlocale=de_DE&locale=de_DE
Hallo C
zu deinen OS X Kenntnissen:
OS X läuft auch ohne Java, ich habe es deaktiviert. Das ist der Unterschied zum Google Programm, da Google wie bei Android fast immer auf Java setzt. Da Java nicht die bevorzugte Programmiersprache unter OS X ist, laufen alle Programme von Apple, MS und anderen trotzdem.
Die vielen Anfälligkeiten von Java und das Warten auf Oracle interessieren mich schon lange nicht mehr.
Übrigens weist Apple auf die Möglichkeit der Deaktivierung hin.
Ok, WDSE, Du hast Java deaktiviert.
Ich finde es sehr gut, dass Du weißt was Du tust und warum Du es tust.
Ich bin aber ganz sicher, dass es eine nicht unerhebliche Anzahl Nutzer gibt, die sich nicht auf IT-Seiten rumtreiben und DEINE Kenntnisse haben und deshalb auch weiter mit Java arbeiten/müssen.
Außerdem werden doch die Produkte von Apple auch hier von den Applern damit beworben, dass man kein Bastler sein muss wenn man damit arbeiten will, sondern alles sooo einfach ist. ;)
Hallo WDSE,
Danke für den Hinweis, das war mir schon bekannt (die De-Aktivierungs-Option unter OS-X von Java). Das gilt übrigens auch für andere OS-Plattformen (z. B. Windows).
Fakt ist, dass der Apfel Java als OS-Bestandteil mit ausliefert – und bei Major-Bugs von JAVA da immer Patches (so denn Oracle einen FIX liefert) nachliefern muss, auch wenn der User Java deaktiviert hat.
Seinerzeit hat S. Jobs den Adobe Flash-Player rausgeworfen.
Ich nutze diese Software auch generell nicht – zu viele Bugs.
Java gehört ebenso nicht auf dem System. Egal welches OS.
Tatsache ist aber auch, dass viele Anwendungs-Systeme auf Java basieren. Die Nutzer sollten langsam in die Pötte kommen und das Zeugs eliminieren. Wird aber eine ganze Zeit benötigen.
„Write Once, run many“ klang damals zu gut…
Das kann man auch nur wenn man Programme wie z.B. Photoshop CS5 nicht verwendet, da solche Java voraussetzen. Windows läuft auch ohne Java, dieses muss man selbst erst installieren, wenn man es benötigt. Bringt dennoch nichts, wenn man es braucht um Programme zu installieren.
@Namenlosen
Ich kommentiere hier nur, weil Du mich direkt angesprochen hast.
Die Sicherheits-Firma hat JAVA Lücken entdeckt.
Java = SUN = Oracle, nicht Google. Google nutzt das in seiner Cloud/PaaS Service nur (es sei denn, sie hätten JAVA dediziert für sich selbst am Quell-Code direkt angepasst und in deren eigenen Google-JAVA Anpassungen entsteht der Fehler).
Da die JAVA Sandbox betroffen ist, muss Oracle ran. Das ist Original SUN/Oracle Angelegenheit, wenn die JAVA Sandbox überwunden wird.
Beide Firmen haben blöd gehandelt.
Die Security Firma hätte Google informieren sollen, nicht die Öffentlichkeit. Google hätte denen den Account nicht sperren dürfen, sondern auf die Entdeckung weiterer Lücken drängen sollen.
Netter Versuch, aber ganz so eindeutig ist die Sache nicht. Das betrifft aber ganz sicher Googles Sicherheitskonzept, und das nicht nur, weil da Java genutzt wird:
„mehrere schwerwiegende Sicherheitslücken in der Java-Umgebung der Google App Engine gefunden.“
Damit ist ganz offensichtlich das Zusammenspiel zwischen Java und der Google App Engine gemeint.
„ermöglichen die Anfälligkeiten das Einschleusen und Ausführen von Schadcode. Dabei werden die Sicherheitsfunktionen der Sandbox der Java Virtual Machine vollständig ausgehebelt.“
Das ist dann doch ganz sicher ein Google Problem, denn als User ist es mir egal, was Google einsetzt, wenn die Sicherheit gefährdet ist, ist Google mein Ansprechpartner. Aber da Google weiteren Untersuchungen einen Riegel vorgeschoben hat …
Und wenn Du gleich den ersten Link angeklickt hättest, und nicht so vorschnell geantwortet hättest, wärst Du auf diese Aussagen gestoßen:
–> gleich als erstes konnte das GAE Whitelisting ausgehebelt werden, und das SOLLTE Google interessieren, denn Google muss diese Lücke nun schließen. Oracle schert sich nicht darum, was mit ihrem Java passiert.
„We discovered multiple security issues in Google App Engine that allow for a complete Java VM security sandbox escape.
There are more issues pending verification – we estimate them to be in the range of 30+ in total.
Quick summary of our developments so far:
– we bypassed GAE whitelisting of JRE classes / achieved complete Java VM security sandbox escape (17 full sandbox bypass PoC codes exploiting 22 issues in total),
– we achieved native code execution (ability to issue arbitrary library / system calls),
– we gained access to the files (binary / classes) comprising the JRE sandbox, that includes the monster libjavaruntime.so binary (468416808 bytes in total),
– we extracted DWARF info from binary files (type information and such),
– we extracted PROTOBUF definitions from Java classes (description of 57 services in 542 .proto files),
– we extracted PROTOBUF definition from binary files (description of 8 services in 68 .proto files),
– we analyzed the above stuff and learned a lot about the GAE environment for Java sandbox (among others).“
Ach ja: beim SSL Bug hast Du damals doch so schön gehässig mit dem dicken Finger auf Apple gezeigt, und damals (SSL ist ungleich Apple) war für Dich ganz eindeutig Apple verantwortlich.
Offensichtlich misst Du mit zweierlei Maß – denn Google nutzt sogar in Deiner Argumentationskette einfach nur Java (was falsch ist, siehe anderen Kommentar), und ist nun aus Deiner Sicht nicht schuldig, sondern Oracle? Na huch ;-)
Hehehe, und na klar: „Ich kommentiere hier nur, weil Du mich direkt angesprochen hast.“
DAS glaube ich Dir gerne, es geht ja nicht um Apple, da schweigst Du ja eh immer. ;-)
So, genug Zeit vergeudet – enjoy life, und nicht immer durch die ‚Pös-Gut‘ Brille schauen. ;-)
Google sollte sich aber schon Gedanken machen, wenn sie das hier versprechen: „Sie müssen sich keine Gedanken über Hardware, Patches und Sicherungen machen…“ ;-)
http://www.google.com/get/mediatools/develop.html
Das klingt aber nicht gut: „Die Gesamtzahl der sicherheitsrelevanten Fehler geben sie mit mehr als 30 an.“ War die These nicht, Google sei die bessere Software Schmiede? Wie passen da gleich 30 sicherheitsrelevante Schwachstellen ins Bild? ;-)
Oder kocht Google doch nur mit Wasser?
Ein Fall für Captain C – er wird uns sicher gleich erklären, warum das bei Google kein Problem ist, aber dennoch Apple der eigentlich pöse Pursche ist.
Danke, Captain C, so komme ich täglich zu fünf Minuten lachen. ;-)