Frage:
Warum höre ich von so vielen Java-Unsicherheiten? Sind andere Sprachen sicherer?
gsingh2011
2014-05-09 22:39:24 UTC
view on stackexchange narkive permalink

Ich mag die Java-Programmiersprache sehr, aber ich höre ständig, wie unsicher sie ist. Wenn Sie "Java unsicher" oder "Java-Schwachstellen" googeln, werden mehrere Artikel angezeigt, in denen erläutert wird, warum Sie Java deinstallieren oder deaktivieren sollten, um Ihren Computer zu schützen. Java veröffentlicht häufig eine große Anzahl von Sicherheitspatches gleichzeitig, und dennoch müssen noch unzählige Sicherheitslücken behoben werden.

Ich verstehe, dass es immer Fehler in der Software geben wird, aber die Anzahl der Sicherheitslücken, die Java aufweist hatte scheint nicht normal (oder bilde ich mir das ein?). Noch verwirrender ist, dass wenn es eine einzige architektonische Entscheidung gibt, die diese Sicherheitslücken schafft, warum nicht dieses Design ändern? Es gibt Unmengen anderer Programmiersprachen, die dieses Problem nicht haben. Es muss also einen besseren Weg geben, um das zu tun, was Java falsch macht. Warum ist Java immer noch so unsicher?

Ich finde es wirklich unfair, dass einige Leute behaupten, Java sei "unsicher", weil das Sandbox-Konzept einige Mängel aufweist, während die meisten anderen Technologien nicht einmal Sandboxing aufweisen und es Programmen ermöglichen, auf dem Computer, auf dem sie ausgeführt werden, praktisch alles zu tun, was sie wollen. Die Kritik ist nur in dem wirklich engen Anwendungsfall von Applets gerechtfertigt, die in einem Webbrowser ausgeführt werden, in dem Alternativen wie Flash eine ebenso schlechte Sicherheitsbilanz aufweisen.
Ihre Frage ähnelt der Frage "Warum haben Autos immer noch Motorprobleme?". (Und für diejenigen, die aus dem Blickwinkel von "C (++) hat diese nicht!" Kommen, fügen Sie hinzu "Mein Fahrrad hat nie welche!")
Weil es als Kind gemobbt wurde.
Java hatte relativ * wenige * Sicherheitslücken für eine vollwertige Programmiersprache, die in einem Browser ausgeführt werden kann (die meisten anderen browserfähigen Sprachen sind von Natur aus nicht in der Lage, bestimmte Dinge zu tun). - Die Sicherheitslücken, von denen Sie in letzter Zeit gehört haben, sind völlig bösartige Anwendungen (lesen Sie Applets), die einen Weg finden, aus der Sandbox auszubrechen und beliebigen Code auf Ihrem System auszuführen. Es könnte ein Argument dafür geben, dass Applets ein Teil von Java sind, der zur Ruhe gesetzt werden sollte, obwohl viele Technologien immer noch auf ihnen beruhen (IMPI-Konsolen, Bank-Websites usw.).
@Philipp: Ich denke nicht, dass es überhaupt unfair ist. Wenn eine Sprache als Sandbox beworben wird, ihre Sandbox jedoch jedes Jahr zehn bis hundert kritische Schwachstellen aufweist, ist es durchaus gerechtfertigt, sie als unsicher zu verurteilen. Sicherheit ist keine absolute Sache, sondern eine Frage der Einhaltung des veröffentlichten Vertrags. Vielleicht ist es nicht fair, Java und C ++ zu vergleichen, aber es ist sicherlich fair, Java und Lua zu vergleichen. Wenn ich mich nicht irre, hat letzterer nicht einmal die einstelligen Sicherheitslücken für Sandbox-Escape überschritten.
@R .. Das Sandboxing gilt nur für einen sehr engen Kontext, und das sind Java-Applets in Webbrowsern. Wenn Sie sagen wollen, dass diese unsicher sind, stimme ich voll und ganz zu. Wie Sie dieser Frage entnehmen können, erweitern viele Leute diese Kritik auf Java im Allgemeinen, das Anwendungsfälle abdeckt, in denen die Sandbox-Probleme von Applets überhaupt keine Rolle spielen.
@R .. Der Vergleich von Java mit Lua ist auch nicht fair, da Java eine Allzwecksprache mit [einer riesigen Standardbibliothek, die alles außer dem Spülbecken enthält] (http://docs.oracle.com/javase/8) ist /docs/api/allclasses-noframe.html), während Lua [eine sehr kleine Standardbibliothek] (http://www.lua.org/manual/5.2/) hat und in eine Hostanwendung eingebettet werden soll, die eine Domäne hinzufügt -spezifische Skriptbindungen an lua, die möglicherweise sicher sind oder nicht.
Meiner Meinung nach ist dies vollkommen fair, da eine riesige Standardbibliothek *, die außerhalb der Sandbox implementiert ist *, die Möglichkeit, eine sichere Sandbox-Umgebung anzubieten, im Wesentlichen ausschließt. Dies ist eines der Dinge, die Java schrecklich falsch gemacht hat, dass Lua richtig gemacht hat.
Ich bin damit einverstanden, dass "Java the language" viel negative Publizität erhält, wenn "Java the sandbox" so kaputt ist. Ob dies "fair" ist oder nicht, ist eine Entscheidung, aber es ist eine Folge der Marketingentscheidung, die beiden eng miteinander zu verbinden. Auf den meisten Systemen werden durch die bloße Installation von Java (für welchen Zweck auch immer) auch Browserkomponenten installiert, die das System bei Verwendung des Browsers kritischen Remote-Schwachstellen aussetzen. Es ist also fair zu sagen, dass Java einfach installiert ist, es sei denn, Sie haben sich die Mühe gemacht Blockieren Sie die Verwendung im Browser, ist ein Sicherheitsproblem.
@R .. Eine Firma, für die ich gearbeitet habe, hat LotusNotes nur verwendet, weil nur wenige Leute es verwendet haben und die Sicherheitslücken, die es (wie alles) hatte, sicherlich unentdeckt blieben. Ich fürchte, Java ist auf der anderen Seite. Jeder Fehler, den es hat, wird entdeckt, bedeutet nicht, dass andere weniger verbreitete Dinge sicherer sind, es gibt nur weniger Leute, die versuchen, sie zu knacken
@R .. "Es ist sicherlich fair, Java und Lua zu vergleichen. Wenn ich mich nicht irre, hat letzterer nicht einmal die einstelligen Zahlen für Sandbox-Escape-Schwachstellen überschritten." Nach diesem Argument sollten wir eigentlich alle PostScript verwenden, da es noch weniger solche Sicherheitslücken gibt. (PostScript _does_ bietet tatsächlich Sandboxing an, und wenn es richtig konfiguriert ist, können Sie feindlichen Code ungestraft ausführen, FYI) (Wenn Sie nicht ganz verstehen, was ich sage, hat Java mehr _discovered_ Schwachstellen, weil Java _far verwendet wird öfter als Lua.)
Tatsächlich weist PostScript in der Vergangenheit einige Sicherheitslücken auf, insbesondere wenn man die Umgebung betrachtet, in der es verwendet werden soll. Und jede Turing-vollständige Sprache ist eine DoS-Sicherheitslücke im Kontext dessen, wofür PostScript gedacht ist (Dokumente), insbesondere wenn Sie es sind Betrieb auf 1-MHz-Mikrocontrollern in Druckern.
Bei Java gegen Lua geht es nicht darum, wie oft sie verwendet werden. Es ist eine Frage des Designs. Lua hat eine winzige Anzahl potenzieller Fehlerpunkte (einer davon war ein idiotischer: Lua-Code kann Bytecode direkt in die virtuelle Maschine einspeisen). Java hat eine astronomische Zahl.
Für (White-Hat-) Hacker ist die Untersuchung in Java-Vulns offensichtlich interessanter als in der anderen Sprache. Dies ist genau das, was Windows für andere Betriebssysteme ist.
Vielleicht können Sie den Kontext Ihrer Aussage klären. Anscheinend geben Sie an, dass Sie der Meinung sind, dass der Java-Code möglicherweise repariert werden muss und dass die Software-Betreuer nicht gut genug arbeiten? Jede Anwendung hat ihren eigenen anwendbaren Codetyp, der implementiert werden muss. Daher sollte vermieden werden, sich auf eine Reihe von Codierungspraktiken zu verlassen. Ich wette, dass clientseitige Java-Anwendungen über Flash ausgeführt werden und bald absterben.
Hah, sprechen Sie über unfair: Wir entwickeln einen [Browser in Java] (https://github.com/UprootLabs/gngr), und die Leute verwechseln ihn mit Applets oder assoziieren ihn mit Java, was sie mit Applets verwechseln oder assoziieren die Security-Manager-Sandbox mit der spezifischeren Applet-Sandbox ... und so weiter.
Sieben antworten:
#1
+120
Steffen Ullrich
2014-05-09 23:24:59 UTC
view on stackexchange narkive permalink

Wenn Sie Java wie die meisten anderen Programmiersprachen verwenden, z. 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. vorliegen.

Java wird jedoch regelmäßig als Plugin im Webbrowser verwendet, z. ä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 in einer begrenzten Sandbox ausführen zu lassen, in der er nicht in der Lage sein sollte, auf irgendeine Weise gegen das System oder den Benutzer vorzugehen (z. B. lokale Dateien lesen und senden) sie auf die Website, scannen das lokale Netzwerk usw.). Und hier ist Java in den letzten Jahren gescheitert, z. Manchmal tauchten täglich neue Fehler auf, die das Entkommen aus der Sandbox ermöglichten.

Manchmal führen auch Fehler im Bytecode-Interpreter oder in nativen Bibliotheken zu Pufferüberläufen und können das System gefährden, in dieser Hinsicht jedoch Flash wird normalerweise als schlimmer 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 keinen inhärenten Weg gibt um ihre Interaktion mit dem System zu begrenzen.

Server- und Desktop-Java-Anwendungen weisen also weniger Schwachstellen auf als Java-Applets?
Ja, das größte Sicherheitsproblem ist nur die Sandbox.
Kein Stackoverflow? Ich habe gerade heute versehentlich eine mit unendlicher Rekursion ausgelöst. Meinten Sie Pufferüberlauf?
Ja, ich meine Pufferüberläufe. Danke für die Korrektur. Und Sie können sie immer noch bekommen, aber nicht so allgegenwärtig wie in C, C ++.
Mit Java auf dem Server kann Oracle Datenbanklizenzen usw. verkaufen. Java-Applets sind jedoch für das Geschäft von Oracle nicht sinnvoll. Erwarten Sie daher nicht, dass Oracle mehr als manuelle Anstrengungen unternimmt, um die damit verbundenen Sicherheitslücken zu schließen.
@IanRingrose Stimme nicht zu. Oracle ist von den Aktionären nicht verpflichtet, mehr als nur minimale Wartungsarbeiten durchzuführen, aber bis jetzt scheinen sie Schwachstellen ziemlich ernst genommen zu haben. Wie bereits erwähnt, wirken sich Schwachstellen auf das gesamte System aus, und Webanwendungsanwendungen und Applets werden normalerweise von Serveranwendungen in Java gesichert. Im Allgemeinen glaube ich nicht, dass es keinen Hinweis darauf gibt, dass Oracle diese Fehler nicht ernst nimmt. Beachten Sie auch, dass Entwickler selbst häufig ein starkes Verantwortungsbewusstsein haben, unabhängig vom Unternehmen selbst. Schwarz / Weiß-Aussagen sind hier nutzlos.
@Lekensteyn Die Java-Sprachspezifikationen verlangen, dass Implementierungen Stapelüberläufe erkennen und eine Ausnahme auslösen. In C / C ++ ist es nur undefiniertes Verhalten mit allem, was dazu gehört. Bis zu einem gewissen Grad funktioniert "Stapelüberlauf" dort auch noch.
@SteffenUllrich zum Ausarbeiten - das liegt daran, dass die Sandbox versucht, die Funktionen einer vollwertigen Programmiersprache einzudämmen / einzuschränken. Im Gegensatz zu einigen anderen browserfähigen Sprachen, die ursprünglich ohne bestimmte Funktionen entwickelt wurden (dh es spielt keine Rolle, ob Sie aus der Sandbox ausbrechen, weil Sie bestimmte Dinge immer noch nicht tun können). Solange in Ihrem Browser eine vollwertige Programmiersprache ausgeführt wird, besteht die Möglichkeit, dass diese Dinge mit Ihrem lokalen System tut. Java-Applets sind noch heute sehr leistungsfähig (IMPI-Konsolen usw.).
Ihre Gleichung aus Java-Applets und JavaScript ist falsch. JavaScript ist eine intrinsische Browserfunktion, und Java erfordert ein explizites, separat installiertes Plugin. Ein JavaScript-Exploit in einem Browser ist nicht der gleiche wie der andere, aber ein Applet-Exploit funktioniert * überall *, da das Plugin * überall * gleich ist. Darüber hinaus bietet JavaScript in den meisten Browsern keine Betriebssystemfunktionen und kann auf verschiedene Arten in eine Sandbox umgewandelt werden (Verhinderung der Ausführung von nativem Code). Es ist besser, Java und Flash gleichzusetzen.
*** Großes Stöhnen *** bezüglich des "z. B. ähnlich wie JavaScript". Nur sie in den gleichen Satz zu setzen, bittet um Verwirrung; Sie sind sich wirklich nicht ähnlich und JS funktioniert wirklich nicht wie ein Plugin. Ich habe gerade alle Kommentare gelesen ... Was @DCKing gesagt hat.
@DCKing: Javascript ist dem Browser eigentlich nicht so eigen, wie Sie vielleicht denken. Javascript-Interpreter wie Rhino, SpiderMonkey und V8 können tatsächlich unabhängig von dem Browser ausgeführt werden, an den sie normalerweise angeschlossen sind. Es gibt eine Art Plugin-Schnittstelle zwischen der Host-Anwendung (nicht unbedingt einem Browser) und all diesen beliebten Javascript-Engines.
@LieRyan Das argumentiert Semantik. Jeder Hauptbrowser verwendet eine andere JavaScript-Implementierung, und Angreifer benötigen für jeden von ihnen unterschiedliche Sicherheitslücken. Plugins sind überall gleich. Das ist der Punkt.
#2
+81
meriton
2014-05-10 16:48:48 UTC
view on stackexchange narkive permalink

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

Stattdessen befinden sich die gemeldeten Sicherheitslücken in der Java Sandbox, die versucht, ein Privilegierungsmodell zu erzwingen, das die sichere Ausführung von nicht vertrauenswürdigem Code ermöglicht. und wird am bekanntesten verwendet, um die automatische Ausführung von Java-Applets in einem Browser zu ermöglichen. 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 zum Beispiel erfordert eine Benutzerberechtigung zum Starten eines Java-Applets seit Firefox 26.

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

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 Entwickler durchaus möglich, diese undurchsichtige Funktion beim Ändern der Java-API oder ihrer Implementierung zu vergessen und versehentlich Dinge freizulegen, die geschützt werden sollten (um zu veranschaulichen, wie einfach dies ist, lesen Sie die langwierigen 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).

IMHO ist dies die beste Antwort, da es die Komplexität der Sicherung einer API berührt, die versucht, alles zu tun. Eine vollständig ummauerte Version von Java für Applets (keine E / A) würde viel Erleichterung bringen, aber die aktuelle API ist dafür einfach zu eng gekoppelt.
Nur Rindfleisch, das ich mit dieser Antwort habe, ist, dass 1) Heartbleed * nicht * das Ergebnis eines Pufferüberlaufangriffs war. 2) Sie können aus offensichtlichen Gründen auch nicht sagen, dass eine mit einer virtuellen Maschine gekoppelte Sprache "besser" ist als eine andere Sprache. Abgesehen davon, eine gute Anmerkung zu den wirklichen Löchern in dieser Sandbox, ist eine Programmiersprache nicht sicherer oder unsicherer als eine menschliche Sprache, alles läuft auf einen Compiler oder Interpreter hinaus und * am * wichtigsten: Die Person * benutzt * die Sprache.
1) Ok, laut Wikipedia war Heartbleed eher ein Pufferüberlesen als ein Pufferüberlauf, da der Zugriff über die Pufferlänge hinaus eher ein Lesezugriff als ein Schreibzugriff war. Behebt die Terminologie. 2) Ich denke, das ist ein gültiger Vergleich, da die Java ** Language ** Spezifikation [Mandate] (http://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls) -15.10.4) dass die Laufzeitumgebung diese Prüfung durchführt. In Java ist die Speichersicherheit eine Sprachfunktion. In C oder C ++ ist dies nicht der Fall.
#3
+11
dimo414
2014-05-11 00:55:51 UTC
view on stackexchange narkive permalink

Es gibt Unmengen anderer Programmiersprachen, bei denen dieses Problem nicht auftritt. Es muss also einen besseren Weg geben, um das zu tun, was Java falsch macht.

Das ist hübsch hoher Anspruch, woher hast du diesen Eindruck? Es gibt "Tonnen anderer Programmiersprachen", die nicht die gleichen Schritte wie Java durchlaufen oder allgegenwärtig verwendet werden.

Grundsätzlich gibt es so viele Sicherheitspatches, weil Java es war Entwickelt, um sicher zu sein, 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 Sicherheit von größter Bedeutung. Mit Sicherheitsfunktionen, die in das Sprach- und Laufzeitsystem integriert sind, können Sie mit der Java-Technologie Anwendungen erstellen, die nicht von außen angegriffen werden können. In der Netzwerkumgebung sind in der Programmiersprache Java geschriebene Anwendungen 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 dies nicht angeben "Seien Sie sicher" in den Spezifikationen für Ihre Programmiersprache, müssen Sie selten Sicherheitspatches veröffentlichen. Wenn dies andererseits eines Ihrer erklärten Ziele ist, wird es Ihnen schwer fallen, nicht .

#4
+10
Thomas Pornin
2014-05-16 20:43:43 UTC
view on stackexchange narkive permalink

Java selbst verfügt über große Sicherheitsvorteile, 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 Remotecodeausführung zu bloßem Denial-of-Service).

  • Die Speicherzuweisung wird über verwaltet Ein Garbage Collector, der Use-After-Free- und Double-Free-Fehler 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.

  • Die strikte Typisierung 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 in Bezug auf Sicherheit viel stärker als viele Programmiersprachen (insbesondere das höllische Paar C / C ++).

Die Java-Designer versuchten jedoch, diese erweiterte Sicherheit zu nutzen etwas schwer machen, dh Applets. Das Problem ist Angriffsfläche : Da das Applet potenziell feindlicher Code ist, muss alles, was es tut, kontrolliert werden. Der feindliche Code muss jedoch in der Lage sein, die "Standard-Java-Klassen" zu verwenden, wenn er etwas tun soll. Daher müssen "Kontrollpunkte" für jede einzelne Standard-Java-Klasse erzwungen werden. Die Angriffsfläche besteht somit aus Hunderten von Klassen, die Tausende von Methoden enthalten, und alle müssen angemessene Überprüfungen erzwingen.

Die Java-Designer sündigten aus Ehrgeiz: die Schwierigkeit, Tausende von Methoden zu implementieren Schecks ohne Verpfuschen waren viel höher als sie sich vorgestellt hatten. Alle "Java-Fehler" stammen aus dieser Tatsache.

Hier können wir Java mit Javascript vergleichen. Java erlaubt beispielsweise den Zugriff auf Dateien auf Datenträgern, aber dieses Recht darf Applets nicht gewährt werden, es sei denn, 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 nur sehr schwer zu gewährleisten ist. Für eigenständige Anwendungen und Server ist die Verwendung von Java jedoch eine gute Idee, wenn Sie Sicherheit wünschen (dies gilt auch für C #).

Nitpick: Es ist eher wie Tausende von Klassen und Zehntausende von Methoden. Davon abgesehen: Tolle Antwort!
#5
+4
Kasun
2014-05-10 01:53:36 UTC
view on stackexchange narkive permalink

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 veröffentlicht werden.

Überprüfen Sie einfach, wie schnell Firefox und Chrome gepatcht werden. Viele Schwachstellen sind 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.

Ich stimme dem ersten Satz zu. Nicht * Sicherheitslücken * in anderer Software zu finden, bedeutet nicht, dass es keine gibt - schauen die Leute (so genau)?
#6
+2
John
2014-05-14 06:58:17 UTC
view on stackexchange narkive permalink

Ü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 tatsächlich jemand Applets mehr erstellt. Die meisten Entwicklungshäuser verwenden Flash oder HTML4 / 5 seit mindestens 10 Jahren für Front-End-Webschnittstellen.

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

#7
-4
SSpoke
2014-05-11 08:07:39 UTC
view on stackexchange narkive permalink

Die Antwort liegt auf der Hand. Können Sie Ihre Computerdateien mit JavaScript, HTML oder Flash löschen? Nein, das kannst du nicht.

Was ist mit Java? Können Sie alle Ihre Dateien löschen und Ihre Festplatte mit einem Java-Applet (auf einer Website gehostet) vollständig löschen? Die Antwort lautet Ja, wenn Sie das Ausführen des Applets akzeptieren. Im Gegensatz zu jeder anderen Webbrowsersprache.

Java kann beispielsweise Programme auf Ihrem Computer ausführen (ausführbare Dateien) und Dateien auf Ihrer Festplatte schreiben, aktualisieren oder löschen.

Auch Java Applets können von Virenscannern nicht erkannt werden: In den meisten Fällen wissen Sie nicht einmal, dass Ihr Computer dadurch beschädigt wurde. Einige Scanner erkennen möglicherweise, dass etwas versucht, Dateien in einem eingeschränkten Verzeichnis zu löschen: Eine, die ich kenne, ist Kaspersky, aber die meisten Benutzer haben diese Funktion standardmäßig deaktiviert.

Java-Applets können dies Aktualisieren Sie beispielsweise Windows-Dateien wie HAL.dll , um zu verhindern, dass Ihr Computer startet. Es kann alles mit Ihrem Computer tun, wenn Sie das Ausführen des Applets akzeptieren.

In einigen Fällen spielt es keine Rolle, ob ein Java-Applet signiert oder nicht signiert ist - es werden weiterhin Dateien auf Ihren Computer heruntergeladen.

Ganz zu schweigen davon, dass Java sehr beliebt ist.

Es gibt eine andere, die immer beliebter wird: Unity Engine (ähnlich wie Flash): Sie hat dieselbe Sicherheitsprobleme wie Java haben und könnten alles mit Ihrem Computer tun. Der einzige Unterschied zwischen Unity Engine und Java besteht darin, dass Unity ausgeführt wird, ohne Sie zu fragen, ob Sie es ausführen möchten oder nicht. Wenn also jemand Unity Player installiert hat und ein Spiel mit einem Virus ausführt, wird Ihr Computer durcheinander gebracht.

Weniger beliebt, aber möglicherweise äußerst schädlich ist VBScript. Ich glaube, Microsoft Internet Explorer ist der einzige, der dies derzeit unterstützt, aber ich könnte mich irren. Es hat die gleichen Fähigkeiten wie Java.

"Die Antwort liegt auf der Hand. Können Sie Ihre Computerdateien mit JavaScript, HTML oder Flash löschen?" Ja, ich kann. Ich brauche nur einen ausreichenden Exploit in der JavaScript-Engine oder im Flash-Plugin.
Viele Faktoren, auf die Sie abzielen müssen, um auf eine bestimmte Version von Flash und JavaScript abzuzielen, scheinen, als ob jeder Browser seine eigene Engine verwendet. Mit einer Sprache, die dies tut, ohne Code zu hacken, kann nur ein normaler Programmierer dies problemlos mit Java / Unity usw. tun. Wenn er böse ist, versucht er natürlich nur zu sagen, dass die Leute etwas nicht vertrauen sollten, das Schaden anrichtet, ohne es zu verbergen. Nichts macht mich mehr wütend als kleine Kinder, die versuchen, mich mit Keyloggern zu verarschen. Haha
Java-Applets sind im Allgemeinen auch vor solchen Szenarien geschützt, z. B. vor dem Löschen Ihres Dateisystems. Sie müssen zunächst eine Sandbox-Umgehung durchführen, bei der Sie auch bestimmte Versionen und null Tage als Ziel festlegen müssen. Aus dieser Perspektive befinden sich die Java- und Flash-Plugins mehr oder weniger im selben Boot.
Flash hat auch einen fairen Anteil an Exploits. Mit jeder Sprache, die von einer nativen Engine "interpretiert" wird und Programmierfehler aufweist (Java, Flash sind die vorherrschenden Beispiele), ist es möglich, der von ihnen erstellten Sandbox zu entkommen und das Hostsystem zu beeinflussen, möglicherweise sogar nativen Code einzufügen, der dies dann kann einen Privilegieneskalationsfehler des Hosts ausnutzen.
"Die Antwort lautet" Ja ", wenn Sie das Ausführen des Applets akzeptieren."Dies ist völlig falsch, wenn wir über Applets sprechen (und wir sind, wie sonst, alle Wetten ungültig und ich hoffe, Sie wissen, was Sie auf dem "nominell Ihrem" Computer installiert haben).Siehe: [Berechtigungen im Java Development Kit (JDK)] (http://docs.oracle.com/javase/7/docs/technotes/guides/security/permissions.html)


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...