Geschwindigkeit vs. Sicherheit

Zeus

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?

Artchi

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?

GPC

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.

Gregor

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.

finix

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

finix

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

Gregor

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.

Gregor

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.

volkard

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 scheibt

char i[39];//i_know_what_i_do

als kommentar dahinter. das kann ich als projektleiter dann leicht automatisiert suchen und gegebenenfalls gestatten und die datei nach gestattung mit md5 versiegeln.

Jester

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.

Gregor

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?

byto

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!

Gregor

byto schrieb:

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!

Und SWT ist IMHO übrigens eine Modeerscheinung, die in ein paar Jahren wieder weg sein wird. Swing ist einfach viel angenehmer zu nutzen und die Gründe, die für SWT sprechen, verschwinden mit der Zeit. IMHO sind sie heute schon weg.

volkard

Gregor schrieb:

wobei ich die Entwicklung von C++ insgesamt für zu langsam halte, aber das ist wohl eine subjektive Meinung.

die teile ich.

Werden im neuen Standard solche Index-Checks angegangen?

wäre ganz untypisch. man kann sich ja indexgrenzenprüfende klassen bauen.

afair gab es irgendwo einen vorschlag, daß beim vector der op[] prüfen soll, weil eh kein arsch at() verwendet. weiß aber nicht mehr, ob der ernst gemeint war.
korrekt wäre, daß at() weiterhin ne exception wirft und [] ne assertion. also abschaltbar für den release-code bei []. und das ist eigentlich allein sache der bibliothekenbauer.

Jester

Ich bin zuversichtlich, daß so ein assert bereits heute in meiner stdlib-Implementierung drinsteht.

finix

byto schrieb:

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!

Da ging's um Gregor's Argument dass bei Java gleich alles dabei ist, und man nicht auf Bibliotheken von Dritten angewiesen ist.
/edit

Hm. Da demonstrierst du natürlich ein sehr gutes Argument. Aber ich denke das Sicherheitsmodell von Java geht immer noch nicht weit genug für Leute die noch nicht einmal einen einzigen, unkomplizierten Satz korrekt lesen können.

SideWinder

@finix: Wird er durch solche Aussagen eigentlich länger?

MfG SideWinder

Gregor

finix schrieb:

für Leute die noch nicht einmal einen einzigen, unkomplizierten Satz korrekt lesen können.

Und als nächstes Argument kommt dann "Der ist nicht korrekt, denn Du hast da nen Rechtschreibfehler.". Toll. Ich glaube, ganz so tief müssen wir mit dem Niveau in diesem Thread nicht unbedingt gehen. Im Übrigen habe ich auch nicht verstanden, worauf Du mit Deinem Beitrag da eigentlich hinaus wolltest. Vielleicht stellst Du es einfach klar, dann redet man nicht mehr aneinander vorbei.

finix

SideWinder schrieb:

@finix: Wird er durch solche Aussagen eigentlich länger?

Ja, und wie. Solltest du auch mal probieren, dann ziehst du vielleicht nicht immer den kürzeren...

finix

Gregor schrieb:

finix schrieb:

für Leute die noch nicht einmal einen einzigen, unkomplizierten Satz korrekt lesen können.

Und als nächstes Argument kommt dann "Der ist nicht korrekt, denn Du hast da nen Rechtschreibfehler.". Toll. Ich glaube, ganz so tief müssen wir mit dem Niveau in diesem Thread nicht unbedingt gehen. Im Übrigen habe ich auch nicht verstanden, worauf Du mit Deinem Beitrag da eigentlich hinaus wolltest. Vielleicht stellst Du es einfach klar, dann redet man nicht mehr aneinander vorbei.

Es ging einfach um die "Bibliotheken von Dritten" die man verwendet. Swing war einfach nur ein Beispiel dafür dass die Standard-Bibliotheken auch nicht immer das wahre sind - d.h. wäre AWT so toll gewesen gäbe's kein Swing, wäre Swing problemfrei gäbe es kein SWT.