RKI Hack / Wieso gibt es immer wieder Hacks?
In dem Fall war es ein XSS... Bei ARM wurde auch wieder ein Angriffsvektor (TikTag) gefunden, der das „unbefugte“ Überschreiben des Stacks ermöglicht... Stack Overflow passiert anscheinend auch immer mal wieder, so dass ARM dachte, sie machen spezielle Hardware Unterstützung dagegen... lol
Kann man nicht iwi Java-mäßig dem Programmierer es einfach unmöglich machen, solche groben Fehler einzubauen? Aber na klar ohne diese schlimmen Performance Einbußen, die Java mitbringt... Iwi indem alle Speicherzugriffe über Funktionen/Macros laufen? Mit Compiler-Unterstützung (also indem der Compiler bemerkt, dass man den range check auch für alle Zugriffe machen kann, schon bevor die Schleife beginnt... wenn z. B. die Abbruchbedingung schon bei Eintritt in die Schleife feststeht...)?
Ich mein: Warum geht nur entweder langsam oder unsicher?
et tu Windoze resp. Crowdstrike... lol
2 Antworten
Aber na klar ohne diese schlimmen Performance Einbußen, die Java mitbringt...
"Schlimm"? Eigentlich sind die Performance-Einbußen sehr gering, wenn es um Sicherheit geht. Was die JVM in manchen Situationen langsam (und undeterministisch) macht, ist die Garbage Collection. Und dafür gibt es nun mal kein Wundermittel. Besonders im Embedded-Bereich, wo es auf jedes Byte und jede Mikrosekunde ankommt, sind GC-Sprachen ein Problem.
Die gepriesene Alternative ist eben ein Ansatz wie bei Rust, wo man versucht, alles zur Compilezeit zu erschlagen. Der Preis dafür ist eine komplexe Sprache, die einfache Dinge mitunter ausgesprochen mühsam macht.
Das gute alte Ada und modernes(!) C++ können einen Großteil dieser Probleme auch sehr gut vermeiden, wenn auch nicht 100% ausschließen, und erlauben trotzdem recht bequemes Entwickeln. Diese Sprachen gelten aber nicht als "sexy". Leider rennt die Branche ständig dem nächsten glitzernden Ding hinterher.
wenn man z. B. konsequent Iterator-s verwendet
"Konsequent verwenden" ist halt eine Konvention und wird nicht von der Sprache erzwungen. In einer Software mit ein paar 10k oder gar 100k LOC wird das schwierig zu überwachen, aber manche Sauereien können auch in winzigen Programmen übersehen werden.
Auch in topmodernem C++ 23 kann ich immer noch oldschool C schreiben und munter in beliebige Adressen reinschreiben (oder das zumindest versuchen). Dann kann ich nur hoffen, dass mir ein statischer Codechecker solche Sauereien erkennt.
In Ada ist die Sprache selbst strenger, d.h. da ich kann das zwar alles tun, aber nur über strikt definierte Sprachmittel die auch ausschließbar sind.
Außerdem sind in C++ immer noch viele Situationen schlicht undefiniert. Du machst etwas falsch und das Resultat ist durch die Sprache nicht definiert, d.h. es kann alles mögliche passieren und wir können nur aufs Betriebssystem und/oder die MMU hoffen (sofern vorhanden).
Das ist eigentlich der wesentliche Faktor hier.
Theoretisch ist jedes Problem in der IT-Sicherheit gelöst.
Das Problem ist nicht, dass uns irgendwelches Wissen fehlt.
In der Realität bekommen wir es trotzdem nicht hin.
Hier die Erklärung:
was kann denn bei C++ noch schiefgehen, wenn man z. B. konsequent Iterator-s verwendet?