Geschwindigkeit vs. Sicherheit

[Artchi]

Hier mal ein Blog eines Java-Fans:
http://weblogs.java.net/blog/evanx/archive/2006/10/pulp_diction_2.html

Köstlich, die Vorteilel Java ggü. C++:
5 Java Libraries. Sweeet. What would life be without Collections? A boring singleton.

Ehm, nie was von der Standard C++ Library gehört?

6 Swing. The sweeetest, GUI'est thing!

Swing ist tatsächlich cool, kann man wirklich schnell mal ne GUI basteln. Aber ist ja nicht so, das es für C++ nicht auch GUIs gibt.

7 Frameworks. What you want? You got it. Goto Apache, Spring, Google, or the guy sitting next to you in the bus.

Boost? Adobe Open Source? ACE? wxWidgets?

8 Enterprise-ready stacks? Take your pick!

Hem, ist damit JEE gemeint? Für den IIS gibts die ATL, finde ich cool und wird von meinem VisualC++ 2003 super unterstützt. ACE gibts ja auch noch.

[Gast]

Hat sowieso alles nichts mit der Sprache zu tun. Was mit der Sprache zu tun hat, sind die erwähnten Sicherheitsprobleme. Der Typ von dem Blog ist wahrscheinlich ein komischer Mensch und 95% der Weblogs sind Datenmüll.

[rüdiger]

Jester schrieb:

Ist wie mit GUI und Threading. In C++ muß man sich seine Sicherheitslücken selbst schreiben, bei Java sind sie im Lieferumfang enthalten.

gurkenesser schrieb:

@rüdiger ( http://www.c-plusplus.net/forum/viewtopic-var-p-is-1163194.html#1163194 )
es geht um sicherheit und nicht um fehlverhalten durch programmierfehler

ja. Aber ich sehe immer noch nicht, wo Java da helfen soll.

gurkenesser schrieb:

und "solange Terabyte-RAM nicht handelsüblich ist, sehe ich keinen Grund Java-Software einzusetzen. " ist wohl das typische letzte "argument" wenn man keine ahnung mehr hat, oder?

Vielleicht, wenn man unlimitiert Geld hat. Ist aber auch nicht mein letztes Argument.

Optimizer schrieb:

Entschuldigt mal. Keiner sagt, dass Sicherheitsprobleme ein Grund sind, zukünftig alles mit Java zu machen.

Doch, ich glaube das war der Grund warum der Thread gestartet wurde.

Optimizer schrieb:

Aber die Sicherheitsprobleme durch buffer overruns sind real und nicht auf vereinzelte inkompetente Programmierer zurückzuführen.

doch, weil sie auf inkompetente Programmierer zurückzuführen sind. Naja, vielleicht auch auf eine alte zu große Code-Base.

Optimizer schrieb:

Es ist ein grundsätzliches Problem, dass durch FEHLER der Programmierer immer auftreten kann, wenn die Sprache keine Sicherheitsstandards erzwingt - unabhängig von Bildung, Erfahrung und Bösartigkeit.

Gut eine Programmiersprache die Index-Überprüfung erzwingt, verhindert Fehler durch mangelnde Index-Überprüfung. Das hätten wir glaube ich geklärt. Der Punkt ist ja, das eine Programmiersprache die dies nicht erzwingt, eben auch sicher sein kann. Man kann ja ohne Probleme Index-Überprüfung auf einer höheren Ebene erzwingen. Natürlich kann man das umgehen, wenn man böswillig ist. Aber man kann wenn man böswillig ist und den Quellcode beliebig ändern kann auch andere Böse sachen machen. Auch mit Java oder wer weiß was man noch so für "sicher" hält.

Optimizer schrieb:

Keiner hat gesagt, dass die Verwendung von Java grundsätzlich alle Sicherheitsprobleme löst. Gerade in Zeiten, wo verteilte Anwendungen wieder interessanter werden, muss man umfangreiche Maßnahmen schon beim Design der Software und ihrer Schnittstellen nach außen ergreifen, was keineswegs trivial ist. Was jedoch trivial ist, sind buffer overruns die im Jahre 2006 schon längst der Vergangenheit angehören könnten. Konzepte, diese zu vermeiden, gibt es seit Jahrzehnten und Java setzt eines davon um. Es handelt sich also um keine Innovation von Java und keiner hier ist so vernarrt, das zu behaupten. Es ist eher ein Stillstand von C++ gewesen. Da braucht man nicht auflabern von wegen "die kiddies ham's halt falsch gemacht".

Wie gesagt, in C++ kann man das auch erreichen. C++ zwingt einen eben zu nix. Aber wenn man nicht will, dann eben nicht.

Sandbox: wenn ich mich unter einem Multiuser-/Multisession-OS als normaler User anmelde (nicht als Admin), ist das nicht schon sozusagen eine Sandbox? Ist der Speicherschutz einer CPU nicht schon eine abgeregelte Programmlaufzeitumgebung? Wenn ich einen Server betreibe, kann ich nich einfach durch Virtualisierung die einzelnen Server-Programme gegenseitig schützen?

Das Problem bei den von dir genannten Verfahren ist, dass sie eigentlich zu spät greifen, da sie nichts über die internas und die Logik des Programms wissen. Mit dem Speicherschutz musst du jeden Speicherzugriff überwachen, nicht nur die, auf die es ankommt.

Macht die MMU doch eh. Daher gibt es ja Segmentation-Faults.

Außerdem kannst du nie die Rechte so weit einschränken, dass nichts passieren kann. Wenn du deinem Webbrowser was runterladen lassen willst, braucht er das Recht, die Datei anzulegen. Also kann ich über nen buffer overflow schon wieder Code einschleußen (leider geschieht das einschleußen von Code vollständig innerhalb des Browser-Prozess und kann damit kaum vom Speicherschutz verhindert werden. Auch AMDs tolles NX-Flag hilft da nicht zuverlässig), der die alle heruntergeladenen Dateien manipuliert, so dass sie was böses macht, sobald sie ausgeführt wird.

Das verstehe ich nicht. Was kann ein Buffer Overflow machen, weil man eine Datei runterlädt und wie verhindert eine Sandbox, das man eine Datei runterlädt, wenn man eine Datei runterladen will?

Alles was dann vom Betriebssystem kommt, ist nur Schadensbegrenzung: Die böse Datei kann halt nur mein Home löschen und nicht alle Programme, im Kontext des Users halt. Aber das Betriebssystem erkennt NIE, dass ein Programm nicht das macht, wofür es vorgesehen wurde.

erkennt eine Sandbox ja auch nicht, sie kann nur Schadensbegrenzung betreiben: Die böse Datei kann halt nur die Dateien löschen, auf die es zugreifen darf, im Kontext der Sandbox halt.

Nimm als Beispiel die JPG-Sicherheitslücke in Windows: Das Betriebssystem erkennt nicht, dass Paint nicht das macht, was es soll. Es erlaubt dem Programm im Kontext seines Users alles und das ist schlimm genug.

das ist schlimm an Windows. Aber nicht generell schlimm.

Taschenlampe schrieb:

Wieso sagt eigentlich kein C++ befürworter was zu dem 2038er Problem?

Welches 2038er Problem?

Taschenlampe schrieb:

Irgendwie muss man doch in C++ ständig irgendwelche sachen einführen, damit man nicht soviel kaputt machen kann.

Das nennt man Freiheit. Wenn man Sicherheit will, dann benutzt man Eben Container wie std::vector oder ähnliches.

Optimizer schrieb:

Ich wollte auf den Fall raus, der eigentlich der problematische ist: Du vertraust dem Programm, aber es wird auf Grund eines Programmierfehlers zum Zombie. Das und nicht von sich aus schon böse Programme sind das Problem. Weil die Programme, denen du vertraust, haben Rechte, die gefährlich sind. Würdest du dem Firefox vertrauen?

Wenn du einem Programm sowieso nicht vertraust, kannst du ihm gleich alle Rechte entziehen, die über das Belegen von 2MB RAM hinausgehen. Oder gar nicht starten. Hier kommt die Sicherheit von Bufferoverflows nicht zum Tragen, denn wir unterstellen mal ein sicheres Betriebssystem, dass Einschränkungen zuverlässig durchsetzen kann.

"Sicherheit von Bufferoverflows"? Und was hat das ganze mit C++ zu tun und was soll Java da besser machen?

[lolz]

Warum lasst ihr euch eigentlich immer wieder auf eine Java vs. C++ Diskussion ein?

[Gregor]

Artchi schrieb:

gregor schrieb:

...es ist ja sogar so, dass die Sicherheitslücken in Java auf C++ zurückzuführen sind. Die existieren nicht im Javacode, sondern in der JVM, die in C++ geschrieben ist.

Ist das nicht die Schuld der JVM-Programmierer? Und die sitzen doch direkt bei SUN, oder? Weiterhin: ich hatte mal einen Memorydump, weil ich es geschafft hatte, die JVM zum Absturz zu bringen. Was soll ich sagen? Im Output stand was von MSVC6!!! Hallo? Und das in einer JVM 1.5!

Hmmm... Die C++ler sehen immer sämtliche Schuld beim Programmierer, die Javaleute gehen hingegen davon aus, dass es den perfekten Programmierer, der keine Fehler macht, nicht gibt. Das ist ja auch ein Grund, warum die Javaleute eben Java nutzen: Da werden viele Fehler, die einem mit C++ assieren können, nicht ermöglicht. Insofern würde ich da auch nicht von der Schuld des JVM-Programmierers reden. Bugs und andere Probleme entstehen halt, wenn man ein komplexes System entwickelt. Wenn man dazu Werkzeuge nutzen muss, die mehr Bugs und andere Probleme zulassen als andere Werkzeuge, dann entstehen eben auch entsprechend mehr Bugs und andere Probleme. Die JVM kannst Du selbst nicht in Java schreiben, insofern ist es da eine Notwendigkeit, eine Sprache wie C++ zu verwenden.

Ansonsten weiß ich nicht, welche Formen der Qualitätssicherungen bei der Entwicklung der JVM vorkommen. Ich weiß nur, dass da durchaus sehr stark drauf geachtet wird. Java 6 wird momentan massiv getestet. ...zwei bis drei Monate lang, weiß nicht so genau. In dieser Zeit sind zumindest jegliche Änderungen am Code verboten. Es dürfen keine neuen Features eingeführt werden und es dürfen auch keine normalen Bugs behoben werden. ...nur absolute Showstopper werden behoben. Vergleich das mal mit der Qualitätssicherung von MS: Da wird bis zur letzten Sekunde an Vista gewerkelt und jede Änderung hat das Potental, neue Bugs einzuführen. (...ist zumindest mein Eindruck. Ich habe nicht so einen genauen Üerblick über die Entwicklung von Vista.)

...zu MSVC 6.0: Das haben durchaus auch einige Javaentwickler bemerkt und entsprechende negative Beiträge in Foren geschrieben. Ich weiß nicht mehr genau, was damals dazu gesagt wurde, aber AFAIK hat es schon größere Probleme bereitet, einfach so mal den Compiler zu wechseln. Soetwas scheint, wenn es da gemacht wird, immer mit einem größeren Aufwand verbunden zu sein. Und da stellt sich dann die Frage, inwiefern das gerechtfertigt ist: Java ist ein kommerzielles Produkt. Die Leute haben beschränkte Resourcen und müssen sich entscheiden, wieviel in was investiert wird. Der Umstieg auf einen anderen Compiler müsste also schon enorme Vorteile bieten, wenn man dadurch eine deutliche Verzögerung in der eigentlichen Entwicklung rechtfertigen will. Also auch hier: Die Welt könnte besser und perfekter sein, aber man kann halt nicht alles haben.

[otze]

rüdiger schrieb:

Taschenlampe schrieb:

Wieso sagt eigentlich kein C++ befürworter was zu dem 2038er Problem?

Welches 2038er Problem?

Das jahr 2000 problem, halt nur mit 32 bit

ist aber imho echt kein problem, da im jahre 2038 wohl kein jetziges programm mehr im umlauf sein wird(technologie entwickelt sich halt weiter, ne?), und bis dahin time_t wohl schon lange 64bit hat.

[Artchi]

Optimizer schrieb:

Hat sowieso alles nichts mit der Sprache zu tun. Was mit der Sprache zu tun hat, sind die erwähnten Sicherheitsprobleme. Der Typ von dem Blog ist wahrscheinlich ein komischer Mensch und 95% der Weblogs sind Datenmüll.

Ja, eben! Es zeigt aber sehr schön welche Meinung über C++ in den Köpfen der Leute drin ist. Und zwar eine Meinung, die falsche Informationen verbreitet. Genau die falsche Meinung war auch vom Topic-Starter gegeben, die hier diskuttiert wird.

[Gast]

groovemaster schrieb:

[Das übliche: Man kann in C++ sicher programmieren, keiner zwingt einen, was mit Pointer-Arithmetik und Arrays zu machen und das ist ja so schön, dass man es sich genau aussuchen kann]

In der Praxis funktioniert das nicht. Dazu braucht man eigentlich nur kurz einen Blick in die Welt hinaus werfen und sieht Sicherheitsprobleme hier und Sicherheitsprobleme da.

Natürlich muss man da differenzieren. Es gibt Sicherheitsprobleme, die man mit keiner Sprache der Welt verhindern kann. Aber ein erstaunlich hoher Anteil sind buffer overruns, eine Trivialität eigentlich. Da hilft aber kein std::vector dagegen, denn die Ursachen sind meistens viel tiefgründiger als direkt ein falsch gesezter Index.

Das können Fehler im Speicher-Management sein zum Beispiel ein Objekt zweimal gelöscht. Oder Funktionen, die nichts zurückgeben (== einen uninitialisierten Speicherblock zurückgeben), was C++ ja genialerweise erlaubt. Oder generell uninitialisierte lokale Variablen, was C++ ja genialerweise erlaubt (schön, dass man die Möglichkeit hat). Und überhaupt generell alles wofür der GEILE C++ Standard "undefiniertes" (== unsicheres) Verhalten vorsieht.

Und wenn man sich ansieht, wo BEISPIELSWEISE Java (hier kann man eigentlich fast alle Sprachen die ich kenne einfügen) undefiniertes Verhalten vorsieht, dann ist doch klar, dass es auf Sprachebene die Möglichkeit gibt, sichere Programme zu begünstigen.

Natürlich ist es möglich, auch in C++ ein fehlerfreies Programm zu entwickeln. Auch in einer beliebigen Assembler-Sprache und in Brainfuck ist es möglich. C++ und die anderen Alternativen (;)) haben aber ein paar Eigenarten, die das nicht gerade unterstützen und da Menschen programmieren, passieren Fehler.

[byto]

groovemaster schrieb:

Und das ist ja das schöne an C++. Du programmierst vollkommen ohne Overhead, und vertraust darauf, dass dich deine Programmierkünste nicht im Stich lassen. Oder du verwendest etwas Sicheres, weil du davon überzeugt bist, dass irgendwo schon ein Fehler sein wird oder dein Produkt diese Sicherheit einfach verlangt. Musst dann aber mit dem Overhead leben. Niemand zwingt dich zu irgendetwas. Für dich mag das ein Fluch sein, für andere ein Segen. Was gibt dir eigentlich das Recht, darüber zu urteilen?

Dieser Segen sorgte halt bis dato für zahllose Sicherheitslücken und gott-weiss wieviel Milliarden Dollar Schaden. Aber offenbar war das alles bloß von Newbs zusammengefrickelter Code, während die Sicherheitsexperten alle hier im Forum sitzen.

[Gast]

rüdiger schrieb:

"Sicherheit von Bufferoverflows"? Und was hat das ganze mit C++ zu tun und was soll Java da besser machen?

Ja entschuldigung, Sicherheit VOR buffer overflows.

[Artchi]

Das können Fehler im Speicher-Management sein zum Beispiel ein Objekt zweimal gelöscht

Smartpointer? Ist mittlerweile offizielle iSO-C++ bekannt! Kann ich garnicht ausversehen zweimal löschen. Klar, wenn ich rohe Pointer nutze. Stimmt.

Oder Funktionen, die nichts zurückgeben (== einen uninitialisierten Speicherblock zurückgeben),

Verstehe ich ehrlich gesagt nicht. Meinst du wenn ich Null zurück bekomme? Was hat das mit Sicherheit zutun?

Da hilft aber kein std::vector dagegen, denn die Ursachen sind meistens viel tiefgründiger als direkt ein falsch gesezter Index.

Beispiel?

Oder generell uninitialisierte lokale Variablen, was C++ ja genialerweise erlaubt (schön, dass man die Möglichkeit hat).

Und? Geht auch in Java. Bekomme ich halt nen Warning vom Compiler, macht aber mein MSVC7.1 auch!

[Gregor]

groovemaster schrieb:

Taschenlampe schrieb:

Sind das nicht genau die Sachen, die Hacker nutzen um irgendwo Code hinzubringen?

Das sind Bufferoverruns, wo lokale Arrays durch einen Fehler in der Anwendungen über das Ende hinaus beschrieben werden können, so dass die Rücksprungadresse der Funktion, welche sich auf dem Stack nach oben hin befindet, manipuliert wird. Bufferunderruns sind mir ehrlich gesagt in Verbindung mit C++ und Sicherheit unbekannt. Deshalb wollte ich es halt wissen. Ich kenne das nur im Zusammenhang mit dem Brennen von CDs.

Das gibt es auch in Verbindung mit der Sicherheit von Software. ...beschreibt halt den gleichen Vorgang auf der anderen Seite des Arrays.

...Google präsentiert einem da bei einer passenden Suche gleich mal so ne Sicherheitslücke:

http://archive.cert.uni-stuttgart.de/archive/win-sec-ssc/2006/09/msg00080.html schrieb:

CVE-2006-4336 - Schwachstelle in gzip

In gzip besteht eine Schwachstelle in der Funktion build_tree() in der Datei unpack.c. Eine Variable wird nicht richtig ueberprueft, was dazu fuehrt, dass eine defekte Leaf Count Tabelle mit einem negativen Index erzeugt wird (Buffer Underrun). Dadurch koennen Daten vor dem Puffer ueberschrieben werden. Ein entfernter Angreifer kann, indem er ein manipuliertes gzip Archiv zur Verfuegung stellt, diese Schwachstelle ausnutzen und das Programm zum Absturz bringen oder eventuell beliebigen Code mit den Rechten des Benutzers ausfuehren.

...ok, war da wohl C und nicht C++.

[Artchi]

Otze schrieb:

Das jahr 2000 problem, halt nur mit 32 bit

Bei Java: Das jahr 2000 problem, halt nur mit 64 bit.

[SideWinder]

Wenn ein Guru wie volkard von 15-20 Jahren spricht, nach denen man ordentlich C++ programmieren kann ist doch das absolute Killerargument schon genannt worden. Eine Sprache die eine längere Schulungsdauer als 6 Monate hat (aufbauend auf bisherigen Programmiererfahrungen) fällt in der Wirtschaft schon weg. Wurde halt leider gehyped bis zum geht nicht mehr, aber das passiert bei mehr Sprachen.

In 10 Jahren wirds wieder was neues geben.

MfG SideWinder

[SideWinder]

Artchi schrieb:

Otze schrieb:

Das jahr 2000 problem, halt nur mit 32 bit

Bei Java: Das jahr 2000 problem, halt nur mit 64 bit.

Das Y2K-Problem ist anderer Natur. Unabhängig davon hat Java dieses Problem allerdings nicht: Eine neue JRE löst das Problem.

Aber auf solchen "Problemen" Programmiersprachenentscheidungen aufzubauen ist ohnehin lächerlich. Da baut man einen Workaround oder sonstwie einen fix und weiter gehts.

Frage #1: Mit welcher Sprache erhalte ich maximalen Profit. Alle Faktoren einsammeln (Wartung, Schulungskosten, etc.) und unterm Strich steht heute sicher kein C++ mehr. C++ wird zwar immer noch viel geschrieben, aber es soll auch noch COBOL-Programmierer geben.

MfG SideWinder

[Artchi]

Volkard? Guru? Hab ich was verpasst? Habe nicht gewusst, das ich hier in einer Sekte bin. Und weil so ein mir unbekannter Typ was von 15-20 Jahren sagt, stimmt das. LOL

[Gast]

Artchi schrieb:

Das können Fehler im Speicher-Management sein zum Beispiel ein Objekt zweimal gelöscht

Smartpointer? Ist mittlerweile offizielle iSO-C++ bekannt! Kann ich garnicht ausversehen zweimal löschen. Klar, wenn ich rohe Pointer nutze. Stimmt.

Smartpointer sind natürlich die Antwort auf alles.

Oder Funktionen, die nichts zurückgeben (== einen uninitialisierten Speicherblock zurückgeben),

Damit meine ich zum Beispiel:

MyClass* foo() {
    for( ... )
         if( ... ) // programmierer denkt, das wird irgendwann schon true
              return irgendwas;
}

Nicht dass ich das für ein ernsthaftes Problem halten würde. Aber ich würde auch einen möglichen buffer overflow allein nicht für ein ernsthaftes Problem halten. Aber an lauter solchen Trivialitäten erkennt man, dass man es im C++ Standard wohl nicht so wichtig mit der Sicherheit nimmt. Dinge wie diese sind für mich schwere Schäden an der Sprache und mir außerdem vollkommen unbegreiflich.

Das Problem ist, immer wenn man ein einfaches Beispiel gibt, wo die Sprache kaputt ist, dann hacken alle darauf rum. "Ja wer SOWAS macht, ist selber schuld" Anscheinend gibt es genügend Leute, die kaputte Sachen machen und die Profis sitzen alle hier und labern, anstatt es besser zu machen.
Deshalb geb ich nicht gerne Beispiele.

[rüdiger]

Optimizer schrieb:

groovemaster schrieb:

[Das übliche: Man kann in C++ sicher programmieren, keiner zwingt einen, was mit Pointer-Arithmetik und Arrays zu machen und das ist ja so schön, dass man es sich genau aussuchen kann]

In der Praxis funktioniert das nicht. Dazu braucht man eigentlich nur kurz einen Blick in die Welt hinaus werfen und sieht Sicherheitsprobleme hier und Sicherheitsprobleme da.

Natürlich muss man da differenzieren. Es gibt Sicherheitsprobleme, die man mit keiner Sprache der Welt verhindern kann. Aber ein erstaunlich hoher Anteil sind buffer overruns, eine Trivialität eigentlich. Da hilft aber kein std::vector dagegen, denn die Ursachen sind meistens viel tiefgründiger als direkt ein falsch gesezter Index.

Das können Fehler im Speicher-Management sein zum Beispiel ein Objekt zweimal gelöscht. Oder Funktionen, die nichts zurückgeben (== einen uninitialisierten Speicherblock zurückgeben), was C++ ja genialerweise erlaubt. Oder generell uninitialisierte lokale Variablen, was C++ ja genialerweise erlaubt (schön, dass man die Möglichkeit hat). Und überhaupt generell alles wofür der GEILE C++ Standard "undefiniertes" (== unsicheres) Verhalten vorsieht.

Ja, das kann man vermeiden, mit modernen C++ Techniken. Das eine Code-Base die 10, 20 oder 30 Jahre alt ist, solche Techniken nicht kennt, ist eine andere Sache. Damals hatte man eben andere Anforderungen und Java-Software mit einer so alten Code-Base existiert ja wohl kaum.

Und wenn man sich ansieht, wo BEISPIELSWEISE Java (hier kann man eigentlich fast alle Sprachen die ich kenne einfügen) undefiniertes Verhalten vorsieht, dann ist doch klar, dass es auf Sprachebene die Möglichkeit gibt, sichere Programme zu begünstigen.

wow, ich habe keine Bufferoverflows. Meine Programme sind ja so sicher begünstigt. Wobei, wie schon mehrfach angedeutet wurde, Java ein schlechtes Beispiel ist um gegen Bufferoverflows zu wettern, da Java in den VMs ja selbst oft genug Bufferoverflows hatte.

Natürlich ist es möglich, auch in C++ ein fehlerfreies Programm zu entwickeln. Auch in einer beliebigen Assembler-Sprache und in Brainfuck ist es möglich. C++ und die anderen Alternativen (;)) haben aber ein paar Eigenarten, die das nicht gerade unterstützen und da Menschen programmieren, passieren Fehler.

Wie ich schon sagte, wenn man sich sichere Wrapper bastelt, dann hat man da auch keine Probleme.

[SideWinder]

@Optimizer: Das beispiel liefert wenn mich nicht alles täuscht einen Compilerfehler in meinem VC...

@rüdiger: Du investierst in die falsche Sprache. Deine absolut unwirtschaftlichen Ausbrüche solltest du dir für C aufheben, dort ist Linux zu Hause

MfG SideWinder

[Artchi]

Wenn dir Smartpointer auch nicht reichen, nimm Hans Boehms Garbagecollector. Dann biste mit C++ auf Java-Level.