Die leise Revolution bei eingebetteten Systemen ist gerade laut geworden. Laut einem überwältigenden neuen Bericht von RunSafe Security aus dem Jahr 2025 verwenden 80,5 % der Embedded-Ingenieure jetzt KI-Tools zum Schreiben von Code, und erstaunliche 83,5 % haben diesen KI-generierten Code direkt in Produktionsumgebungen bereitgestellt.
In jeder anderen Branche wäre dies ein Produktivitätssieg. Aber in der Welt der eingebetteten Systeme (wo der Code Insulinpumpen, Industriearmaturen und Automobilbremssysteme steuert) stellt dies eine erschreckende Entkopplung von Geschwindigkeit und Gültigkeit dar.
Der Bericht mit dem Titel „AI in Embedded Systems: AI Is Here. Security Isn’t“* zeichnet das Bild einer Branche an einem gefährlichen Wendepunkt. Ingenieure schreiben Code schneller als je zuvor, verwenden Sprachen, die nie auf Sicherheit ausgelegt waren, und implementieren ihn auf Hardware, die nicht einfach gepatcht werden kann.
Der technische Deep Dive: Warum „guter“ Code kaputt geht
Die Codequalität ist nicht das Hauptanliegen. LLMs generieren eine gültige Syntax.
Das Problem besteht darin, dass C und C++ von Natur aus unsichere Sprachen sind, die eine vollkommene Wachsamkeit der Entwickler erfordern – etwas, das KI-Modelle, die probabilistische Token-Prädiktoren sind, strukturell nicht garantieren können.
Die Speichersicherheitslücke
In einer modernen High-Level-Anwendung (geschrieben in Python, Rust oder Go) übernimmt der Language Runner die Speicherzuweisung. Sie erstellen ein Objekt; Das System findet Platz. Sie hören auf, es zu benutzen; Der Garbage Collector gibt es frei.
In eingebettetem C/C++ sind Sie der Garbage Collector. Sie weisen Speicher manuell zu (malloc) und geben ihn manuell frei (free). Wenn Sie einen Fehler machen, bekommen Sie nicht nur einen Fehler; Sie schaffen eine Schwachstelle.
Der RunSafe-Bericht hebt hervor, dass dieser Ansatz der „manuellen Übertragung“ mit der KI-Geschwindigkeit kollidiert. Wenn eine KI einen 50-Zeilen-Parser für einen JSON-Stream generiert, verwendet sie häufig effiziente Standard-C-Muster. Der Kontext des Speicherlayouts wird jedoch selten berücksichtigt.
- Pufferüberläufe: Die KI schreibt Daten in einen Puffer, ohne gründlich zu prüfen, ob die Daten passen. In einer Desktop-App führt dies zum Absturz des Programms. In einem eingebetteten Controller ohne MMU (Memory Management Unit) überschreibt dies den Befehlszeiger und gibt einem Angreifer die Kontrolle über das Gerät.
- Use-After-Free (UAF): Die KI gibt einen Zeiger korrekt frei, hinterlässt jedoch an anderer Stelle im Code einen freien Verweis darauf. Später versucht die Logik, auf den freigegebenen Speicher zuzugreifen. Wenn ein Angreifer den Heap mit bösartigen Daten überschüttet hat, ist er nun für die Ausführung verantwortlich.
Der Angriffsflächenmultiplikator
Die Statistiken aus dem Bericht sind aufgrund der Oberfläche alarmierend. 53 % der Befragten nannten Sicherheit als ihre größte Sorge, doch 91 % erhöhen ihre Investitionen in eingebettete Sicherheit. Sie wissen, dass die Welle kommt.
Die traditionelle Entwicklung wirkt als natürliche Drosselung des Codevolumens. Ein menschlicher Ingenieur kann pro Tag nur eine begrenzte Anzahl Zeilen C++ schreiben, und gute Teams überprüfen diesen Code. KI entfernt den Gashebel. Die Branche überschwemmt nun veraltete Codebasen mit riesigen Mengen neuer, nicht verifizierter Logik.
Wenn eine von 10.000 Zeilen menschlichen Codes einen kritischen Speicherfehler aufweist und KI es Ingenieuren ermöglicht, 100.000 Zeilen in der Zeit zu schreiben, die zum Schreiben von 10.000 Zeilen benötigt wurde, hat die Branche nicht nur die Produktivität gesteigert; Es hat die Dichte latenter Schwachstellen um eine Größenordnung erhöht.
Kontextgeschichte: Das Muster der Nachlässigkeit
Die Branche hat diesen Film schon einmal gesehen, nur auf anderen Bildschirmen.
In den frühen 2000er Jahren führte die „Connect Everything“-Phase des IoT-Booms zum Mirai-Botnetz. Hersteller beeilten sich, IP-Stacks auf Kameras und DVRs zu installieren, ohne an Standardkennwörter oder offene Telnet-Ports zu denken. Das Ergebnis war eine riesige DDoS-Infrastruktur aus kompromittierten Toastern und Webcams.
In den 2010er Jahren beeilte sich die Automobilindustrie, Autos mit Infotainment und Konnektivität auszustatten. Das Ergebnis war der Jeep Cherokee-Hack, bei dem Forscher aus der Ferne das Getriebe eines Fahrzeugs auf einer Autobahn abschalteten, weil das Unterhaltungssystem mit dem CAN-Bus kommunizieren konnte.
Jetzt, im Jahr 2025, passiert es erneut mit der Codegenerierung. Der RunSafe-Bericht stellt fest, dass 73 % der Ingenieure das Risiko von KI-Code als „moderat oder höher“ einstufen, die Bereitstellungszahlen (83,5 %) zeigen jedoch, dass sie trotzdem weitermachen.
Der wirtschaftliche Druck, „intelligente“ Funktionen (vorausschauende Wartung, Edge-KI-Verarbeitung, Sprachschnittstellen) bereitzustellen, übersteigt die technische Disziplin, die zu ihrer Sicherung erforderlich ist.
Die Gegenmaßnahme: Load-Time Function Randomization (LFR)
Wenn Vertrauen in den Code unmöglich ist (weil es zu viel davon gibt) und es unmöglich ist, 30 Jahre C++ über Nacht in Rust umzuschreiben, was ist dann die Verteidigung?
Der Bericht weist auf Laufzeitresilienz hin. Wenn Sie davon ausgehen, dass der Fehler vorliegt, müssen Sie ihn unausnutzbar machen.
Eine der effektivsten Techniken hierfür im eingebetteten Bereich ist Load-Time Function Randomization (LFR).
Wie es funktioniert
In einer Standard-Firmware-Kompilierung befindet sich jede Funktion an einer statischen, bekannten Adresse. calculate_voltage() könnte immer bei 0x08001234 sein.
Angreifer lieben das. Um einen Exploit zu erstellen (wie Return-Oriented Programming oder ROP), müssen sie genau wissen, wohin sie springen müssen, um den gewünschten Code auszuführen. Sie verketten kleine Schnipsel vorhandenen Codes (Gadgets), um ein Schadprogramm zu erstellen.
LFR durchbricht diese Kette.
- Kompilierungszeit: Der Compiler gibt Code aus, der nicht zu absoluten Adressen springt. Stattdessen wird zu einem „Stub“ oder einer Nachschlagetabelle gesprungen.
- Ladezeit: Wenn das Gerät startet, mischt der Secure Loader das Deck. Es weist allen Funktionen nach dem Zufallsprinzip tatsächliche Speicheradressen zu.
- Patching: Der Loader aktualisiert die Nachschlagetabelle oder patcht die Binärdatei im Speicher, damit die Aufrufe weiterhin funktionieren.
Das Ergebnis? Bei jedem Neustart des Geräts (oder bei jeder Aktualisierung der Firmware, abhängig von der Implementierung) ändert sich die Speicherzuordnung. Ein Exploit, der auf Gerät A funktioniert, führt zum Absturz von Gerät B. Ein Exploit, der gestern funktioniert hat, funktioniert nach einem Neustart nicht mehr.
Die proprietäre Implementierung dieser Technologie durch RunSafe gewinnt an Bedeutung, da sie kein Umschreiben des Quellcodes erfordert. Sie wenden es auf der binären Ebene an. Dies ist von entscheidender Bedeutung für 60 % der Befragten, die bereits versuchen, Laufzeitschutz zu verwenden.
Vorausschauende Analyse: Der 5-Jahres-Ausblick
Der Bericht 2025 ist eine Momentaufnahme einer Übergangszeit. Der Sektor befindet sich derzeit in der „Wild-West“-Phase der KI-Codegenerierung.
In den nächsten fünf Jahren werden drei große Veränderungen erwartet:
- Der Aufstieg der siliziumbasierten Sicherheit: Software-Abhilfemaßnahmen wie LFR werden faktisch obligatorisch. Vorschriften (ähnlich dem Cyber Resilience Act der EU) werden wahrscheinlich verlangen, dass kritische Infrastrukturgeräte über binäre Randomisierungsfunktionen verfügen.
- Der Rust-Übergang: Während KI problemlos C++ schreibt, schreibt sie auch Rust problemlos. Der Aufwand für den Wechsel zu speichersicheren Sprachen wird geringer, da die KI die Grundbausteine übernimmt. Dies schützt jedoch nur neuen Code. Die Milliarden Zeilen des alten C/C++ bleiben bestehen.
- Verschiebung der Haftung: Da KI-generierter Code zu physischen Ausfällen führt (z. B. zu schnelles Schwingen eines Roboterarms, Ausfall eines Batteriemanagementsystems), verlagert sich die juristische Diskussion von „Softwarefehlern“ auf „Produkthaftung“. Wenn ein Hersteller KI verwendet, um sicherheitskritischen Code ohne menschliche Überprüfung oder Laufzeitschutz zu generieren, ist das Fahrlässigkeit.
Das Fazit
Der RunSafe Security 2025-Bericht ist nicht nur eine Sammlung von Umfragen; Es ist ein Warnsignal. Die Branche hat die Flasche der KI-Produktivität entkorkt, und es gibt kein Zurück mehr.
Die schiere Menge an Code, der produziert wird, bedeutet, dass eine manuelle Überprüfung im großen Maßstab mathematisch unmöglich ist. Es ist nicht mehr möglich, so zu tun, als könne jeder Fehler erkannt werden. Der einzig gangbare Weg nach vorn besteht darin, davon auszugehen, dass der Code kaputt ist, und Systeme zu entwickeln, die es nicht zulassen, dass er die Maschine kaputt macht.
Für den Embedded-Ingenieur im Jahr 2025 besteht die Aufgabe nicht mehr nur darin, C zu schreiben. Vielmehr geht es darum, die Eindämmungsfelder zu entwerfen, die verhindern, dass C irgendjemandem schadet.
Mathematischer Anhang: Die Wahrscheinlichkeit eines Exploits
Um den Wert von LFR zu modellieren, muss die Wahrscheinlichkeit P eines erfolgreichen ROP-Chain-Exploits berechnet werden. Eine Standardkette erfordert k Gadgets. In einer statischen Speicherkarte beträgt die Wahrscheinlichkeit, das Gadget i an einem bekannten Ort zu finden, 1.
Die Wahrscheinlichkeit eines statischen Exploits liegt effektiv bei 100 %.
Wenn es bei LFR N mögliche Standorte (Slots) für eine Funktion gibt und der Angreifer eine Chance von 1 zu N hat, den korrekten Offset für jedes unabhängige Gerät zu erraten (vereinfachtes Modell), sinkt die Wahrscheinlichkeit ungefähr auf 1 geteilt durch N hoch k.
Die Wahrscheinlichkeit ist effektiv Null.
Selbst bei einer bescheidenen Entropie (N=256) und einer kurzen Kette (k=3) steigt der Schwierigkeitsgrad von sicher auf eins zu 16 Millionen.
Quellen (6)
- runsafesecurity.com RunSafe Security Blog
- themanufacturingconnection.com The Manufacturing Connection
- vmblog.com VMblog 2025 Predictions
- runsafesecurity.com Medical Device Cybersecurity Index 2025
- news.mit.edu MIT News: Memory Safety Tipping Point
- appsecengineer.com Defending Memory Corruption
🦋 Diskussion auf Bluesky
Auf Bluesky diskutieren