C, C++ und Java nicht mehr verwenden

Mal was Technisches.

Ein Leser macht mich auf einen Artikel in den aktuellen VDI-Nachrichten aufmerksam und schickt mir einen Scan.

Problem daran: Es scheinen da versehentlich bei den VDI-Nachrichten zwei Nachrichten durcheinander gekommen zu sein, da steht nämlich

Ursache für erfolgreiche Cyberangriffe „ist die Verwendung von Programmiersprachen, welche syntaktisch und semantisch massive Lücken aufweisen.“

Hubert Keller fordert, die Programmiersprachen C, C++ und Java nicht mehr zu verwenden

Schwachstellen sinds eit Langem bekannt

„Wir brauchen eine Stärkung der Strafverfolgungsbehörden” – Interview mit Bitkom-Präsident Ralf Wintergerst (Nr. 16/23)

Der Leser meint, Wintergerst habe das mit den Programmiersprachen gesagt.

Für mich sieht das aber so aus, als sei das kein Interview, sondern einfach ein Artikel von einem Hubert Keller, und der Satz mit den Strafverfolgungsbehörden und Wintergerst da nur versehentlich reingeruscht, gehörte wanders hin.

Aber in der Sache:

Wir sollten nicht immer nur Symptome therapieren, sondern die Ursachen beseitigen. Der überwiegende Teil der Cyberangriffe erfolgt auf Basis von Schwachstellen in der Software. Und diese Schwachstellen sind seit Jahren bekannt und nahezu stabil die Gleichen geblieben.

Ja.
Das Thema hatte ich im Blog auch schon oft. Dass ich keinen Spaß mehr an IT-Security habe, weil die Probleme eigentlich immer noch dieselben sind wie damals, als ich vor fast 35 Jahren (so ungefähr um 1989) damit angefangen habe. Könnt Ihr Euch googeln: „With Microscope and Tweezers“. Uralt, aber im Prinzip immer noch so, es sind immer nur neue Löcher dazugekommen.

Ursache dafür ist die Verwendung von Programmiersprachen, welche syntaktisch und semantisch massive Lücken aufweisen.

Jain.

Ich stimme zu, dass das eine Ursache ist, eine wesentliche sogar, aber nicht die einzige Ursache, nicht die Ursache schlechthin. Das Problem hat auch damit zu tun, dass zuviel Software gemurkst wird, dass zuviel Leute unterwegs sind, die nicht ordentlich programmieren können oder in großer Eile durchhetzen.

Die Top-25-Software-Vulnerabilities sind nahezu ausschließlich auf C, C++ und Java zurückzufuhren. Dass C/C++ immer noch keine Indexprüfung bei Vektoren in der Sprache verankert hat, ist ein Unding und sorgt dafür, dass beliebig falsche Speicherlängen auf dem TCP/IP Stack ausgelesen und beliebige Daten gelesen oder überschrieben werden können.

Da merkt man etwas, dass der selbst nicht die volle Ahnung hat, das Problem existiert nämlich nicht nur beim TCP/IP-Stack, sondern praktisch überall. Der hat da wohl nur einen Beispielfall betrachtet und verstanden.

C ist von seiner Konstruktion und Genese her eine sehr niedrige Sprache. Viele spotteten (und nicht zu unrecht), dass es eine Art prozessorunabhängiger Assembler ist oder war. Das ist sachlich richtig, unterschlägt aber etwas, dass C eben auf Maschinen mit sehr wenig Leistung und Speicher entwickelt wurde und deshalb wirklich einfach strukturiert war und sein musste. Ändert aber nichts daran, dass es so ist oder war.

Mein Problem ist gerade:

Ich habe früher, so bis in die Mitte der 2000er Jahre, sehr viel und knallhart in C und C++ programmiert und kann das sehr genau, auch die Compiler-Macken. Und habe nicht selten den Leuten Sachen erklärt, für die man mich zur Gottheit erklärte.

Seither habe ich aber nicht mehr viel gemacht, vor allem, mich da nicht sehr weitergebildet und deshalb auch die Sprachänderungen nicht nachverfolgt. Ich weiß, dass es in modernen C++-Standards Dinge gibt, die ich noch nicht verstanden habe, obwohl ich sie verstehen wollte. Ich habe aber einfach keine gute Sprachdokumentation mehr gefunden, kein Buch, in dem das noch gesammelt drin steht. Es gibt da inzwischen eine Vielzahl von Versionen und neuen Funktionen und Definitionen, durch die es wohl sehr schwer ist, noch durchzublicken. Was ich seinerseits wieder als Sicherheitsproblem betrachte, denn wie soll man Software in einer Sprache auditieren können, deren Sprachsemantik man nicht mehr kontrolliert nachlesen kann?

Und wie will man überhaupt persistente Software schreiben, wenn die alle paar Jahre oder jedes Jahr die Definition ändern und erweitern?

Anfangs fand ich C++ sehr toll, aber je mehr da reingebaut wurde, desto sperriger wurde die Sprache.

Ja, jemand der programmieren kann sollte keine Pufferüberlauf-Fehler machen. Man kann auch in C und C++ durchaus ziemlich sicher programmieren, wenn man eben programmieren kann und die Probleme versteht. Man kann sich einen Stil aneignen, der solche Fehler praktisch immer vermeidet.

Das können aber viele der heutigen „Programmierer“ und „Coder“ nicht mehr. Programmiersprachen müssen heute idiotensicher sein, und das sind C und C++ einfach nicht.

Und viele Dinge sind einfach schwierig. Ein großes Problem sind auch die Null-terminierten Strings, deren Länge man nicht ohne weiteres kennt, und die vielen Funktionen, denen man keine Länge mitgeben kann, die längst wegmüssten, aber aus Rückwärtskompatibilität noch drin sind. Oder Unions.

Ich weiß, dass mir Leser schon schrieben, dass man Index-Prüfungen inzwischen eingebaut hätte. Ich wüsste jetzt aber nicht, wo es steht.

Java hat diese Index-Prüfung, aber ganz andere Probleme.

Vor allem darin, dass Java ein unendlicher, unüberschaubarer Zeitgeistsumpf aus vielen Softwarestückchen von Autoren der ganzen Welt, durch die keiner mehr durchblickt. Der Mist von neulich, in dem das Ding log-Einträge auswertete und dann Software von beliebigen externen LDAP-Servern runterlud, war der totale fuckup. Sowas darf überhaupt nicht passieren. Es ist aber passiert, weil irgendwo viele Idioten schlechte Software geschrieben haben, ohne sich abzusprechen, und keiner die Software des anderen verstand, und man sie dann alle zusammengerührt hat. Da ist der Stil, das Biotop das Problem.

Die Ursachen werden beseitigt, indem eine Programmiersprache wie Spark, Rust oder Ada eingesetzt wird, die 75 % aller Vulnerabilities ausschließen. Der Rest sind dann falsche Rechtevergabe, fixe Passwörter oder falsche Algorithmen und natürlich die Organisation.

Ganz so einfach ist es nicht, man kann nicht einfach so eine andere Sprache verwenden.

Und Rust ist zwar eine tolle Sprache mit beeindruckenden Eigenschaften, aber noch nicht die Lösung aller Probleme. Rust hat einfach keine ordentliche Objektorientierung, versucht das nur nachzuahmen, und kann viele Probleme auch nicht oder nicht sauber lösen. Aber grundsätzlich ist Rust der richtige Weg. Ich würde einem in Rust geschriebenen Programm sehr viel mehr vertrauen als einem in C/C++.

Ada habe ich noch nicht programmiert. Ich habe mir das vor ungefähr 25 oder 30 Jahren mal durchgelesen, gedacht „Mmmh“ und es wieder weggelegt. Und ob eine Sprache aus den 1970er für heute geeignet sein kann … ich weiß, dass es einen Ada 2012 Standard gibt. Aber wenn ich mir die Webseiten dazu und das Reference Manual sehe, bekomme ich Augenkrämpfe und frage mich, ob jemand, der so eine Dokumentation abliefert, in der Lage sein kann, eine Programmiersprache zu machen.

Und dann wären wir auch schon beim eigentlichen Problem.

Mit C ist es wie mit Deutschland: Am Ende und im Eimer, nischt wie weg, aber wohin?

Es gibt eine riesige, unüberschaubare Menge von Sprachen (immer, wenn ich das Thema anspreche, melden sich welche und halten Turbopascal für die beste aller Sprachen und verwenden es immer noch). Dazu das Dilemma, dass man eine halbwegs frische Sprache braucht, die aber über mindestens 30 Jahre zu gebrauchen ist, und in der man alle Software dieser Welt bekommt. Und die Software dieser Welt kriegt man hauptsächlich in C, C++ und Java.

Und dann gibt es die alte Informatikerweisheit, dass es viel zu viele Sprachen gibt, jede Murks, aber immer dann, wenn einer kommt, und meint, er hat jetzt die ultimative Sprache, die alle ersetzt, danach dann einfach n+1 Sprachen da sind, und das Problem nur größer wurde.

Im Prinzip hat der Autor recht.

Aber eben nur im Prinzip.

In der Realität ist es eben nicht so einfach, dass man ab morgen einfach mal eine andere Sprache verwendet. Der Autor hat anscheinend nicht verstanden, was für eine Rattenschwanz da hinten dran hängt.

Ich will den Status Quo dabei keinesfalls verteidigen oder beschönigen, schützen oder erhalten. Aber es ist halt naiv zu glauben, dass man einfach mal so eine andere Sprache einsetzen könnte, weil einem gerade danach ist. Wenn ich mich recht erinnere, hat Rust eine Schnittstelle zu C-Programmen. Aber so richtig elegant ist das auch nicht.

Die Quintessenz ist:

Wir haben nach 40 Jahren ein paar der Probleme verstanden.

Aber keine Lösung.