https://blog.fefe.de/?ts=9a65c751
Wenn der Compiler versteht, dass OPENSSL_cleanse keine Seiteneffekte hat außer key zu überschreiben, dann ist das ein klarer Fall für die Dead Store Elimination. Ähnlich sieht es mit einem memset() vor einem free() aus. Das ist vor ein paar Jahren aufgefallen, dass Compiler das nicht nur tun können sondern sogar in der Praxis wirklich tun. Plötzlich lagen im Speicher von Programmen Keymaterial herum. Also musste eine Strategie her, wie man den Compiler dazu bringt, das memset nicht wegzuoptimieren.
Sehr spannende Analyse von Fefe, wie Optimierungen des Compilers die Sicherheit von Software untergraben können. Da gibt man sich als Programmierer alle Mühe, sensible Daten aufzuräumen, und dann schmeißt der Compiler den Code wieder raus, weil er ihn für unnötig hält. Und Abhilfe ist gar nicht so einfach.
Kein Wunder, dass immer neue Lücken gefunden werden in Betriebssystemen und Software. Die Komplexität der SW-Entwicklungs-Prozesse hat ein derartiges Ausmaß angenommen, dass sie nur noch mit sehr hohem Testaufwand beherrschbar sind. Fefes Artikel beleuchtet dabei den interessanten Aspekt, dass sogar eine neue Compiler-Version Sicherheitslücken in Code reißen könnte, der ursprünglich sicher geschrieben war. Wer würde bei Recompilation mit einer neuen Compiler-Version den erzeugten Assembler-Code neu überprüfen? Es benötigt also umfangreiche und ständige Kontrollen des Outputs, um die Stabilität der Ergebnisse des Codes auch bei der Weiterentwicklung zu gewährleisten.