Sicherheitsforscher: Immer noch Schwachstellen durch 64-Bit-Portierung
Forscher vom Institut für Systemsicherheit der TU Braunschweig haben untersucht, welche Schwachstellen durch die Umstellung von einem 32-bittigen auf ein 64-bittiges Speichermodell entstehen können – und so einige gefunden.
Mehr als zehn Jahre ist es jetzt her, dass 64-Bit-Prozessoren den Massenmarkt erobert haben; selbst in Smartphones sind sie angekommen. Doch immer noch lauern in altem C/C++-Code Gefahren durch die Umstellung von 32 auf 64 Bit: Code, der mit 32 Bit kompiliert korrekt ist, kann mit 64 Bit übersetzt plötzlich Sicherheitslücken enthalten.
Das liegt vor allem am laxen Umgang der Programmierer mit signed vs. unsigned oder int vs. size_t. In ihrem jüngst veröffentlichen Paper Twice the Bits, Twice the Trouble: Vulnerabilities Induced by Migrating to 64-Bit Platforms haben Christian Wressnegger, Fabian Yamaguchi, Alwin Maier und Konrad Rieck vom Institut für Systemsicherheit der TU Braunschweig diese Probleme systematisch unter die Lupe genommen.
Sie zeigen zunächst verschiedene Typen von Sicherheitslücken auf, die durch die Umstellung von 32 auf 64 Bit entstehen können. Anschließend untersuchten sie große Mengen Code auf diese Typen von Fehlern: 200 Open-Source-Projekte von GitHub sowie alle Pakete aus Debian stable (“Jessie”), die als Required, Important oder Standard gekennzeichnet sind.
Indem sie Compiler-Warnungen für implizite Typumwandlungen, signed/unsigned-Umwandlungen etc. einschalteten, bekamen sie einen groben Überblick über mögliche Probleme: Im Mittel einige Hundert zusätzliche Warnungen produziert der Code, wenn man ihn 64-bittig kompiliert. Darüber hinaus untersuchten sie die Codebasis auf eine Reihe spezifischer Muster mit Fehlerpotenzial, beispielsweise einen Aufruf von atol(), der das Ergebnis einer Variablen vom Typ int statt long zuweist. Allein für dieses Beispiel fanden sie, dass im Debian-Code 21 Prozent aller atol()-Aufrufe fehlerhaft waren (für weitere Details siehe die Tabellen in der Veröffentlichung).
Natürlich ist nicht jedes dieser gefundenen potenziellen Probleme tatsächlich eine Sicherheitslücke, aber die Zahlen zeigen doch, dass aktueller, gut getesteter und als stabil angesehener C-Code heute noch jede Menge Altlasten mit sich herumschleppt.
Und dass das alles keine bloße Theorie ist, untermauern die Autoren mit dem Hinweis, dass sie im Zuge ihrer Forschungen sechs konkrete, zuvor unbekannte Sicherheitslücken in durchaus prominenter Software entdeckt haben: im Linux-Kernel, Chromium, der C++-Bibliothek Boost und den Komprimierungs-Libraries libarchive und zlib – alle entstanden durch die Migration von 32 auf 64 Bit. (bo)
