Aversion gegen Java
-
NurZurNotCpp schrieb:
Mal ehrlich, wer heute ein größeres Projekt plant der wird doch C++ nur nehmen wenn es gar nicht anderes geht.
Der nimmt dann Java und spricht den C-Code über JNI an.
-
Ethon_ schrieb:
Und du hast nichts bezüglich der Sicherheit von Java argumentiert, nur Metametaargumente.
Was soll man da Argumentieren?
Java ist nach Flash das größte Einfallstor für Angreifer.
https://www.cvedetails.com/vulnerability-list.php?vendor_id=93&product_id=19117
bzw.
https://heimdalsecurity.com/blog/java-biggest-security-hole-your-computer/
-
So ein Unsinn, das mit der Lücke ist Jahre her. Wenn du wirklich unsicher sein willst, dann stell ein Linux-Server ins Netz am besten noch mit einem SSH-Server. Ach ne, das haben sie ja nach vielen Jahre erst entdeckt. Jaja, Opensource macht Software sicherer *lach
Das Java unsichere ist, ist genau so ein Unsinn wie dass Windows unsicherer ist als Linux.
-
Schau dir mal hier an wie viele Fehler pro Produkt gelistet sind. Da steht ja Windows echt gut da.
https://www.cvedetails.com/top-50-vendors.php
-
Was für eine Diskussion...
Javalove's Spruch "So gut wie jede C++ Software ist doch wie ein Schweizer Käse, bei dem man sich das Loch nur aussuchen muss." hat mich gestört und habe ihm deswegen gegen den Kopf geknallt dass das Java Plugin sich in Sachen Sicherheit auch nicht rühmlich gemacht hat.
Wir leben heute in einer Welt, in der das Internet nie weit von uns entfernt ist. Und in der sich Internetkriminalität noch nie so gelohnt hat. Ich vermute mal dass wir heute in einer Welt mit diversen Internet-Mafia's leben, welche es sich problemlos leisten können, Software-Entwickler einzustellen, welche Tag und Nacht nach Sicherheitslücken suchen. Daher würde ich jede mächtige Online-Sprache als potenziell unsicher bezeichnen. Einfach weil sie im Fokus stehen.
Aber Sicherheit nur an Sprachelementen einer Programmiersprache festmachen, halte ich für einen Fehler. Java wird nicht sicherer dadurch das Buffer-Overflows nicht funktionieren. Zum ersten kann man nachschauen wie gut der Schutz funktioniert und diesen ggf. umgehen (siehe Heap Spraying gegen Data Execution Prevention (DEP) und Adress Space Layout Randomisation (ASLR)). Oder man wirft einen Blick in die java.exe, überprüft ob die Funktionen innerhalb der Exe anfällig ist und weicht ggf. auf die von java.exe genutzten Betriebssystem-Funktionen aus. Ganz krass wird dies am Angler-Exploit Toolkit sichtbar, welche EMET Schutztechniken aushebeln kann.
Kurze Sache am Rande. Jedes neu geschriebene C Programm hat unter Visual Studio automatisch diverse Sicherheitstechniken implementiert, wie Data Execution Prevention, Address Space Layout Randomization, Safe Exception Handling, Überprüfung auf unsichere Funktionen,... Damit wird Sicherheit auch Sache des Programm-Alters, sofern man nicht EMET nutzt.
Sicherheit hat viele Facetten. Und viele Sicherheitslücken öffnen sich einfach dadurch, dass unsachgemäße Benutzung erstens möglich ist und zweitens diese weitreichenden Zugang ermöglichen:
1.) Geben Sie ihren Namen ein: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXX -> Buffer Overflow da Name ein char[16] ist und so den Instruction Pointer überschreibt. Warum darf er dass denn überhaupt?
2.) Geben Sie ihren Namen ein: * -> SQL Injection. Gibt Namen aller Personen aus.
3.) Passwortwiederherstellung bei EMail Account: Geben sie ihre Lieblingsfarbe ein:
-> Findet man einfach bei Facebook. Einfach eine falsche Identität einer 20 jährigen Frau mit dicken Brüsten annehmen, den Freund der Zielperson werden,
so auf seine private Facebook Seite kommen, wo alle sozialen Informationen stehen.
4.) Alex schickt Beate folgende Nachricht: AES("Hallo Beate. Kaufe noch bitte weitere 2000 Aktion der IchBinBaldPleite AG"). Mallory fängt die Nachricht ab,
leitet diese an Beate weiter und schickt ihr zusätzlich diese jeden Tag. Dadurch kauft Beate wesentlich mehr Aktion als gedacht und geht durch die
Pleite Bankrott.Ich denke Sicherheit ist eine komplexe Sache. Und daher würde ich mit Sicherheit sicherheitstechnische Aspekte schon in Softwareentwicklung einbauen (siehe Microsoft Security Development Lifecycle oder ähnlichem).
PS:
Bei folgenden bin ich mir nicht ganz sicher. Setup Dateien dürften beim Starten diverse DLL's wie beispielsweise User32.dll laden. Wenn man nun eine gefakte User32.dll entwickelt, welche die Funktionen der Windows User32.dll wrappt, und zusätzlich eigenen Code enthält, und diese in den Ordner der Setup Exe Datei legt, dürfte die Setup Datei die gefakte DLL laden s.d. man zum Nulltarif zu Admin Rechten kommen.
-
Andromeda schrieb:
Ethon_ schrieb:
Bitte ein einziges Argument, warum Java unsicher sein sollte. Danke.
Es gab doch da vor Jahren mal ein Sicherheitsloch bei Applets, das IMHO einige Browserhersteller dazu veranlasst hat, Java gar nicht mehr zu unterstützen.
Ja, das Java-Plugin für den Browser. Hat aber wenig mit der JVM, dem JDK und der sonstigen Java-Infrastruktur zu tun.
Ist auch schon lange obsolet, vor allem jetzt dank HTML 5.
Was in der Praxis gerne betrieben wird, ist Java-Code, der mit GWT in Javascript kompiliert wird. Hat die Probleme der Applets nicht.Shade Of Mine schrieb:
Ethon_ schrieb:
Und du hast nichts bezüglich der Sicherheit von Java argumentiert, nur Metametaargumente.
Was soll man da Argumentieren?
Java ist nach Flash das größte Einfallstor für Angreifer.
https://www.cvedetails.com/vulnerability-list.php?vendor_id=93&product_id=19117
bzw.
https://heimdalsecurity.com/blog/java-biggest-security-hole-your-computer/Hier geht es wohl um Fehler in diversen Implementierungen.
Wenn ich jetzt eine SSL-Library in C++ entwickle, Bugs einbaue, dann ist das nicht wirklich ein C++ Problem.Im Übrigen gibt es bei anderen Sprachen garantiert nicht weniger Fehler, nur wird es da nicht unter einem Namen aggregiert. Wenn der Apache Webserver miese Bugs hat, dann ist Apache buggy, nicht C.
Genausowenig ist Java schuld, wenn eine RMI-Implementierung buggy ist.
Aus der Liste lässt sich leider schwer ableiten, was denn nun die Bugs waren und wo.
-
Ethon_ schrieb:
Hat aber wenig mit der JVM, dem JDK und der sonstigen Java-Infrastruktur zu tun.
Das hat alles mit der JVM und dem JDK zu tun, da ein grosser Teil der Exploits auf Bugs in der JVM und/oder dem JDK basieren. Oder meinst du dass das Browser-Plugin ein grundlegend anderes, schlechteres JDK verwendet als normale Anwendungen? Oder vielleicht dass die ganzen Bugs alle nur im Browser-Plugin-spezifischen Code zu Hause waren? Das ist nämlich nicht der Fall, ein grosser Teil sind einfach ganz normale Bugs im JDK.
Bloss halt Bugs in Komponenten mit denen man üblicherweise nicht in Server-Applikationen Daten verarbeitet. Bzw. halt keine Daten die direkt über's Netzwerk aus nicht vertrauenswürdigen Quellen daherkommen. Die Klassen die mit solchen Daten arbeiten müssen sind - im Vergleich zum Gesamtumfang des JDK - sehr wenige. Die ganzen Sockets/Streams, ein bisschen Cryptographie (SSL etc.), XML Parser, JSON Parser, und damit haben wir's auch schon im Grossen und Ganzen.
Solltest du allerdings eine Serverapplikation haben wo der Kunde z.B. Dokumente mit Embedded Fonts hochladen kann, und die Serverapplikation dann das JDK verwendet um daraus ne hübsche Bitmap zu rendern, dann wäre die Serverapplikation genau so von dem Bug in der Font-Engine des JDK betroffen.
Bloss da die wenigsten Server-Applikationen sowas machen, ist das halt kein so grosses Thema.----
Und was im JDK als ganzem so für kritische Bugs zu finden sind ist ja nicht schwer in Erfahrung zu bringen:
https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19116/Oracle-JDK.html
Und da ist jetzt nicht gerade wenig "Rot" zu sehen.----
Davon abgesehe: Ich habe nicht behauptet dass Java für Server-Anwendungen besonders unsicher ist. Ich erkenne nur dein Argument nicht an, weil das Argument halt Blödsinn ist. Und ein Argument nicht anzuerkennen ist nicht das selbe wie das Gegenteil zu behaupten. Und Blödsinn ist das Argument auf jeden Fall, da braucht man gar nicht lange drüber diskutieren. Es läuft auf "die Mehrheit hat immer Recht" hinaus (Recht haben im Sinn von "die Wahrheit kennen"). Und das ist Quatsch. Auf eine Diskussion warum lasse ich mich nicht ein, kannst du googeln wenn es dich interessiert.
Und weil dir das vermutlich noch etwas zu abstrakt ist, bzw. nicht reichen wird, kann ich dir auch ein schönes Gegenargument bringen. Nämlich dass vielen grossen Firmen einfach keine andere Wahl bleibt als mit Java zu arbeiten. Dahingehend wirken viele Faktoren, und einer der wichtigsten ist dass Java einfach so verdammt verbreitet im "Enterprise" Segment ist. D.h. du hast einerseits sehr viele Firmen die bereits sehr viel Java Code haben den sie nicht einfach wegwerfen können - und schno sehr viele Java Programmierer haben die sie nicht einfach durch nen 2-wöchigen Kurs in C++ Programmierer umwandeln können. Und andrerseits beeinflusst das natürlich auch welche Sprachen an Unis/FHs/... gelehrt werden, und damit welche Sprachen "günstig" sind wenn man viele neue Programmierer einstellen möchte. (Und je grösser die Firma, desto mehr muss sie schonmal nur deswegen einstellen um die nachzubesetzen die in Pension gehen -- Wachstum der Firma ist da also nichtmal nötig.)
Jetzt könnte man die Frage stellen: Wenn Java so ein Mist ist, wieso wurde es dann überhaupt so gross?
Und ein wichtiger Teil der Antwort darauf ist, dass das Thema Internet/Security/Exploits zu dem Zeitpunkt wo Java gross geworden ist einfach quasi nicht existent war.
-
Ethon_ schrieb:
Hier geht es wohl um Fehler in diversen Implementierungen.
Wenn ich jetzt eine SSL-Library in C++ entwickle, Bugs einbaue, dann ist das nicht wirklich ein C++ Problem.Das ist ein Strohmann von dir!
Niemand behauptet dass der Java Sprachstandard an sich irgendwie hinsichtlich Security krass kaputt wäre. Bzw. zumindest ich behaupte das nicht. Und ich habe auch bei den anderen Java-kritischen Stimmen hier nicht den Eindruch dass die das tun. Nur ist die Erkenntnis dass es da kein bzw. kein krasses Problem gibt nicht viel Wert. Umgekehrt, also wenn der Sprachstandard an sich schon kaputt wäre, wäre es natürlich fatal. Also die Frage ist schon interessant -- nur halt lange nicht hinreichend.
Und strenggenommen gilt das genau so für C++ und so ziemlich jede andere Sprache überhaupt. Da gibt es auch kein Problem mit dem Sprachstandard an sich. Wenn man korrekte und sichere C++ Programme schreibt, dann funktionieren die auch korrekt und sicher.
Wenn ich behaupte würde dass Java nicht sicher ist (was ich hier gar nicht getan habe, aber das Thema hatten wir ja schon)... dann würde ich damit also klarerweise die Implementierung meinen. Und da ist es bei Java nunmal einfach so, dass grösstenteils nur eine Implementierung im "Enterprise-Segment" verwendet wird, und das ist halt einfach die von Oracle.
----
Ja, in C++ kann man sich leichter mit *eigenem* Code so ins Knie schiessen dass dabei ein sicherheitskritischer Bug entsteht. In Java ist das schwieriger.
Dafür hast du in Java eine Implementierung die fast überall verwendet wird, und die sehr sehr sehr viel mehr bereit stellt als die Standard-Library von C++. Und was im JDK schon drinnen ist, dafür nimmt man auch nicht ohne Not externe Libraries. Dadurch hast du einerseits eine viel breitere Angriffsfläche.
D.h. bei Java kannst du dir wesentlich einfacher einen kritischen Bug durch Fehler in der Implementierung eintreten. Und damit ist die Frage ob die Implementierung sicher ist oder nicht sehr relevant.
-
hustbaer schrieb:
Ethon_ schrieb:
Hat aber wenig mit der JVM, dem JDK und der sonstigen Java-Infrastruktur zu tun.
Das hat alles mit der JVM und dem JDK zu tun, da ein grosser Teil der Exploits auf Bugs in der JVM und/oder dem JDK basieren. Oder meinst du dass das Browser-Plugin ein grundlegend anderes, schlechteres JDK verwendet als normale Anwendungen? Oder vielleicht dass die ganzen Bugs alle nur im Browser-Plugin-spezifischen Code zu Hause waren? Das ist nämlich nicht der Fall, ein grosser Teil sind einfach ganz normale Bugs im JDK.
Ich behaupte einfach mal, dass das alles nur für das Browser Plugin relevant ist. Nur dort gibt es überhaupt das Sicherheitskonzept einer Sandbox aus der ein Javaprogramm nicht ausbrechen darf, deshalb kann es auch nur dort Sicherheitslücken geben. In anderen Zusammenhängen dürfen Javaprogramme sowieso alles machen. ...wie C++ Programme auch.
-
Dann behaupte ich mal dass du damit falsch liegst. Klick mal auf
https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19116/Oracle-JDK.html
und lies dir die Beschreibung von ein paar der vielen "10er" Bugs durch.
Da geht es nicht um Sandboxing Verletzungen. Da geht es um schlimme Bugs im JDK/JRE. Remote Code Execution und so, echt krasser Scheiss.Guck dir z.B. mal diesen Bug an:
https://www.cvedetails.com/cve/CVE-2013-5907/
OK, da steht dass Oracle die Vermutung nicht bestätigt hat, aber das tut Oracle sowieso nie. Worum es mir geht ist das Verständnis was mit "vectors via X" gemeint sein kann. Kann also heissen dass es reicht wenn dein Programm ein prepariertes Datenfile lädt und dem JDK zum Dekodieren füttert.Es betrifft also definitiv nicht nur das Browser Plugin. Es betrifft viel viel mehr. Wird bloss von vielen totgeschwiegen oder falsch dargestellt. Vermutlich weil Java auf dem (privaten) Desktop nicht mehr wirklich relevant ist, weil so verflixt wenige "nicht enterprisige" Anwendungen in Java geschrieben sind.
----
Das Browser Plugin ist nur deswegen besonders in Verruf, weil es uns als sicher verkauft wurde - und in Wirklichkeit leider überhaupt nicht sicher ist. Und weil es, wenn man seinen Browser auf "ausführen ohne nachfragen" eingestellt hat, den Brain.exe Virenscanner komplett umgeht - weil man ja nichtmal mitbekommt dass man ein Java-Applet startet wenn man auf einen Link auf ne infizierte Seite klickt.
-
Bin ich blind oder steht da nie, welche API betroffen ist?
-
Das steht da nie. Weil Oracle zu feige ist.
Und nu? Ist deswegen jetzt alles nur erfunden weil das da nicht steht?ps: Wobei grob um was es geht steht da schon. Das ganze "vector related to X" halt.
-
Naja, ist von daher interessant, dass ich mir im Vergleich mal Apache angeschaut habe. Und da sind einige "kritische" Bugs in äußerst selten genutzten und unkritischen Komponenten gelistet.
-
Wenn man korrekte und sichere C++ Programme schreibt, dann funktionieren die auch korrekt und sicher.
Wer schreibt denn bitte korrekte und sichere C++-Programme? Das dürfte doch wohl die absolute Minderheit sein.
-
hustbaer schrieb:
Ich erkenne nur dein Argument nicht an, weil das Argument halt Blödsinn ist.
DAS ist natürlich ein Argument
Nur Sarkasmus
Brauchst nicht darauf anworten, ich geb dir ansonsten völlig Recht.
-
LOLometer schrieb:
Wenn man korrekte und sichere C++ Programme schreibt, dann funktionieren die auch korrekt und sicher.
Wer schreibt denn bitte korrekte und sichere C++-Programme? Das dürfte doch wohl die absolute Minderheit sein.
Vor allem kann niemand beweisen, dass ein Programm sicher und korrekt ist, höchstens das Gegenteil.
Naja, außer man taucht in die Tiefen der puren, funktionalen Sprachen ab. Aber "Unsicherheit" ist in erster Linie bei Netzwerkprogrammen relevant, da wird es schwierig, Korrektheit zu beweisen.
-
Naja doch, beweisen kann man das schon meistens. Ist nur oft sehr mühsam.
-
hustbaer schrieb:
Das steht da nie. Weil Oracle zu feige ist.
Ich glaub eher, Oracle interessiert das gar nicht.
-
Verstehe nicht - wie soll sie das nicht interessieren? Die fixen die Fehler ja, also müssen sie sich "dafür interessieren", und dann auch wissen was genau betroffen ist/war.
Oder meinst du dass sie einfach nur für den letzten Schritt das auch in der Fehlerdatenbank einzutragen zu faul sind?
-
hustbaer schrieb:
Verstehe nicht - wie soll sie das nicht interessieren? Die fixen die Fehler ja, also müssen sie sich "dafür interessieren", und dann auch wissen was genau betroffen ist/war.
Oder meinst du dass sie einfach nur für den letzten Schritt das auch in der Fehlerdatenbank einzutragen zu faul sind?So wie sich Oracle seit einiger Zeit verhält....Ich denke Java ist für die nur ein notwendiges übel.
