# Ist die JVM crackbar?



## thewulf00 (4. Jul 2011)

Hallo,

nachdem ich Java sehr mag, liegt es auch nahe, damit Anwendungen zu erstellen, die unsere Firmen(root)server verwalten. Da einige Dinge, die dort zu tun wären, mit dem root-user gemacht werden müssen, haben wir hier eine Diskussion, ob es ein Eindringling durch einen Prozess, der die JVM benutzt, einfacher hat.
Ich meine damit NICHT die Anwendung selbst, sondern lediglich die Tatsache, dass jetzt gerade eine JVM mit root-Rechten läuft.

Also: Ist es einfacher für jemanden, weil eine root-JVM läuft? Kann er da was anstellen?


----------



## faetzminator (4. Jul 2011)

Es empfiehlt sich IMHO überhaupt nicht, die JVM mit root-Rechten auszuführen. Aber in der JVM hast du eine Sandbox. Wenn also die Securityeinstellungen (AFAIK java.policy) richtig eingestellt ist, dass die App nur das kann, was sie benötigt, dann sollte das kein Problem darstellen.


----------



## thewulf00 (4. Jul 2011)

Und wenn die Dinge, die die App macht, auch missbraucht werden können? Sagen wir mal bspw. die App muss mit root-Rechten eine Datei irgendwo im Dateisystem anlegen. Wenn das ein Angreifer tut, könnte er den kompletten Server kompromittieren.


----------



## faetzminator (4. Jul 2011)

Na dann sollte der User (natürlich nicht root!) nur in diesem einen Ordner Rechte besitzen. Aber Daten auf die HD zu schreiben, ist nicht unbedingt die feine Art.


----------



## thewulf00 (4. Jul 2011)

Alles klar. Du antwortest immer, indem Du mein als gegeben hingestelltes Szenario abänderst - das hilft mir leider nicht. 
Man kann sicherlich stundenlang darüber diskutieren, warum man dem Prozess keinesfalls root-Rechte geben muss, weil es hier und da andere Lösungen gibt. Das ist richtig und ich akzeptiere das. Aber für die Fragestellung an sich ist diese Diskussion nichtig, da es als gegeben hingenommen werden sollte - obgleich ich für Deine Anmerkungen dankbar bin, dass es ohne gehen muss.


Edit: Angenommen, ich würde sowas wie Webmin oder Plesk in Java nachbilden. Ich müsste auf sehr viele Dateien und Verzeichnisse Zugriff bekommen. Egal ob ich nun den bequemen root-Weg gehe, oder alles granular mit Usern und Gruppen aufschlüssle, hat doch jemand, der die JVM kompromittiert, dann die gleichen Rechte, nicht wahr?


----------



## ice-breaker (4. Jul 2011)

Man lässt eine Software nur im absoluten Notfall im Root laufen. Aus welchen Gründen sollte die Software denn bei euch unbedingt Root-Rechte benötigen?

Jede Software ist crackbar, auch das Sandbox-Modell der JVM hat hinundwieder Schwachstellen, aber genau deswegen wurden ja auch die Linux-User erfunden, damit nicht alles mit Admin-rechen läuft. Ich würde aber mal pauschal sagen, dass die Gefahr einer solchen Lücke in der JVM geringer ist, als wenn man die Software in C(++) entwickeln würde (meine Meinung).


----------



## faetzminator (4. Jul 2011)

thewulf00 hat gesagt.:


> Alles klar. Du antwortest immer, indem Du mein als gegeben hingestelltes Szenario abänderst - das hilft mir leider nicht.



Ok, gehen wir davon aus, dass serverseitig Dateien erstellt / geändert / ... werden müssen. Dabei musst du halt beachten, dass sicher nicht der Client einen absoluten Pfad mitschicken kann. Ansonsten könnte er dir z.B. "/etc/passwd" o.ä. modifizieren.
Es wär vielleicht von Vorteil zu erwähnen, was der Client / User bestimmen kann und was nicht.


----------



## thewulf00 (4. Jul 2011)

ice-breaker hat gesagt.:


> Man lässt eine Software nur im absoluten Notfall im Root laufen. Aus welchen Gründen sollte die Software denn bei euch unbedingt Root-Rechte benötigen?


Ein Beispiel habe ich per Edit eingefügt.





ice-breaker hat gesagt.:


> Jede Software ist crackbar, auch das Sandbox-Modell der JVM hat hinundwieder Schwachstellen, aber genau deswegen wurden ja auch die Linux-User erfunden, damit nicht alles mit Admin-rechen läuft. Ich würde aber mal pauschal sagen, dass die Gefahr einer solchen Lücke in der JVM geringer ist, als wenn man die Software in C(++) entwickeln würde (meine Meinung).


Das ist sicherlich richtig. Der Nachteil ist aber, dass eine selbst entwickelte, private C++-Software unbekannt ist, und der Angreifer keinen Vektor hat, d.h. keine fertigen Exploits findet (von Lib-Schwachstellen abgesehen). Wenn aber nun eine JVM läuft, dann ist die App egal, denn die JVM ist ein großes, sehr bekanntes Ding, das jeder analysieren kann. Genau dort liegt der Hund meines Erachtens begraben.


----------



## thewulf00 (4. Jul 2011)

faetzminator hat gesagt.:


> Ok, gehen wir davon aus, dass serverseitig Dateien erstellt / geändert / ... werden müssen. Dabei musst du halt beachten, dass sicher nicht der Client einen absoluten Pfad mitschicken kann. Ansonsten könnte er dir z.B. "/etc/passwd" o.ä. modifizieren.
> Es wär vielleicht von Vorteil zu erwähnen, was der Client / User bestimmen kann und was nicht.


Ich vermute fast, Du gehst von einer Webanwendung aus. Ich meinte hier aber mehr oder weniger selbstständige Software, die nach vorgegebenen Regeln im Hintergrund agiert - ohne Nutzer- oder gar Kundeneingriff.
Wie gesagt: Betrachten wir das Szenario mal von der Applikation unabhängig - die soll hier nicht das Problem sein.


----------



## faetzminator (4. Jul 2011)

Naja, wenn der [c]chown[/c] der App auf root lautet und die anderen User keine Schreibberechtigung für diese App (und natürlich auch die Files der JVM haben), dann kann ein schädlicher Prozess auch nichts modifizieren. Irgendwie hab ich immer noch nicht begriffen, was für Attacken du dir vorstellst - wenn das keine Webanwendung sein soll. Bitte beschreib, was für Schnittstellen du wohin hast.


----------



## thewulf00 (4. Jul 2011)

Nun, unterm Strich gehts darum, dass ein Angreifer durch ein Sicherheitsloch auf den Server kommt. Da hat er natürlich erstmal nur die Rechte des betroffenen Prozesses, z.B. www-data wegen des Webservers.
Nun sieht er, dass auf dem Server eine JVM läuft, mit einer oder mehreren Anwendungen. Und das Diskussionsthema meiner IT-Runde war nun, ob die als root laufende JVM das Eindringen und somit erschleichen von root-Rechten einfacher macht.


----------



## fastjack (4. Jul 2011)

Okay, lassen wir mal den Rootzugang weg. Ich glaube der TO meint die Manipulation einer Anwendung in der VM oder die der VM selbst.
Eine Anwendung in der z.B. Klassen nachgeladen werden (Class.forName), oder Klassen erzeugt werden (durch generierten Bytecode) ist sozusagen direkt angreifbar, ohne die VM zu beeinflussen. Nur der Klassenpfad oder die Eingabe zur Klassengenerierung müssen verändert werden, schon sind ganz neue Möglichkeiten offen. Das setzt natürlich ein wenig Kenntnis der Anwendung voraus. Bleibt noch die direkte Manipulation von Class-Dateien, die auch möglich ist. 
Das der Hacken der VM selbst sollte wohl auch möglich sein, es sind ja genügend Security-Updates erschienen...


----------



## ice-breaker (4. Jul 2011)

thewulf00 hat gesagt.:


> Der Nachteil ist aber, dass eine selbst entwickelte, private C++-Software unbekannt ist, und der Angreifer keinen Vektor hat, d.h. keine fertigen Exploits findet (von Lib-Schwachstellen abgesehen).


_Security through obscurity_ bietet *keine* Sicherheit.

Wenn du deinen Gedanken weiterverfolgst dann darfst du auch keine einzige fremde Library verwenden, erst dann hast du eine Argumentationsgleichheit zwischen einer "privaten C++-Software" und der JVM - und wer entwickelt heutzutage noch ohne fremde Libraries?
Auch der C++-Compiler kann Schwachstellen bzw. wenigstens DoS-Schwachstellen (Floating Point Bug in gcc) verursachen.


----------



## thewulf00 (4. Jul 2011)

fastjack hat gesagt.:


> Okay, lassen wir mal den Rootzugang weg. Ich glaube der TO meint die Manipulation einer Anwendung in der VM oder die der VM selbst.


Das klingt schon eher nach dem, was ich meinte 




fastjack hat gesagt.:


> Das der Hacken der VM selbst sollte wohl auch möglich sein, es sind ja genügend Security-Updates erschienen...


Was könnte ein Angreifer denn dadurch erreichen? Der absolute Super-GAU wäre ja eine root-Shell.




ice-breaker hat gesagt.:


> _Security through obscurity_ bietet *keine* Sicherheit.


Richtig, aber das war ja auch nie das Thema. Denn wenn der Angreifer die Software die da läuft, nicht kennt, also weder Sinn und Zweck noch Code, dann kann er auch nicht darauf vertrauen, Sicherheitslücken auf gut Glück auszunutzen. Die JVM kennt er aber (möglicherweise).




ice-breaker hat gesagt.:


> Wenn du deinen Gedanken weiterverfolgst dann darfst du auch keine einzige fremde Library verwenden, erst dann hast du eine Argumentationsgleichheit zwischen einer "privaten C++-Software" und der JVM - und wer entwickelt heutzutage noch ohne fremde Libraries?
> Auch der C++-Compiler kann Schwachstellen bzw. wenigstens DoS-Schwachstellen (Floating Point Bug in gcc) verursachen.


Ja, ich dachte mir schon, dass dieses Argument hier kommen wird. Zu meiner Verteidigung kann ich nur hinzufügen, dass diese kompromittierten Libs erst wirksam werden, wenn die Software erneut gestartet wird. Eine dauerhaft im Hintergrund laufende Applikation kann er so nicht anfassen.
Ach ja nochwas: Wenn der Eindringlich bereits so weit vorgedrungen ist, dass er System-Libs ersetzen/ändern kann, dann ist die Frage nach dem Cracken der VM hinfällig.



Um der ganzen (nebenher)Problematik mal den Kern zu nehmen, hier mal ein Beispiel:
Ein Angreifer findet ein Upload-Script für Bilder in einer privaten Webseite. Diese Webseite liegt bei einem Massenhoster. Nun findet er eine Möglichkeit, eine Lücke auszunutzen und lädt eine PHP-Datei hoch, die weitere Dinge mit den Rechten des Webservers tun kann. Also lässt er sich eine Prozessliste anzeigen.
Nun sieht er: Gut, hier läuft eine unbekannte Applikation XYZ als root - ist das C++? Ist das ein Script? Vielleicht Erlang? Er weiß es nicht. Sich weiter darum zu kümmern, macht keinen Sinn.
Doch plötzlich sieht er: Ach da läuft ja Java als root - er bekommt glänzende Augen. Die App darunter ist ihm egal, die JVM ist sein Ziel. Also nimmt er sich die Prozess-ID und die Security-Meldungen der letzten Monate.
Kann er hier weiter kommen?


----------



## schlingel (4. Jul 2011)

Ja natürlich.

Wenn ein Angreifer sich auf ein Program einschießt - und auf eines mit root-Rechten wird er das wahrscheinlich auch tun - wird er es knacken. Die Frage ist *nie* ob, sondern nur *wann*.

Prinzipiell gehört die Maschine dem Angreifer sobald er solch einen Prozess knacken konnte.


----------



## Spacerat (4. Jul 2011)

Kurz und bündig: Wenn ein Angreifer unbedingt in ein System will, findet er einen Weg, selbst wenn's länger dauert. Es ist müssig, sich darüber zu unterhalten, ob dafür nun eine JVM mit Rootrechten oder eine beliebige andere Anwendung mit eben solchen Rechten verantwortlich ist. Es ist doch beinah so, dass man pro übertragenes Kilobyte eine Sicherheitslücke schliessen muß. Und wenn es dann schon eine VM sein muß, dann kann die Anwendung die darin läuft unter Umständen natürlich auch dazu misbraucht werden.


----------



## thewulf00 (4. Jul 2011)

schlingel hat gesagt.:


> Wenn ein Angreifer sich auf ein Program einschießt - und auf eines mit root-Rechten wird er das wahrscheinlich auch tun - wird er es knacken. Die Frage ist *nie* ob, sondern nur *wann*.


Das ist natürlich richtig. So stehts im Leerbuch. Die hier pragmatischen Gedanken weichen allerdings etwas ab. Man geht hier vom größten Schaden aus, den ein Eindringlich anrichten könnte - dazu setzt man maximales Wissen/viel Erfahrung voraus. Nach meinen bisherigen Erfahrungen ist das aber nicht so. Ich möchte hier die Gefahr keinesfalls kleinreden! Ich möchte nur die Gefahr, die eine JVM auf einen Server ausübt, genauer untersuchen.




schlingel hat gesagt.:


> Prinzipiell gehört die Maschine dem Angreifer sobald er solch einen Prozess knacken konnte.


Das stimmt. Und deshalb ist in dem von mir beschriebenen Szenario die JVM die letzte Bastion - deshalb ist diese Frage umso wichtiger.


----------



## thewulf00 (4. Jul 2011)

Spacerat hat gesagt.:


> wenn es dann schon eine JVM sein muß, [...]


Was meinst Du denn damit? Ist davon generell abzuraten?


----------



## Spacerat (4. Jul 2011)

Habe ich bereits verbessert. Ist im Prinzip bei allen VM's so. Kommt halt auf die Anwendung und den damit verbundenen Sicherheitslecks an. Absolute Sicherheit erlangt man nur auf einem netzwerklosem diskless System, bzw. auf Systemen, die von der "Aussenwelt" völlig isoliert sind. Warum also generell davon abraten? Es gibt Anwendungen, die 1000 mal unsicherer sind aber auch welche die 1000 mal sicherer sind als Java. Das macht Java zwar nicht besser, aber auch nicht schlechter.


----------



## fastjack (4. Jul 2011)

Ich denke mal alles ist irgendwie hackbar. Wenn man es genau betrachtet Hardware auch (Überbrücken etc.). Das mit den fremden Libs ist so eine Sache, sind sie sicher, benutzt man sie, haben sie Schwachstellen, naja dann eben nicht.
Übrigens Root-Zugriff ist auch nicht immer das wahre. Manchmal reicht es schon, wenn man die Verschlüsselung von daten umgehen kann oder ähnliches. Beim Rootzugang habe ich dann Zugriff auf die verschlüsselten Daten, naja, nicht das was ich eigentlich will  Bei der "Direkteinspritzung" kann ich mir die verschlüsselten Daten (entschlüsselt) mailen lassen, weil die Anwendung sie mir freundlicher aufbereitet, weist Du was ich meine?


----------



## ice-breaker (4. Jul 2011)

thewulf00 hat gesagt.:


> Was könnte ein Angreifer denn dadurch erreichen? Der absolute Super-GAU wäre ja eine root-Shell.


abhängig von den Security Updates, schau sie dir doch an. Eine root-shell bezweifel ich persönlich aber mal, da hätte man dann denke ich von allen IT-Seiten gehört wie unsicher Java doch ist.



thewulf00 hat gesagt.:


> Richtig, aber das war ja auch nie das Thema. Denn wenn der Angreifer die Software die da läuft, nicht kennt, also weder Sinn und Zweck noch Code, dann kann er auch nicht darauf vertrauen, Sicherheitslücken auf gut Glück auszunutzen. Die JVM kennt er aber (möglicherweise).


doch, genau das kann er, und aus diesem Grund ist Security through Obscurity nutzlos.
Man kann systematisch einfach die Anwendung mit defektem Input füttern und hoffen, dass man sieht, dass etwas schief lief, und dann probiert man einfach weiter. Das ist genauso wie eine Blind-Sql-Injection, und da argumentiert auch niemand, dass der Angreifer weder Tabellen noch Spalten kennt.



thewulf00 hat gesagt.:


> Ja, ich dachte mir schon, dass dieses Argument hier kommen wird. Zu meiner Verteidigung kann ich nur hinzufügen, dass diese kompromittierten Libs erst wirksam werden, wenn die Software erneut gestartet wird. Eine dauerhaft im Hintergrund laufende Applikation kann er so nicht anfassen.
> Ach ja nochwas: Wenn der Eindringlich bereits so weit vorgedrungen ist, dass er System-Libs ersetzen/ändern kann, dann ist die Frage nach dem Cracken der VM hinfällig.


Die JVM ist genauso anfällig wie Libs, und hier meine ich nicht, dass kompromittierte Libs geladen werden. Denn die Hauptschwachstellen sind Buffer-Overflows und dergleichen und die kann ein Angreifer eben im laufenden Betrieb ausnutzen, dagegen sind deine Libraries als auch die Implementierung der JVM nicht "sicher". Es kann immer eine Schwachstelle vorhanden sein.
Von daher hat eben die JVM die gleichen Angriffsvektoren wie jede andere C++-Software, es muss eine Lücke in der C++-Implementierung gefunden werden, die sich im laufenden Betrieb ausnutzen lässt, und da sind eben Buffer Overflows das größte Risiko.



thewulf00 hat gesagt.:


> Nun sieht er: Gut, hier läuft eine unbekannte Applikation XYZ als root - ist das C++? Ist das ein Script? Vielleicht Erlang? Er weiß es nicht. Sich weiter darum zu kümmern, macht keinen Sinn.
> Doch plötzlich sieht er: Ach da läuft ja Java als root - er bekommt glänzende Augen.


schonmal der falsche Ansatz 
Der Angreifer wird erstmal schauen ob es Fehler im Betriebssystem, Rechtemangement oder ähnlichem gibt. Hat er da keinen Erfolg, schaut er sich jede bekannte laufende Sofware an, also dein Apache, dein PHP und deine Java-VM.
Sollte er bei allem dem kein Erfolg haben, wird er auch die unbekannten Prozesse angreifen, und über das PHP eine Shell installieren und systematisch mit fertigen Tools deine unbekannte Software angreifen, sollte da ein Fehler vorhanden sein, wird der sehr schnell gefunden.



thewulf00 hat gesagt.:


> Die App darunter ist ihm egal, die JVM ist sein Ziel. Also nimmt er sich die Prozess-ID und die Security-Meldungen der letzten Monate.
> Kann er hier weiter kommen?


natürlich kann er da weiterkommen 
Das kann er aber auch mit dem PHP und Apache aus deinem Beispiel. Oh mein Gott, also implementieren wir beides selbst, damit ein Angreifer es nicht ausnutzen kann (Analogie zu der "Java vs. C++"-These )

Wenn ihr die Software auf eurem Server nicht aktualisiert, dann seit ihr selbst Schuld, und das meine ich ernst.
Denn damit öffnet ihr selbst jedem Script-Kiddie Tür und Tor, spielt ihr aber regelmäßig Bugfixes ein und aktualisiert die Software, dann habt ihr auch keine Probleme und die JVM ist genauso sicher wie eine closed source C++-Software.




Deine These bzw. Diskussionsgrundlage stützt sich eigentlich nur auf wenige Faktoren:

ihr aktualisiert Java nicht (denn für eine aktuelle Version wird eher unwahrscheinlich eine schwere Lücke bekannt sein)
eure C++-Software ist sicherer als eine JVM-Implementierung an der viele arbeiten
eure C++-Software nutzt keine einzige fremde Library
Um nun zu bewerten, welche der Möglichkeiten sicherer ist, musst du eben einschätzen wie realistisch die Punkte sind, und gerade der 2. Punkt wird nach meiner Erfahrung wahrscheinlich genau umgedreht sein.


----------



## thewulf00 (4. Jul 2011)

Gut, dazu habe ich zwei Anschlussfragen:
- Welche Möglichkeiten habe ich, eine Java-Applikation unmodifizierbar zu erstellen? Soll heißen, sie prüft sich selbst bei Beginn und weicht etwas ab, startet sie nicht, oder macht was-auch-immer.
- Ich habe eben eine Info gefunden, dass man eine JVM in den Kernel compilieren kann, so dass Linux dann nativ Java-Bytecode spricht. Macht soetwas das System sicherer?


----------



## ice-breaker (4. Jul 2011)

thewulf00 hat gesagt.:


> - Welche Möglichkeiten habe ich, eine Java-Applikation unmodifizierbar zu erstellen? Soll heißen, sie prüft sich selbst bei Beginn und weicht etwas ab, startet sie nicht, oder macht was-auch-immer.


gar keine, die Frage ist irgendwie sinnlos, denn sie trifft genauso auf eine C++-Software zu 
Du solltest in deiner Argumentation schon darauf achten, dass du differenzierst, welche Angriffe bei C++ möglich sind, und welche bei Java. Wenn eine Software neustartet muss sie immer den Programmcode laden-



thewulf00 hat gesagt.:


> - Ich habe eben eine Info gefunden, dass man eine JVM in den Kernel compilieren kann, so dass Linux dann nativ Java-Bytecode spricht. Macht soetwas das System sicherer?


ja? nein? vielleicht?
Habe ich noch nie von gehört, und es kann auch nur sicher sein, wenn es aktiv und viel gepflegt wird. Die Idee klingt für mich jedoch mehr nach einem wissenschaftl. Projekt.
Linux kann auch nur den Bytecode ausführen, wenn der Interpreter in den Kernel eingebaut wird, was effektiv bedeutet, dass die kleinste Sicherheitslücke mit Kernel-Rechten läuft, wirklich sicher gell?


----------



## thewulf00 (4. Jul 2011)

ice-breaker hat gesagt.:


> gar keine, die Frage ist irgendwie sinnlos, denn sie trifft genauso auf eine C++-Software zu
> Du solltest in deiner Argumentation schon darauf achten, dass du differenzierst, welche Angriffe bei C++ möglich sind, und welche bei Java. Wenn eine Software neustartet muss sie immer den Programmcode laden-


Hm. Ich habe aber schon von einer Signierungsmöglichkeit der Jar gehört. Stimmt die Signatur nicht, wird die Jar nicht geladen. Ich dachte, man könnte mir das bestätigen oder davor warnen.




ice-breaker hat gesagt.:


> Die Idee klingt für mich jedoch mehr nach einem wissenschaftl. Projekt.
> Linux kann auch nur den Bytecode ausführen, wenn der Interpreter in den Kernel eingebaut wird, was effektiv bedeutet, dass die kleinste Sicherheitslücke mit Kernel-Rechten läuft, wirklich sicher gell?


Nun, das wäre ein Argument, wenn da das User-Prinzip nicht wäre. Aber ich glaube auch, dass diese Lösung nicht ausgereift ist.


----------



## ice-breaker (4. Jul 2011)

thewulf00 hat gesagt.:


> Hm. Ich habe aber schon von einer Signierungsmöglichkeit der Jar gehört. Stimmt die Signatur nicht, wird die Jar nicht geladen. Ich dachte, man könnte mir das bestätigen oder davor warnen.


man kann aber die JVM nicht zwingen nur signierten Code auszuführen  Das Signieren der Jar ist vor allem für die Policys bei Java-Applets nötig.
Selbst wenn du eine Policy für eine Java-Serveranwendung schreibst, dann kann ich meine Jar trotzdem noch von irgendeiner Regestrierungsstelle korrekt signieren lassen 
Wenn jemand schon soweit in den Server eingebrochen ist, dass er das zu startende Programm austauschen/modifizieren kannst, hast du schon längst verloren.
Da das Programm in deinem Szenario jedoch mit Root-Rechten läuft, müsste man auch schon Root-Rechte haben um die Datei auszutauschen


----------



## Empire Phoenix (4. Jul 2011)

Also obs c++ oder java ist ist latte, wenn die firewalls/rechte/gruppenrichtlinien mies konfiguriert sind kann ich dir da auch über telnet deinen Server übernehmen. Die jvm hat so wie jedes andere c++ programma uch hin und wieder lücken, wobei sie weit verbreitet ist, und dadurch sicherlich einen besseren Wartungsstand hat als irgeteine selber geschreibene Application die dann 10 Jahre produktiv benutzt wird.
Wesetlich sinnvoller ist es ein konsequentes Rechtemanagement zu haben, da es einem wenig nutzt wenn  man dann zb nur Selects auf die Datenbasis amchen kann als rootrechte zu haben. AUSSERDEM sollten alle sensitiven Datena uch so behandelt werden,(aka Sony userpasswörter im Klartext ist nogo) DAnn sind selbst erbeutete Daten nahezu wertlos.


----------



## Wildcard (4. Jul 2011)

Nur weil eine VM auf einem Rechner läuft ist sie noch lange nicht von aussen erreichbar.
Welche Schnittstellen bietet die Applikation denn nach aussen?
Wenn du mit Sockets, Webservices, oder ähnliches kommunizierst, dann ist es nicht ausgeschlossen das ein Bug existiert um den VM Prozess zu manipulieren und mit den Rechten des Prozesses zu arbeiten (deshalb soll die Anwendung nicht als root laufen), allerdings ist mir persönlich derzeit keine derartige Schwachstelle bekannt. Bei Bildverarbeitung gab es AFAIR zB mal einen exploit um aus einer Applet Sandbox auszubrechen.
Allerdings halte ich die Gefahr für deutlich geringer als bei zB C Programmen, da die VM selbst sehr gut getestet ist und Anwendungsseitig die verbreiteten Probleme in C, wie Buffer Overflow gar nicht auftreten können.
Man kann natürlich trotzdem  große Sicherheitslücken aufreisen (zB SQL Injection), aber Java gibt einem die Mittel an die Hand um das zu verhindern. Wenn es doch passiert, dann hat es weder mit der programmiersprache, noch der VM zu tun, sondern liegt alleine am entsprechenden Entwickler.


----------

