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.
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.
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.
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.
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.