|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
Von Anonymer Feigling am Thursday 23. October, 20:21 MET (#1)
|
|
|
|
|
kann mich nicht an das letzte Mal erinnern, muss also schon eine Weile her sein - die Implementation von MS war wirklich löchrig, aber das war ja eh keine vollwertige Java-Implementation.
Ausserdem sehe ich nicht ganz ein, wieso dieser Fehler das Konzept der Sandbox in Frage stellen soll? Scheint mir ein simpler Implementierungsfehler zu sein.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stimmt, das letzte mal das es Probleme mit der Sandbox gab, ist bei in meinem Gedächtnis auch sehr lange her.
So wie das aussieht muss man genau wissen welche Variablen und welche Methoden aufgerufen werden müssen um das auszunutzen. Das bringt mir nur was, wenn ich ein Applett auf einen Server schleusen kann der als vertrauenenswürdig angesehen wird. Dann kann ich mit den Daten rumpfuschen. Sehe ich das so richtig?
Gruß
NSG
--
The 'True' George W. Bush
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stimmt, das letzte mal das es Probleme mit der Sandbox gab, ist bei in meinem Gedächtnis auch sehr lange her.
Guckst Du einfach mal hier: Suns Security FAQ für Java.
Dein Applet kann ruhig auf Tripod liegen und braucht auch nicht signiert werden. Das einzige was Du brauchst, um die Lücke auszunutzen, ist der Byte-Code des anzugreifenden Applets (z.B. Online-Banking): Die Klassenhierachie des Applets ist dank Reflektion-API (j ava .lang.reflect)schnell erfasst. Das API ist sogar so mächtig, dass die statischen Variablen automatische erfasst und der passende Exploit-Code generiert wird.
Noch mal in aller Deutlichkeit: Ich halte dieses Loch für extrem gross, denn im Gegensatz zu esoterischen Bufferoverruns, ist dieses extrem einfach auszunutzen: Rudimentäre Java-Kenntnisse (Variable zuweisen, Klasse definieren, ggf. java.lang.reflect nutzen) genügen, um beliebigen Highlevel-Code in der Sandbox des anderen Applets auszuführen!
Beinahe wäre ich ja noch versucht zu sagen: Welch ein Glück, dass Java-Applets im Web doch nicht so verbreitet hat. Ironischerweise sind Java-Applets aber gerade bei Banken besonders beliebt...
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 24. October, 00:42 MET (#4)
|
|
|
|
|
man könnte damit, über die Nachfrage welches
OS denn auf dem Zielsystem läuft, sogar
den ersten Super-Duper Platform unabhängigen
Wurm/Trojaner entwickeln :)
^^hrhr, nervende Handy´s ? -> die Lösung ! (das Handy für immer aus Applet)
|
|
|
|
|
|
|
|
|
|
|
|
|
Wir wollen jetzt doch mal nicht übertreiben ...
Die Warscheinlichkeit, dass Dein "Haxor" Applet, sponsored by big bad Haxor Site, in einem Browser-Tab läuft, und gleichzeitig Dein "Ziel" Applet von der "good old swiss bank" in der selben Browser/JRE Instanz läuft bereitet mir keine schlaflosen Nächte.
Das gespannte Warten darauf, dass jemand dein böses Applet laufen lässt, bevor und wärend er (lechz) eines deiner bevorzugten Ziel Applets laufen lässt, worauf Du dann eine Aktion im fremden Kontext laufen lassen kannst ist IMHO nicht so erfolgsversprechend.
Wo bleibt denn da die Kreativität? Schreib lieber der netten Dame im zweiten Stock Deiner bevorzugten Bank einen netten, farbigen Werbebrief mit beigelegter CD-Rom und erzähl ihr von den tollen Schriftarten und Cliparts für ihr Outlook, welche sie, als bevorzugte Kundin, für 1 Jahr kostenlos ausprobieren darf, um all ihre Freunde mit Ihren neuen farbigen Mails zu beeindrucken. 4 von 5 Anwender werden Deinen Trojaner schon beim CD Autostart untergejubelt bekommen.
Ne ne, so richtig bunt wird's erst beim Faktor Mensch, lass gut sein mit VMs und Sandboxen.
Solche, und hundert andere Beispiele findest Du übrigens in K.Mitnicks Buch. IMHO ziemlich langweilig.
Doch zuletzt will auch ich Euch etwas über Static Members in Java VMs zu erzählen haben:
In der letzten und neusten JAVA VM aus dem Hause zu Redmond werden Klassen mit Static Members bis zum Browser Neustart gecacht.
Das heisst, Applet A instanziert seine Klasse mit Static-Members und 30 Minuten später besucht der Benutezr irgend eine Webseite mit Applet B, und dieses kann nach wie vor auf die längst vergessene Klasse eines längst "gestorbenen" Applets zugreiffen.
But it's not a Bug, it's a Feature !!
Dank dieser "Eigenart" lässt sich prima clientseitiges-daten-caching implementieren ;-)
PS: Der IE instanziert für jedes Applet eine EIGENE VM falls diese in einem JAR File zur Verfügung gestellt werden. Sind die Klassen "ungepackt" vom Webserver zur verfügung gestellt ist dies nicht der Fall. Warum auch immer ...
3b
Unknown: "If Linux doesn't have the solution, you have the wrong problem."
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 24. October, 02:24 MET (#6)
|
|
|
|
|
wenn man ein ausgezeichnetes konzept wie die jvm sandbox in frage stellt, muss man eine bessere alternative anbieten. die wäre? netzstecker ziehen? ach so.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 24. October, 03:42 MET (#7)
|
|
|
|
|
Guckst Du einfach mal hier: Suns Security FAQ für Java.
Neuester Eintrag ist von November 2002, das IST lange her (IE/Active-X Lücken gibt's etwa 2-mal wöchentlich...). Bin jetzt zu faul um alle Sun-Alerts nach diesem Datum durchzusehen, so in den letzten paar Monaten scheint aber nichts dabei zu sein was Java betrifft.
Ich halte dieses Loch für extrem gross
will ich ja gar nicht erst bestreiten, ich sehe aber immer noch nicht wieso das das Konzept der Sandbox in Frage stellt? Das Konzept ist doch völlig in Ordnung, bloss die Implementierung nicht?
Welch ein Glück, dass Java-Applets im Web doch nicht so verbreitet hat. Ironischerweise sind Java-Applets aber gerade bei Banken besonders beliebt...
ich hoffe doch du schlägst als Alternative nicht irgendein Active-X Control vor, abgesehen davon dass das unter praktisch keinem Betriebssystem läuft dürfte die Sicherheit wohl kaum besser sein...
Interessant ist aber wie lange Sun brauchen wird um diesen Fehler zu beheben, bin mal gespannt.
|
|
|
|
|
|
|
|
|
|
|
|
|
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F57221&zone_32=category%3Asecurit y
Note: SDK and JRE 1.4.2 and later releases for Windows, Linux, and Solaris are not affected.
Version 1.4.2_01 hab ich am 3. Oktober installiert ;)
muss also keine Angst haben.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 24. October, 12:21 MET (#9)
|
|
|
|
|
wenn ich mich nicht irre, ist das ein anderer Bug.
In dem Fall ist die letzte Sicherheitslücke doch nicht allzu lange her...
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 24. October, 23:38 MET (#10)
|
|
|
|
|
|
|
|
|
|
