Geschwindigkeit vs. Sicherheit

Gregor

rüdiger schrieb:

Man kann doch auch leicht ein Programm mit Java schreiben, das abstürzt oder undefiniertes Verhalten erzeugt.

In Java ist viel weniger undefiniert als in C++. Beim Threading kann es zum Beispiel auf unterschiedlichen Plattformen zu unterschiedlichem Verhalten kommen. Viel mehr fällt mir da aber nicht ein. Ich weiß nicht, auf was Du da hinaus willst.

volkard

ihr tut gerade so, als sei ein auto, das neben den vorwärtsgängen auch einen rückwärtsgang hat, abzulehnen, weil die meisten einparkunfälle rückwärts passieren.
warum sollte man in c++ mist programmieren? gute c++-programme sind allemal sicherer als gute java-programme. nur weil man 15 bis 20 jahre braucht, um mit c++ praktisch fehlerfrei zu programmieren, ist das doch kein grund, gleich zu weinen und baby-sprachen zu benutzen.

rüdiger

Gregor schrieb:

1. Die Frage, ob jemand während des Betriebs eines Programms von außen Code einschleusen kann, der dann ausgeführt wird. Damit meine ich zum Beispiel solche Sicherheitslücken in Browsern, von denen man häufiger mal hört. ...das war zum Beispiel mal durch manipulierte JPGs im IE möglich. In Java ist soetwas viel problematischer: AFAIK sind dafür meistens irgendwelche Buffer-Underruns oder so verantwortlich, die es so in Java nicht gibt. Die JVM macht halt immer Checks bezüglich Indizes usw..

Das ist wirklich ein Problem, das Fehlerhafte Programmierung in C++ Probleme mit den Indizes verursachen kann. Das hat Java nicht, da muss ich dir Recht geben (okay, die VMs haben das Problem natürlich intern schon).

Aber warum sollte da ausgerechnet Java helfen? Ob gäbe es keine anderen Programmier-Umgebungen, die solche Überprüfungen haben. Hey, so etwas hatte man schon in den 1950er Jahren.

Gregor schrieb:

2. Die Frage, ob ein Programm dem Rechner, auf dem es ausgeführt wird, irgendwie Schaden zufügt. In Java kann man das Programm innerhalb einer Sandbox laufen lassen. Dadurch verbietet man praktisch alle möglichen Dinge, die Schaden könnten. IO usw.. Bei Applets wird das ja gemacht, aber ich wüsste nicht, was dagegen spricht, das generell bei Programmen zu machen, denen man nicht vertraut. AFAIK gibt es da JVM-Parameter, mit denen man so eine Sandbox auch für normale Programme anschalten kann.

Eine Sandbox kann man ja auch auf Betriebssystem-Ebene regeln. Im Zweifelsfall nimmt man eben eine virtualisierungs Lösung.

Gregor schrieb:

rüdiger schrieb:

Man kann doch auch leicht ein Programm mit Java schreiben, das abstürzt oder undefiniertes Verhalten erzeugt.

In Java ist viel weniger undefiniert als in C++. Beim Threading kann es zum Beispiel auf unterschiedlichen Plattformen zu unterschiedlichem Verhalten kommen. Viel mehr fällt mir da aber nicht ein. Ich weiß nicht, auf was Du da hinaus willst.

Ich will darauf hinaus, das ein Programm nicht sicher ist, weil man Java benutzt. Ich kann mich nur daran erinnern, das man wohl eine Unterscheidung zwischen System- bzw VM-Fehlern und Exceptions.

Aber selbst wenn, das ist ja wirklich nicht alles was man bei einer Anwendung falsch oder unsicher machen kann. Man kann ja zB durch schlechte Programme undefiniertes Verhalten von zB einer Datenbank oder ähnliches erreichen. Das hat mit C++ ja nichts zu tun.

groovemaster

volkard schrieb:

warum sollte man in c++ mist programmieren? gute c++-programme sind allemal sicherer als gute java-programme. nur weil man 15 bis 20 jahre braucht, um mit c++ praktisch fehlerfrei zu programmieren, ist das doch kein grund, gleich zu weinen und baby-sprachen zu benutzen.

Tja, so sind 'se halt die Javaisten. Geich anfangen zu heulen, wenn irgendein C++ Newbie mit einem rohen Array einen Bufferoverrun erzeugt, weil er das auch so in einem schlechten Buch gesehen hat. Aber sich mal darüber zu informieren, welche Sicherheitskonzepte es gibt, und dass man auch in C++ absolut sicher programmieren kann, können sie nicht. Schämt euch!

Gregor

groovemaster schrieb:

Tja, so sind 'se halt die Javaisten. Geich anfangen zu heulen, wenn irgendein C++ Newbie mit einem rohen Array einen Bufferoverrun erzeugt, weil er das auch so in einem schlechten Buch gesehen hat. Aber sich mal darüber zu informieren, welche Sicherheitskonzepte es gibt, und dass man auch in C++ absolut sicher programmieren kann, können sie nicht. Schämt euch!

Ok, beruhig Dich mal und komm mal wieder zurück in die Realität. Die Probleme, die durch Bufferunderruns auftreten existieren in Anwendungen, die von vielen Leuten genutzt werden und hinter denen massives Entwickler-Know-How steckt. Ich habe noch nie eine Meldung darüber gelesen, dass ein Anfänger in einem Hello-World-Programm eine Sicherheitslücke produziert hat. Das würde ja auch keinen interessieren. Sicherheitsprobleme sind nur dann von Relevanz, wenn das entsprechende Programm eine gewisse Bedeutung hat. Und offensichtlich werden solche Programme nicht von den Leuten geschrieben, die volkard da beschrieben hat. Insofern halte ich 15-20 Jahre Erfahrung in einer Programmiersprache für realitätsfern. ...oder die Vorstellung, dass diese Leute dann nicht mehr die entsprechenden Probleme verursachen.

...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.

Gregor

rüdiger schrieb:

Aber warum sollte da ausgerechnet Java helfen? Ob gäbe es keine anderen Programmier-Umgebungen, die solche Überprüfungen haben. Hey, so etwas hatte man schon in den 1950er Jahren.

Ja, i.d.T.. Es gibt auch andere Möglichkeiten, solche Probleme zu vermeiden. Die Nutzung von Java ist nur eine dieser Möglichkeiten.

rüdiger

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.

Ne, sie sind auf den unfähigen C++-Programmierer zurück zu führen. Das ist der Unterschied zu Java, wie du es ja bereits erklärt hast.

Gregor schrieb:

rüdiger schrieb:

Aber warum sollte da ausgerechnet Java helfen? Ob gäbe es keine anderen Programmier-Umgebungen, die solche Überprüfungen haben. Hey, so etwas hatte man schon in den 1950er Jahren.

Ja, i.d.T.. Es gibt auch andere Möglichkeiten, solche Probleme zu vermeiden. Die Nutzung von Java ist nur eine dieser Möglichkeiten.

Da muss man nun die weiteren Nachteile von Java abwiegen, aber dafür ist dieser Thread nicht gedacht. Daher lassen wir das mal so stehen.

Zum Beispiel wäre eine Möglichkeit Index-Prüfungen in C++ zu benutzen.

finix

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.

Haha.

Jester

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

Bitte nicht zu ernst nehmen.

net 0

groovemaster schrieb:

...und dass man auch in C++ absolut sicher programmieren kann...

kann man. dank virtual-pc, vmware o.ä.

Artchi

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? Dafür brauche ich nicht unbedingt eine JavaVM. Mittlerweile bieten selbst AMDs und Intels CPUs Virtualisierungs-Support. Ist das nicht besser als eine JavaVM?

Bufferoverrun: Man kann im MSVC7.1 und neuer auch Bufferoverrun-Checks per /GS-Option einschalten. D.h. das Kompilat bekommt nachträglich einen Check verpasst, mit minimalem Laufzeitnachteilen. Laut MS ist dieser Check keine Garantie gegen böswilligen Code , aber immerhin gibts Bemühungen!

MSDN schrieb:

Die /GS-Option wird zum Erkennen von Pufferüberläufen verwendet, die die Rückgabeadresse überschreiben. Diese Technik wird allgemein bei Code angewendet, der keine Beschränkungen der Puffergröße erzwingt. Pufferüberläufe werden dabei durch Sicherheitsprüfungen erkannt, die in den kompilierten Code eingefügt werden.

Durch /GS wird nur versucht, direkte Pufferüberläufe in die Rückgabeadresse zu ermitteln.

/* In diesem Beispiel findet ein Pufferüberlauf statt. Beim Erstellen mit /GS
wird ein Meldungsfenster angezeigt, und der Prozess wird beendet. */

#include <cstring>

// Vulnerable function
void vulnerable(const char *str)
{
   char buffer[10];
   strcpy(buffer, str); // overrun buffer !!!
}

int main()
{
   // declare buffer that is bigger than expected
   char large_buffer[] = "This string is longer than 10 characters!!!";
   vulnerable(large_buffer);
}

Achja, und bzgl. "Mal selber das Gehirn einschalten!":

MSDN schrieb:

Sie sollten auch bei Verwendung von /GS immer darauf achten, sicheren Code zu schreiben. Stellen Sie also sicher, dass der Code erst gar keine Pufferüberläufe verursacht. /GS schützt Anwendungen möglicherweise vor Pufferüberläufen, die sich auf den eigenen Code beschränken.

Ich bin mir sicher, das in Zukunft bei C und C++ noch mehr passieren wird. Z.B. hatte Bjarne Stroustrup für C++0x vorgeschlagen von std::vector nicht nur die at-Methode einer Index-Überprüfung zu unterziehen sondern auch den []-Operator. Weil anscheinend die wenigsten at() verwenden? Also obwohl vector Laufzeitchecks anbietet, nutzen es die wenigsten.

groovemaster

Gregor schrieb:

Ok, beruhig Dich mal und komm mal wieder zurück in die Realität. Die Probleme, die durch Bufferunderruns auftreten existieren in Anwendungen, die von vielen Leuten genutzt werden und hinter denen massives Entwickler-Know-How steckt.

Welche Probleme entstehen denn durch Bufferunderruns?

Gregor schrieb:

Ich habe noch nie eine Meldung darüber gelesen, dass ein Anfänger in einem Hello-World-Programm eine Sicherheitslücke produziert hat. Das würde ja auch keinen interessieren. Sicherheitsprobleme sind nur dann von Relevanz, wenn das entsprechende Programm eine gewisse Bedeutung hat.

Darum geht es ja auch gar nicht. Klar kann man mit C++ Unsinn anstellen. Dies kann aber keine Begründung dafür sein, dass C++ unsicher ist. Es geht ja auch anders. Und das unterscheidet eben gute von schlechten Programmierern.

Gregor schrieb:

Und offensichtlich werden solche Programme nicht von den Leuten geschrieben, die volkard da beschrieben hat. Insofern halte ich 15-20 Jahre Erfahrung in einer Programmiersprache für realitätsfern. ...oder die Vorstellung, dass diese Leute dann nicht mehr die entsprechenden Probleme verursachen.

Wieso nicht? Man muss ja nicht gleich alle in einen Topf werfen. Aber es gibt mit Sicherheit genügend Leute, die sich mit so vielen Jahren Erfahrung weiterentwickelt haben und mittlerweile wissen, wie man Gefahren problemlos aus dem Weg gehen kann.

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.

Hehe, du bist ja lustig. C++ hat auch keine Sicherheitslücken. Das sind einfach nur die dummen Compiler, die den Code in bösen Assembler übersetzen.

@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
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?

@volkard:
""nur weil man 15 bis 20 jahre braucht, um mit c++ praktisch fehlerfrei zu programmieren, ist das doch kein grund, gleich zu weinen und baby-sprachen zu benutzen. ""
na, dass du keinen job in der IT branche findest wundert mich überhaupt nicht.

volkard schrieb:

ihr tut gerade so, als sei ein auto, das neben den vorwärtsgängen auch einen rückwärtsgang hat, abzulehnen, weil die meisten einparkunfälle rückwärts passieren.
warum sollte man in c++ mist programmieren? gute c++-programme sind allemal sicherer als gute java-programme. nur weil man 15 bis 20 jahre braucht, um mit c++ praktisch fehlerfrei zu programmieren, ist das doch kein grund, gleich zu weinen und baby-sprachen zu benutzen.

groovemaster schrieb:

volkard schrieb:

warum sollte man in c++ mist programmieren? gute c++-programme sind allemal sicherer als gute java-programme. nur weil man 15 bis 20 jahre braucht, um mit c++ praktisch fehlerfrei zu programmieren, ist das doch kein grund, gleich zu weinen und baby-sprachen zu benutzen.

Tja, so sind 'se halt die Javaisten. Geich anfangen zu heulen, wenn irgendein C++ Newbie mit einem rohen Array einen Bufferoverrun erzeugt, weil er das auch so in einem schlechten Buch gesehen hat. Aber sich mal darüber zu informieren, welche Sicherheitskonzepte es gibt, und dass man auch in C++ absolut sicher programmieren kann, können sie nicht. Schämt euch!

Welche Probleme entstehen denn durch Bufferunderruns?

Entschuldigt mal. Keiner sagt, dass Sicherheitsprobleme ein Grund sind, zukünftig alles mit Java zu machen. Aber die Sicherheitsprobleme durch buffer overruns sind real und nicht auf vereinzelte inkompetente Programmierer zurückzuführen. 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. Bei solchen Kommentaren kommt mir echt das Kotzen. Wenn man keine Ahnung von Sicherheit hat, sollte man halt lieber mal den Rand halten, anstatt ordentlich einen aufzulabern.

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".

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. 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.

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.

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.

Artchi

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!

net 0

Artchi schrieb:

Im Output stand was von MSVC6!!! Hallo? Und das in einer JVM 1.5!

und wo ist da ein problem?

Mit VC++ 8 kompiliert wäre es doch von ganz alleine schon viel sicherer. Ist doch klar.

groovemaster schrieb:

Gregor schrieb:

Ok, beruhig Dich mal und komm mal wieder zurück in die Realität. Die Probleme, die durch Bufferunderruns auftreten existieren in Anwendungen, die von vielen Leuten genutzt werden und hinter denen massives Entwickler-Know-How steckt.

Welche Probleme entstehen denn durch Bufferunderruns?

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

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

Irgendwie muss man doch in C++ ständig irgendwelche sachen einführen, damit man nicht soviel kaputt machen kann. Arrays->std::vector, char* texte -> std::string. Und dann verwendet aber z.B. std::fstream nicht mal den std::string, sondern doch nur char*. Aber C++ wurde ja anscheinend nicht dazu gemacht irgendwas mit strings zu machen, wenn man sich dieses chaos da anschaut.

Artchi

Optimizer schrieb:

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.

Hem, und wer garantiert mir, das nicht ein beliebiges Java-Programm, welches ich mir aus dem Netz lade (egal ob über WebStart oder so zum entpacken) nicht auch mein Homeverzeichnis löscht? Das kann die JVM nämlich auch nicht verhindern, denn jedes Java-Programm (außer Applets) kann Dateioperationen ohne Nachfrage ausführen. In dem Fall auch mal locker rekursiv mein Home löschen.

Artchi schrieb:

Optimizer schrieb:

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.

Hem, und wer garantiert mir, das nicht ein beliebiges Java-Programm, welches ich mir aus dem Netz lade (egal ob über WebStart oder so zum entpacken) nicht auch mein Homeverzeichnis löscht? Das kann die JVM nämlich auch nicht verhindern, denn jedes Java-Programm (außer Applets) kann Dateioperationen ohne Nachfrage ausführen. In dem Fall auch mal locker rekursiv mein Home löschen.

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.