Geschwindigkeit vs. Sicherheit
-
finix schrieb:
Um. Ja.
Soll ich jetzt die JNI-Dokumentation zitieren um zu zeigen was auf den Java-Entwickler so alles zukommt? (
)Oh man. Du willst mir bei einem "Java ist plattformunabhängig" vorhalten, dass man auch mit Java fremden Code nutzen kann, der in anderen Programmiersprachen geschrieben ist? Das ist echt kreativ!
finix schrieb:
Was meinst du eigentlich mit diesem ominösen "usw"? Was, außer dem wrappen von plattformspezifischem Code, wenn überhaupt (Stichwort: Libraries), kommt denn noch alles auf den C++ Entwickler zu?
mit "usw." meinte ich, dass der Artikel von Shade noch deutlich länger ist. Ich habe ihn nicht ganz gelesen. Weiß nicht, was da noch kommt.
-
Lasst mich mal die Diskussion zusammen fassen.
Also was wir hier haben:
* Java hat Gegenüber C++ den Vorteil, das Index-Probleme nicht erlaubt sind
* C++ kann man so programmieren, das Index-Probleme nicht erlaubt sind
* Java hat Sicherheitsprobleme in seinen Werkzeugen
* Java hat irgend einen Sicherheits-Manager, der Java-Programmen spezielle Verbote auflegen kann (wenn er nicht gerade eine Sicherheitslücke hat) und das soll Java gegenüber C++-Programmen sicherer machen
* Jedes beliebige Programm (sowohl C++, als auch Java) kann man in einer VM betreiben um sich vor Schadhaften verhalten zu schützenGut. Das kann man ja auch wunderbar als Ende der Diskussion nehmen.
Mein Fazit: Es wurde nicht gezeigt, das Java mehr Sicherheit bietet.
-
Gregor schrieb:
finix schrieb:
Um. Ja.
Soll ich jetzt die JNI-Dokumentation zitieren um zu zeigen was auf den Java-Entwickler so alles zukommt? ( )Oh man. Du willst mir bei einem "Java ist plattformunabhängig" vorhalten, dass man auch mit Java fremden Code nutzen kann, der in anderen Programmiersprachen geschrieben ist? Das ist echt kreativ!
Genau, ebenso kreativ wie zu übersehen das C/C++ an sich auch plattformunabhängig sind und dass es für den überwiegenden Teil der Aufgaben die man im Normalfall so bewältigen möchte plattformunabhängige Bibliotheken gibt.
Gregor schrieb:
finix schrieb:
Was meinst du eigentlich mit diesem ominösen "usw"? Was, außer dem wrappen von plattformspezifischem Code, wenn überhaupt (Stichwort: Libraries), kommt denn noch alles auf den C++ Entwickler zu?
mit "usw." meinte ich, dass der Artikel von Shade noch deutlich länger ist. Ich habe ihn nicht ganz gelesen. Weiß nicht, was da noch kommt.
Ach so. Tschuldigung, ich dachte du wüsstest worüber du sprichst und hättest selber Argumente.
(Nicht dass wir uns missverstehen, Java ist toll, und bei z.B. Applets hat es durchaus einen gewaltigen Vorteil, aber viel weiter geht's auch nicht in Sachen Plattformunabhängigkeit.)
-
BTW: Ich möchte nochmal betonen, dass mögliche Sicherheitslücken in der JVM keinerlei Auswirkungen haben, wenn man dem Programm vertraut. Was ich damit meine, ist folgendes: Wenn man einen Browser in Java schreibt, ist es praktisch unmöglich, dass irgendwer durch eine manipulierte Homepage oder so Code einschleust, der dann ausgeführt wird. Die Sicherheitslücken der JVM betreffen nur Programme, die man direkt auf der JVM laufen lässt, denen man nicht vertraut. Solche Programme könnten rein theoretisch so eine Sicherheitslücke ausnutzen, um vielleicht aus der Sandbox auszubrechen. Für einen "Java-Browser" ist das aber irrelevant. Man kann in den Browser ansich keinen Code einschleusen, da dieser ja in Java geschrieben wäre und entsprechend keine Buffer overruns usw. vorkommen können. Entsprechend kann man von außen auch nicht zur JVM durchdringen und deren Sicherheitslücken ausnutzen. Naja, ok: Wenn man dem Browser vertraut, lässt man ihn ja eh nicht in einer Sandbox laufen, was aber auch nicht nötig ist. Wie schon gesagt: Soetwas wie diese JPG-Sicherheitslücke wäre in Java nicht möglich.
-
Mein Fazit: Es gibt Leute, die sind anderen Sprachen/ Technologien gegenüber aufgeschlossen. Und dann gibt es Leute, die sind es nicht.
In diesem Sinne...
-
rüdiger schrieb:
C++ kann man so programmieren, das Index-Probleme nicht erlaubt sind
Wobei das irgendwie zu wenig Leute machen, denn Sicherheitslücken in C++ Programmen sind real. Und das spricht dafür, dass es gut ist, einen entsprechenden Zwang für solche Index-Checks von der Sprache her vorzugeben.
-
Ich weiss jetzt nicht, ob das C++ ist, aber das letzte prominente Opfer, dass mir jetzt spontan einfällt, ist das hier:
-
finix schrieb:
Genau, ebenso kreativ wie zu übersehen das C/C++ an sich auch plattformunabhängig sind und dass es für den überwiegenden Teil der Aufgaben die man im Normalfall so bewältigen möchte plattformunabhängige Bibliotheken gibt.
Ich habe einmal eine Erfahrung mit Qt gemacht und das reicht mir praktisch schon, was diese plattformübergreifenden Bibliotheken betrifft: Die sind auch nicht so perfekt, wie man es vielleicht annehmen sollte. Gerade wenn man irgendwelche nativen GUI-Komponenten nutzt, die zum Beispiel auf anderen Plattformen nicht vorhanden sind. Resultat: Das Qt-Programm hat unter Windows funktioniert, unter Linux nicht. ...ich muss dazu sagen, dass das Programm nicht von mir war.
Und wenn Du ansonsten von "C++ ist plattformunabhängig" sprichst, dann hast Du zwar recht, wenn man davon absieht, dass ziemlich viel Verhalten nicht direkt definiert ist bzw. nur schwache Zusicherungen existieren, aber der Funktionsumfang von C++ geht ja auch gegen 0. Du bist für fast alles auf irgendwelche Bibliotheken von Dritten angewiesen, die mehr oder weniger plattformunabhängig sein können. Qt gilt als plattformübergreifend, zeigt aber anscheinend trotzdem stark unterschiedliches Verhalten auf unterschiedlichen Plattformen. Ist das eigentlich bei vielen plattformübergreifenden C++ Bibliotheken so?
IMHO wäre der erste Schritt zur Besserung, die Schwächen überhaupt zu erkennen. Aber aus meiner Sicht ist die C++-Welt immer noch in einer Leugnungsphase. Wirklich schade.
-
Gregor schrieb:
BTW: Ich möchte nochmal betonen, dass mögliche Sicherheitslücken in der JVM keinerlei Auswirkungen haben, wenn man dem Programm vertraut. Was ich damit meine, ist folgendes: Wenn man einen Browser in Java schreibt, ist es praktisch unmöglich, dass irgendwer durch eine manipulierte Homepage oder so Code einschleust, der dann ausgeführt wird. Die Sicherheitslücken der JVM betreffen nur Programme, die man direkt auf der JVM laufen lässt, denen man nicht vertraut. Solche Programme könnten rein theoretisch so eine Sicherheitslücke ausnutzen, um vielleicht aus der Sandbox auszubrechen. Für einen "Java-Browser" ist das aber irrelevant. Man kann in den Browser ansich keinen Code einschleusen, da dieser ja in Java geschrieben wäre und entsprechend keine Buffer overruns usw. vorkommen können. Entsprechend kann man von außen auch nicht zur JVM durchdringen und deren Sicherheitslücken ausnutzen. Naja, ok: Wenn man dem Browser vertraut, lässt man ihn ja eh nicht in einer Sandbox laufen, was aber auch nicht nötig ist. Wie schon gesagt: Soetwas wie diese JPG-Sicherheitslücke wäre in Java nicht möglich.
pcwelt schrieb:
...
Eigentlich sollten Java-Applets in der so genannten "Sandbox", der Java-Laufzeitumgebung, ablaufen und nicht auf beliebige lokale Dateien zugreifen können. Ausnahmen sind signierte Applets, die als "trusted" (vertrauenswürdig) eingestuft sind. Durch die von Adam Gowdiak entdeckte Schwachstelle ist dies auch beliebigen "untrusted" Applets möglich. Sie können Dateien lesen und schreiben sowie installierte Anwendungen starten. Sie dürfen im Prinzip alles, was der angemeldete Benutzer darf. Eine ähnlich problematische Schwachstelle in Java Web Start wurde bereits im März bekannt und gestopft .
...http://www.pcwelt.de/news/sicherheit/113883/index.html
Ist die Meldung falsch?
-
Gregor schrieb:
finix schrieb:
Inwiefern sind denn die Probleme "viel geringer"?
Oh, lass uns doch mal gucken, was da auf den C++-Entwickler zukommt:
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1014628.html
...
...usw.Bei Java sähe das so aus: "Du musst darauf achten, dass Du nicht künstlich irgendwelche Plattformabhängigkeiten in den Code einbaust."
Das Problem dreht sich also komplett um.
Ehm, du bist also der Meinung, das ich als C++ Programmierer mir meine eigenen Wrapper programmieren MUSS? Der Artikel zeigt nur, wie ich fehlende Platformübergreifende Libs selbst entwickeln KANN.
Aber ich kann wie jeder Java-Programmierer (dazu zähle ich übrigens auch!) auch fertige Platformübergreifende Libs verwenden. Das tue ich in C++ übrigens so ziemlich 100%ig, ich habe noch nie selber einen Wrapper bzgl. Plattformen geschrieben. Weil ich bisher immer fertige Platformübergreifende Libs gefunden habe. Du stellst es aber so hin, als ob jeder C++ Programmierer für seine Projekte erstmal Wochen lang Wrapper schreiben muß. Aber irgendjemand bei Sun hatte auch für die Java-Runtime erstmal Wrapper geschrieben, oder?
-
Ist das eigentlich bei vielen plattformübergreifenden C++ Bibliotheken so?
Keine Ahnung, aber ich hab regelmäßig Probleme, wenn ich meine C++ Programme, die mit gtkmm geschrieben sind, nach Windows portieren will. Mir fliegen dann immer Exceptions um die Ohren, die ich unter GNU/Linux nicht bekommen habe. Der Witz ist, dass ich keine Zeile plattformabhängigen Codes (außer vllt. der, der unter Windows die Shell mit FreeConsole() verschwinden lässt) verwendet habe.
Ergo gehe ich davon aus, dass die glibmm-DLL unter Windows hier das Problem darstellt. Schade.Wenn jede Lib so portabel wie boost wäre, dann wär's natürlich cool, aber das ist leider nicht ganz der Fall.
-
Zeus schrieb:
Ist die Meldung falsch?
Vermutlich nicht. Aber sie widerspricht auch nicht meiner Aussage. Ein Applet ist ein Programm, dem man im Allgemeinen nicht vertraut, das direkt auf der JVM läuft. Wenn so ein Programm durch eine Sicherheitslücke in der JVM aus der Sandbox ausbrechen kann, dann hat es entsprechend mehr Rechte.
Ich wollte mit dem Absatz oben sagen, dass Sicherheitslücken in der JVM und die Sicherheit von Javaprogrammen zwei unterschiedliche Sachen sind, die auch nicht zusammenhängen. Das eine hat mit bösartigen Programmen zu tun, das andere hat mit Sicherheitslücken in Programmen zu tun. Durch die Sicherheitslücken in der JVM sind NICHT automatisch auch Sicherheitslücken in Javaprogrammen.
-
Gregor schrieb:
finix schrieb:
Genau, ebenso kreativ wie zu übersehen das C/C++ an sich auch plattformunabhängig sind und dass es für den überwiegenden Teil der Aufgaben die man im Normalfall so bewältigen möchte plattformunabhängige Bibliotheken gibt.
Ich habe einmal eine Erfahrung mit Qt gemacht und das reicht mir praktisch schon, was diese plattformübergreifenden Bibliotheken betrifft: Die sind auch nicht so perfekt, wie man es vielleicht annehmen sollte. Gerade wenn man irgendwelche nativen GUI-Komponenten nutzt, die zum Beispiel auf anderen Plattformen nicht vorhanden sind. Resultat: Das Qt-Programm hat unter Windows funktioniert, unter Linux nicht. ...ich muss dazu sagen, dass das Programm nicht von mir war.
Sicher dass das Problem an Qt lag? Qt wrappt nicht die kümmert sich quasi um alles selbst...
Aber du hast natürlich Recht, insbesondere wenn man plattformspezifische Funktionalitäten nutzt muss man natürlich wissen was man tut - aber das ist in Java nicht anders.Gregor schrieb:
Und wenn Du ansonsten von "C++ ist plattformunabhängig" sprichst, dann hast Du zwar recht, wenn man davon absieht, dass ziemlich viel Verhalten nicht direkt definiert ist bzw. nur schwache Zusicherungen existieren, aber der Funktionsumfang von C++ geht ja auch gegen 0. Du bist für fast alles auf irgendwelche Bibliotheken von Dritten angewiesen, die mehr oder weniger plattformunabhängig sein können. Qt gilt als plattformübergreifend, zeigt aber anscheinend trotzdem stark unterschiedliches Verhalten auf unterschiedlichen Plattformen. Ist das eigentlich bei vielen plattformübergreifenden C++ Bibliotheken so?
Meine Erfahrungen mit Qt im speziellen halten sich in Grenzen, hatte aber eigentlich einen ganz guten Eindruck davon.
In Bezug auf die Bibliotheken: natürlich braucht man die, aber das ist bei Java nicht anders. Bei Java ist schlicht die Standard-Bibliothek umfangreicher (und dass die nicht unbedingt immer perfekt ist sieht man allein an der Existenz von Swing und insbesondere SWT).Gregor schrieb:
IMHO wäre der erste Schritt zur Besserung, die Schwächen überhaupt zu erkennen. Aber aus meiner Sicht ist die C++-Welt immer noch in einer Leugnungsphase. Wirklich schade.
Dafür ist Java direkt in diese Leugnungsphase gestartet
-
Gregor schrieb:
Ich wollte mit dem Absatz oben sagen, dass Sicherheitslücken in der JVM und die Sicherheit von Javaprogrammen zwei unterschiedliche Sachen sind, die auch nicht zusammenhängen. Das eine hat mit bösartigen Programmen zu tun, das andere hat mit Sicherheitslücken in Programmen zu tun. Durch die Sicherheitslücken in der JVM sind NICHT automatisch auch Sicherheitslücken in Javaprogrammen.
Ja, stimmt, nur wenn sie von der JVM ausgeführt werden
-
finix schrieb:
Gregor schrieb:
Ich wollte mit dem Absatz oben sagen, dass Sicherheitslücken in der JVM und die Sicherheit von Javaprogrammen zwei unterschiedliche Sachen sind, die auch nicht zusammenhängen. Das eine hat mit bösartigen Programmen zu tun, das andere hat mit Sicherheitslücken in Programmen zu tun. Durch die Sicherheitslücken in der JVM sind NICHT automatisch auch Sicherheitslücken in Javaprogrammen.
Ja, stimmt, nur wenn sie von der JVM ausgeführt werden
Nein, Du irrst Dich. Ich wollte eben genau darauf hinweisen, dass das nicht so ist. Als "externer Angreifer" kommt man nicht an die JVM bzw. deren Sicherheitslücken heran, weil man keinen Code in die laufende Javaanwendung einschleusen kann. Und in den Javaanwendungen können zumindest keine Sicherheitslücken auftreten, die auf Buffer overruns oder so basieren.
Zeig mir doch mal eine Meldung, dass in einem Javaprogramm eine Sicherheitslücke aufgetreten ist. ...die JVM ist kein Javaprogramm.
-
finix schrieb:
Gregor schrieb:
IMHO wäre der erste Schritt zur Besserung, die Schwächen überhaupt zu erkennen. Aber aus meiner Sicht ist die C++-Welt immer noch in einer Leugnungsphase. Wirklich schade.
Dafür ist Java direkt in diese Leugnungsphase gestartet
Nein, Du irrst Dich. Die Javawelt hatte zum Beispiel mal erkannt, dass Java ein Performanceproblem hatte. Daran wurde dann gearbeitet. Inzwischen ist es vielleicht noch nicht komplett behoben, aber es hat sich um Größenordnungen verringert. Bei Java wird also an den Schwächen gearbeitet.
-
Gregor schrieb:
rüdiger schrieb:
C++ kann man so programmieren, das Index-Probleme nicht erlaubt sind
Wobei das irgendwie zu wenig Leute machen, denn Sicherheitslücken in C++ Programmen sind real. Und das spricht dafür, dass es gut ist, einen entsprechenden Zwang für solche Index-Checks von der Sprache her vorzugeben.
nöö.
das spricht nur dafür, daß projekte, wo der indexzwang sinnvoll ist, java (oder andere sprachen ohne indexfehlermöglichkeit) nehmen. ups, indexfehlermöglichkeit gibts ja immer. nur die behandlung ist anders. wenn ich den java-mailserver bei jedem indexfehler per exception kille und er erst 5 minuten später reinkarniert, ist das auch eine sicherheitslücke. wirksame dos-attacke mit 144-er modem. man könnte die mitarbeiter wirksam zwingen, in c++ keine rohen arrays zu benutzen, sondern nur welche mit indexgrenzencheck.
aber für mich ist das ein historisches problem. in c war das üblich.
nett wäre eine änderung des standards, daß man rohe arrays und dergleichen mit einer warnung versieht, außer, der programmierer scheibtchar i[39];//i_know_what_i_doals kommentar dahinter. das kann ich als projektleiter dann leicht automatisiert suchen und gegebenenfalls gestatten und die datei nach gestattung mit md5 versiegeln.
-
Gregor schrieb:
Bei Java wird also an den Schwächen gearbeitet.
Das ist doch bei C++ auch nicht anders. Siehe die TRs und den neuen Standard.
-
Jester schrieb:
Gregor schrieb:
Bei Java wird also an den Schwächen gearbeitet.
Das ist doch bei C++ auch nicht anders. Siehe die TRs und den neuen Standard.
Ja, in der Tat. Ich erhoffe mir von dem nächsten C++ Standard einiges. Hoffentlich kommt der bald. ...wobei ich die Entwicklung von C++ insgesamt für zu langsam halte, aber das ist wohl eine subjektive Meinung. Werden im neuen Standard solche Index-Checks angegangen? Was ist momentan das angepeilte Datum für den neuen Standard?
-
finix schrieb:
In Bezug auf die Bibliotheken: natürlich braucht man die, aber das ist bei Java nicht anders. Bei Java ist schlicht die Standard-Bibliothek umfangreicher (und dass die nicht unbedingt immer perfekt ist sieht man allein an der Existenz von Swing und insbesondere SWT).
Swing IST Teil der Standard-Bibliothek!
