it-swarm.com.de

Warum höre ich von so vielen Java Unsicherheiten? Sind andere Sprachen sicherer?

Ich mag die Programmiersprache Java] sehr, aber ich höre ständig, wie unsicher sie ist. Wenn Sie "Java unsicher" oder "Java-Schwachstellen" googeln, werden mehrere Artikel darüber angezeigt, warum Sie = deinstallieren oder deaktivieren sollten Java zum Schutz Ihres Computers. Java veröffentlicht häufig eine große Anzahl von Sicherheitspatches gleichzeitig, und dennoch gibt es noch Unmengen von Sicherheitslücken, die gepatcht werden müssen.

Ich verstehe, dass es immer Fehler in der Software geben wird, aber die Anzahl der Schwachstellen Java hatte nicht normal zu sein (oder stelle ich mir das vor?). Noch verwirrender ist, dass es solche gibt Eine einzige architektonische Entscheidung, die diese Sicherheitslücken schafft. Warum nicht dieses Design ändern? Es gibt Unmengen anderer Programmiersprachen, bei denen dieses Problem nicht auftritt. Daher muss es einen besseren Weg geben, was auch immer zu tun Java = macht falsch. Warum ist Java immer noch so unsicher?

104
gsingh2011

Wenn Sie Java wie die meisten anderen Programmiersprachen verwenden, z. B. um eigenständige Anwendungen zu schreiben, ist es nicht weniger sicher als andere Sprachen und sicherer als C oder C++, da keine Pufferüberläufe usw. vorhanden sind.

Aber Java wird regelmäßig als Plugin im Webbrowser verwendet, z. B. ähnlich wie Flash. Da in diesem Fall der Benutzer nicht vertrauenswürdigen Code ausführt, ohne ihn explizit installiert zu haben, besteht die Idee darin, den Code ausführen zu lassen in einer begrenzten Sandbox, in der es nicht möglich sein sollte, gegen das System oder den Benutzer vorzugehen (z. B. lokale Dateien lesen und an die Website senden, das lokale Netzwerk scannen usw.). Und hier ist Java ist in den letzten Jahren gescheitert, z. B. tauchten manchmal täglich neue Fehler auf, die das Entkommen aus dem Sandkasten ermöglichten.

Manchmal führen Fehler im Bytecode-Interpreter oder in nativen Bibliotheken zu Pufferüberläufen und können das System gefährden. In dieser Hinsicht wird Flash jedoch normalerweise als schlechter angesehen.

Und was die anderen Sprachen betrifft, die besser sind: Diese können normalerweise nicht einmal als nicht vertrauenswürdiger Code in einer Sandbox ausgeführt werden (Ausnahme ist JavaScript und möglicherweise Flash), daher wären sie noch schlimmer, da es keine inhärente Möglichkeit gibt, ihre Interaktion mit dem System einzuschränken .

120
Steffen Ullrich

Bei den gemeldeten Sicherheitslücken handelt es sich nicht um Java (die Programmiersprache), die aufgrund der JVM-Durchsetzung Speichersicherheit tatsächlich robuster ist als Sprachen wie C oder C++. Wo Pufferüberläufe und Pufferüberlesungen eine Bedrohung bleiben und zu Unordnung wie Heartbleed führen können.

Stattdessen befinden sich die gemeldeten Schwachstellen in der Sandbox Java, die versucht, ein Privilegierungsmodell zu erzwingen, das die sichere Ausführung von nicht vertrauenswürdigem Code ermöglicht, und das am häufigsten verwendet wird, um die automatische Ausführung von Java zu ermöglichen Applets in einem Browser. Dieser Sandkasten ist voller Löcher. Außerdem veröffentlicht Oracle Patches (die "kritischen Patch-Updates") nur viermal im Jahr. Unnötig zu erwähnen, dass Browser-Anbieter darüber nicht erfreut sind. Firefox ist beispielsweise für das Starten eines Java Applets ist eine Benutzerberechtigung erforderlich seit Firefox 26.

Der Grund, warum die Presseberichte diese Unterscheidung nicht treffen, ist, dass Oracle die Marke "Java" sowohl für die Programmiersprache als auch für das Browser-Plugin, mit dem Applets ausgeführt werden verwendet. Wenn ein gewöhnlicher Benutzer auf die Marke Java stößt, bezieht er sich wahrscheinlich auf letztere.

Es ist etwas spekulativ, warum genau die Sandbox anfällig bleibt. Wenn Sie mich fragen, ist ein Grund, dass dieselbe API sowohl mit als auch ohne Sandbox verwendet wird und der meiste Java Code ohne Sandbox ausgeführt wird (da der Code vertrauenswürdig ist). Infolgedessen ist es für einen Entwickler durchaus möglich, diese undurchsichtige Funktion zu vergessen, wenn er die Java API oder ihre Implementierung ändert und versehentlich Dinge offenlegt, die geschützt werden sollten (um zu veranschaulichen, wie einfach das ist, siehe die Länge Richtlinien für die sichere Codierung für Java SE ). Ein weiterer, aber verwandter Grund ist die schiere Größe der Java API ( 5800 Klassen und fast 50.000 Methoden für Java SE 6 ).

81
meriton

Es gibt Unmengen anderer Programmiersprachen, die dieses Problem nicht haben. Es muss also einen besseren Weg geben, um alles zu tun, was Java macht falsch).

Das ist eine ziemlich hohe Behauptung, woher hast du diesen Eindruck? Es gibt "Tonnen anderer Programmiersprachen", die nicht die gleichen Schritte wie Java durchlaufen haben oder so allgegenwärtig verwendet werden.

Der Grund dafür, dass es so viele Sicherheitspatches gibt, ist im Prinzip, dass Java wurde als sicher konzipiert, mit einer Reihe von sicherheitsrelevanten Funktionen, die andere Sprachen nicht haben.

Die Java Sprachumgebung

1.2.2 Robust und sicher

Die Java-Technologie wurde für den Betrieb in verteilten Umgebungen entwickelt. Daher ist die Sicherheit von größter Bedeutung. Mit Sicherheitsfunktionen, die in das Sprach- und Laufzeitsystem integriert sind, können Sie mit Java -Technologie Anwendungen erstellen, die nicht von außen angegriffen werden können. In der Netzwerkumgebung können Anwendungen in Java ist vor dem Eindringen von nicht autorisiertem Code geschützt, der versucht, hinter die Kulissen zu gelangen und Viren zu erstellen oder in Dateisysteme einzudringen.

Wenn Sie "sicher sein" nicht in die Spezifikationen für Ihre Programmiersprache aufnehmen, müssen Sie selten Sicherheitspatches veröffentlichen. Wenn dies andererseits eines Ihrer erklärten Ziele ist, werden Sie unter Druck geraten nicht zu.

11
dimo414

Java hat an sich große Vorteile für die Sicherheit, nämlich die inhärente Beständigkeit gegen Pufferüberläufe und Speicherverwaltungsfehler:

  • Alle Array-Zugriffe werden hinsichtlich der zugewiesenen Array-Länge überprüft. Pufferüberläufe werden somit zuverlässig abgefangen und lösen eine Ausnahme aus, die besser ist (dies macht Sicherheitslücken bei der Ausführung von Remotecode zu bloßem Denial-of-Service).

  • Die Speicherzuweisung wird über einen Garbage Collector verwaltet, der Fehler nach und ohne Verwendung verhindert. Außerdem ermöglicht der GC eine einfachere Handhabung von Zeichenfolgen (Zeichenfolgen sind in Java unveränderlich), wodurch die meisten Fälle von Pufferüberlauffehlern beseitigt werden.

  • Strikte Eingabe wird erzwungen; Code kann nicht auf Datenbytes zugreifen, was sie nicht sind. Dies verhindert wiederum Schwachstellen (Fehler, bei denen Datentypen übertragen werden, werden bei der Kompilierung oder im schlimmsten Fall als Laufzeit ClassCastException gemeldet).

Dies macht Java viel stärker als viele Programmiersprachen (insbesondere das höllische Paar C/C++), wenn es um Sicherheit geht.

Die Designer von Java) haben jedoch versucht, diese erweiterte Sicherheit zu nutzen, um etwas zu erschweren, dh Applets . Das Problem ist Angriffsfläche : Da es sich bei dem Applet um potenziell feindlichen Code handelt, muss alles kontrolliert werden. Der feindliche Code muss jedoch in der Lage sein, die "Standard Java Klassen" zu verwenden, wenn dies der Fall ist ist alles zu tun, also müssen "Kontrollpunkte" für jeden einzelnen Standard erzwungen werden Java Klasse. Die Angriffsfläche besteht somit aus Hunderten von Klassen, die Tausende von Methoden enthalten, und all von ihnen müssen angemessene Kontrollen durchsetzen.

Die Java Designer haben aus Ehrgeiz gesündigt: Die Schwierigkeit, Tausende von Prüfungen durchzuführen, ohne sie zu verpfuschen, war viel höher als gedacht. Alle "Java-Fehler" sind auf diese Tatsache zurückzuführen.

Wir können hier Java mit Javascript vergleichen; zum Beispiel Java erlaubt den Zugriff auf Dateien auf Datenträgern, aber dieses Recht darf Applets nicht gewährt werden, außer wenn das Das Applet hat danach gefragt und der Benutzer stimmt zu (was das gesamte Applet-Signiergeschäft mit sich bringt). Javascript, weniger ehrgeizig, hat einfach keine Dateizugriffsmethode: Zugriffskontrollen für eine Funktion können nicht falsch implementiert werden, wenn die Funktion nicht vorhanden ist!

Zusammenfassend: Java ist in Ordnung und sicher. Java applets implizieren eine riesige Angriffsfläche, deren Sicherheit sehr schwer zu gewährleisten ist. Für eigenständige Anwendungen und Server ist die Verwendung von Java eine gute Idee, wenn Sie Sicherheit wünschen () Dies gilt auch für C #).

10
Thomas Pornin

Heutzutage bedeutet das Auffinden weiterer Sicherheitslücken möglicherweise nicht mehr, wie unsicher die Software ist. Das Problem ist, wie das Sicherheitsreaktionsteam jedes Softwareanbieters darauf reagiert und wie schnell die Patches herauskommen.

Überprüfen Sie einfach, wie schnell Firefox und Chrome gepatcht werden). Viele Schwachstellen werden auch auf ihnen gefunden und behoben.

Wie ich mich erinnere, hat Oracle ein Programm namens Critical Patch Updates (CPU), das vierteljährlich viele Patches bereitstellt. Sie veröffentlichen auch Patches ohne CPU, wenn es eine Zero-Day-Sicherheitslücke gibt. Das Problem ist jedoch die Zeit, die Oracle benötigt, um einen Patch zu veröffentlichen.

4
Kasun

Überbewertete Angst .. Java selbst ist in Ordnung; die Probleme treten bei Java-Applets der alten Schule auf, die in Webbrowsern ausgeführt werden, aber ich bezweifle, dass irgendjemand tatsächlich Applets mehr erstellt - die meisten Entwicklungshäuser haben Flash oder HTML4 verwendet/5 für Front-End-Webschnittstellen seit mindestens 10 Jahren.

Heutzutage wird Java wird hauptsächlich für Backend-JEE, Front-End-GUI-Clients (JFX/AWT/SWING), Konsolen-Apps und mobile Apps verwendet - daher gibt es kein Problem.

2
John