Die Anwendung
Wir haben eine kleine Java-Anwendung, die einige Camel-Routen verwendet, um hochgeladene Dateien von einem Webserver abzurufen, zu verarbeiten und einige E-Mails mit den Ergebnissen zu versenden.
Der Server, auf dem diese Anwendung ausgeführt wurde, wurde außer Betrieb genommen. Im Moment müssen wir es auf unterlasteter Hardware ausführen, da ich den Administrator nicht davon überzeugen kann, eine JRE auf dem Webserver (der eigentlich ein Mehrzweckserver ist) zu installieren.
Die Furcht
Ich bin selbst Java Application Engineer und schreibe JEE-Code, um B2B-Transaktionen im Wert von zehntausenden Euro pro Woche abzuwickeln. Aber ich habe Probleme, glaubwürdige Quellen zu finden, die den Mythos widerlegen, dass Java per se unsicher ist.
Die beiden Hauptargumente des Administrators gegen die Installation einer JRE:
- Java-Anwendungen beanspruchen meinen gesamten Arbeitsspeicher
- Java ist voll von Schwachstellen
Die Wahrheit?
Wenn es um Java-Anwendungen geht, die RAM auffressen. Nun ... ich würde sagen, wir müssen die richtigen Werte für Xmx einstellen. Erledigt.
Nun gibt es viele Quellen, die über die vielen Schwachstellen von Java sprechen. Diese Quellen richten sich hauptsächlich an Endbenutzer, die ein bestimmtes Betriebssystem von einem Unternehmen in Redmond / USA ausführen. AFAIK: Für nicht gepatchte Versionen des Java-Browser-Plugins, das so konfiguriert ist, dass alle Applets automatisch ausgeführt werden, kann es sehr wahrscheinlich sein, dass sie Opfer einer Infektion werden. Ebenso besteht die Gefahr, sexuell übertragbare Krankheiten zu bekommen, wenn Sie ungeschützten Sex mit jedem in Ihrem Zug haben, während Sie zur Arbeit fahren.
Aber ich konnte niemanden im weltweiten Interwebz finden, der über Serveranwendungen oder JREs spricht, die kopflos laufen. Das ist eine ganz andere Sache.
Oder vermisse ich hier etwas?
[edit 2014-08-28] Klarstellung: Ich mache mir nur Sorgen um Java auf Servern. Ich interessiere mich nicht für Probleme mit dem Java-Plugin und / oder spezifischer in Java entwickelter Software.
Antworten:
Die zusätzliche Sicherheitsoberfläche, die Java in Ihre Umgebung einfügt, ist komplex und es ist wichtig, sie nicht zu ignorieren oder zu vereinfachen.
Erstens gibt es die schreckliche Bilanz, die die JRE für Sicherheitslücken hat. Es ist schwer, auf ein bestimmtes Problem hinzuweisen, und dies ist der beängstigende Teil - die Fehler sind überwiegend nicht spezifizierte Schwachstellen mit nicht spezifizierten Vektoren.
Wenn ich als Sicherheitsberater Klauseln wie "Erlaube einem entfernten Angreifer" lese, ohne deren Bedeutung näher zu bestimmen, kann dies durchaus bedeuten, dass bestimmte Parameter, die in eine bestimmte Funktion gelangen, den anfälligen Zustand auslösen, selbst wenn Sie dies tun laufen nur Code, den Sie geschrieben haben. Und da sie nicht spezifiziert sind, erfahren Sie nicht, ob Sie betroffen waren.
Noch besser ist, dass die von Oracle veröffentlichte Canonical JRE einen festgelegten vierteljährlichen Aktualisierungszyklus für wichtige Aktualisierungen enthält, einschließlich fast aller Sicherheitsaktualisierungen. Sie haben in den letzten vier Jahren insgesamt elf Mal Patches aus Zyklen erstellt. Dies bedeutet, dass Sie möglicherweise bis zu drei Monate nach der Meldung für einen Sicherheitsfehler anfällig sind, bevor Sie eine Lösung finden.
Es gibt andere Probleme mit Java, auf die ich hier nicht eingehen werde, aber es scheint, als gäbe es berechtigte Bedenken, insbesondere für einen Mehrzweckserver. Wenn Sie solche Dinge ausführen müssen, sollten Sie mindestens eine Einzweck-VM dafür erstellen und sie von anderen Dingen isolieren.
Insbesondere wenn es in der JRE eine Fernbedienung gibt, die es einem Angreifer ermöglicht, RCE zu erlangen, und eine in PHP, die dasselbe tut, und eine andere in Ruby, die dasselbe tut, müssen Sie alle drei patchen. Alle drei scheinen eher wahrscheinlich zu sein, und der Angreifer kann auswählen, was am bequemsten ist, und dann den gesamten Server besitzen. Aus diesem Grund sollten wir VMs verwenden, um Software zu trennen, insbesondere fehlerhafte Software wie verwaltete Sprach-Frameworks, und insbesondere solche, die Sicherheitspatches nur viermal im Jahr bündeln Sicherheit.
Hier sind einige CVEs, die ich zur Veranschaulichung aus der verknüpften CVE-Suche von ChrisS ausgewählt habe.
Und mein Favorit, seit ich dort war:
Das ist übrigens nur eine kleine Auswahl.
quelle
Die Alternative zur Verwendung von RAM ist die Verschwendung von RAM. Sie können es nicht für später speichern.
Das ist nicht wirklich wichtig, weil Sie die JVM nicht der Welt aussetzen werden. Ich nehme an, Sie werden keine feindlichen Programme ausführen, und wenn ja, ist Java sicherer als die meisten anderen Sprachen. Entscheidend ist, ob Ihre Anwendungen Schwachstellen aufweisen.
quelle
Stellen Sie ein Unternehmen ein, das statische Analysen für Ihr Programm durchführt. Veracode ist beispielsweise ein Unternehmen, das ich in der Vergangenheit speziell für die Prüfung der Codesicherheit von Java-Programmen eingesetzt habe.
Stellen Sie den Gebührencode Ihres Admin-Teams in Rechnung.
quelle
Erklären Sie, dass alle anderen Sprachen (oder virtuellen Maschinen) durch den Code, der auf ihnen bereitgestellt wird, ebenso wie bei Java unsicher gemacht werden können. Wenn er der Meinung ist, dass die anderen Plattformen von Natur aus sicher sind (oder sicherer als Java), ohne die Sicherheit der Adressen korrekt zu behandeln, ist er ein Wahn.
Ihr Unternehmen hat offensichtlich in die Einstellung eines Java-Entwicklers investiert. Warum weigert sich der Systemadministrator, eine Technologie zu unterstützen, für die sich das Unternehmen entschieden hat?
Ich würde die Frage umdrehen und ihn fragen, welche Alternativen er vorschlägt und wie diese sicherer sind als die neueste verfügbare Server-JRE, und zwar in ganz bestimmten Begriffen. Zeigen Sie in der Zwischenzeit, dass Sie Ihre Technologie und die mögliche Angriffsfläche verstehen und dass Sie daran gearbeitet haben, diese zu minimieren (z. B. unnötige Frameworks, Code von Drittanbietern usw.). Lassen Sie Ihren Code überprüfen, suchen Sie nach Schwachstellen, die für die Frameworks veröffentlicht wurden, auf die Sie sich in den letzten X Jahren verlassen haben, vergleichen Sie sie mit anderen Sprachen / Frameworks (stellen Sie sicher, dass Sie auch Markeshare einbeziehen, undurchsichtige Frameworks ohne veröffentlichte Schwachstellen bedeuten nichts).
Wir können unmöglich wissen, wie die gesamte Konvertierung zwischen Ihnen beiden stattgefunden hat, aber wenn das seine beiden Argumente waren, haben Sie es vermutlich mit einem Junior-Systemadministrator zu tun. Hat er Erfahrung mit Java-Anwendungsservern? Vielleicht ist er unbehaglich mit der Technologie und hat Angst, etwas in Produktion zu bringen, ohne es gründlich zu verstehen (dann gute Sysadmin-Einstellung).
quelle