Automatisierte Tools und MISRA C Software-Security garantieren

Internetanbindung und Software machen die Fahrzeuge anfällig für Ausspähversuche und Angriffe.
Internetanbindung und Software machen die Fahrzeuge anfällig für Ausspähversuche und Angriffe.

Der rapide zunehmende Software-Gehalt moderner Automobile sowie ihre Anbindung an das Internet und weitere Quellen machen die Fahrzeuge anfällig für Ausspähversuche und Angriffe. Für Automobilhersteller und Autofahrer ist es deshalb gleichermaßen wichtig, dass diese Systeme abgesichert werden.

Die Software hat die Automobilindustrie erobert. In modernen Autos laufen buchstäblich Millionen von Code-Zeilen für Funktionen wie Motormanagement, Bremsen, Lenkung, Stabilisierung, Gefahrenerkennung, Klimatisierung oder Unterhaltungssysteme. All diese Subsysteme sind unterschiedlich kritisch – die Bremsen sind natürlich wichtiger als die Klimasteuerung. Doch alle Funktionen kommunizieren über interne Busse und Kanäle. In vielen Fällen verfügen die Systeme im Auto über externe Kommunikationsfähigkeiten, die einerseits für Updates und Diagnosezwecke benötigt werden, andererseits aber Angriffspunkte für ungewollte oder böswillige Attacken bieten. Hinzu kommt, dass sich die Automobilindustrie nicht nur auf dem Weg zum vernetzten, sondern letztendlich zum fahrerlosen Auto befindet. Aus all diesen Gründen sind Zuverlässigkeit und Funktionssicherheit untrennbar mit dem Security-Aspekt verbunden. Der inzwischen zu trauriger Berühmtheit gelangte Fall, dass eine durch fehlerhaften Quellcode ausgelöste Störung im E-Gas-System sogar Todesfälle verursacht hat, wird noch durch die Tatsache verschlimmert, dass Hacker und Malware mittlerweile auch Zugang zu Fahrzeugen haben, die über keinerlei wirksame Absicherung verfügen.

Funktionale Sicherheit im Auto wird durch den Standard ISO 26262 unterstützt, der den Forderungen nach Sicherheit und Zuverlässigkeit Rechnung trägt und für deren Umsetzung ein Kodierungsstandard erforderlich ist. Einer dieser für die Automobilindustrie entwickelten Standards ist MISRA. Es handelt sich dabei um eine als MISRA C bezeichnete Teilmenge der C-Sprache zur Entwicklung von Anwendungen mit hohen Integritäts- und Zuverlässigkeitsanforderungen. Die MISRA-Richtlinien sollen der funktionalen Sicherheit (Safety), der Absicherung (Security) sowie der Portierbarkeit und Zuverlässigkeit des Codes im Kontext eingebetteter Systeme dienen. Weil C die bevorzugte Programmiersprache für viele Embedded-Anwendungen ist, entstand die Forderung nach mehr und besserer Berücksichtigung der Anforderungen von Embedded Devices, wodurch der MISRA-Standard in einer Vielzahl von Branchen eingesetzt wurde. Erst kürzlich wurde MISRA C:2012 verbessert, um eine bessere Absicherung für Fahrzeuge sowie Embedded-Systeme im Allgemeinen zu erreichen. Für die Automobilindustrie kommt dieser Vorstoß für mehr Security gerade rechtzeitig.

Erweiterung der MISRA-Software-Richtlinien

Nach der Veröffentlichung von MISRA C:2012 gab das für die Pflege des C-Standards zuständige Komitee die ISO/IEC 17961:2013 Security Guidelines für die C-Sprache heraus. Als Reaktion darauf veröffentlichte das MISRA-Komitee MISRA C:2012 Amendment 1, das diese neuen Security-Anforderungen unterstützen soll. Das Amendment wertet alle bestehenden Editionen der MISRA-Richtlinien auf, ist vollständig kompatibel zu ihnen und wird zum Standardkonzept für alle künftigen Editionen der MISRA-Richtlinien.

Im Einzelnen formuliert MISRA C:2012 Amendment 1 insgesamt 14 neue Richtlinien für die sichere C-Codierung. Ziel ist es dabei, die Abdeckung der in den ISO C Secure Guidelines hervorgehobenen Sicherheitsbedenken zu berücksichtigen. Mehrere dieser Richtlinien beziehen sich auf bestimmte Probleme im Zusammenhang mit „tainted data“, was sinngemäß verfälschte Daten bedeutet, die ein bekanntes Sicherheitsproblem sind. Das Amendment enthält sowohl breiter gefasste Richtlinien als auch spezifische Regeln. Bei Einhaltung dieser Richtlinien können Entwickler ihren Code gründlicher analysieren und den Regulierungsstellen den Nachweis vorlegen, dass sie sich an die Codierungs-Konventionen für Safety und Security gehalten haben.

Zwei Beispiele der neuen Regeln:

(1) Dir. 4.14: Die Gültigkeit von Werten aus externen Quellen ist zu überprüfen.Aufgrund der wachsenden Zahl von Geräten, die untereinander oder mit dem Internet verbunden sind, ist es wichtig zu kontrollieren, welche Daten gegenüber externen Quellen exponiert sein können. Wird die Länge einer Nachricht, die von einer externen Quelle empfangen wird, nicht auf Korrektheit überprüft, könnte ein Angreifer den kompletten Speicherinhalt eines Computers aus der Ferne auslesen. Abwandlungen dieses Angriffstyps wurden tatsächlich bereits eingesetzt, um im Klartext Passwörter aus den internen Pufferspeichern von Netzwerkservern abzugreifen. Diese Regel bietet Schutz vor Sicherheitslücken des „Heartbleed“-Typs. Dabei gelang es Hackern mit Hilfe sorgfältig gestalteter Nachrichten, Daten – darunter auch Passwörter – im Klartext über das Internet zu extrahieren.
Ein Automotive-System kann bei Nichtbeachtung einer dieser Richtlinien ernsthaft kompromittiert werden. Die MISRA-Richtlinien sind so angelegt, dass sich ihre Einhaltung mithilfe statischer Code-Analyse überprüfen lässt.

(2) Regel 12.5: Der Operator sizeof darf keinen Operanden haben, bei dem es sich um einen als ‚array of type‘ deklarierten Funktionsparameter handelt.
Pufferüberläufe sind eine Möglichkeit, Schad-Code außerhalb eines Datenbereichs einzuschleusen. Die Größe des Datenbereichs wird mit dem Operator sizeof festgelegt. Wird sizeof also mit einem falschen oder ungeeigneten Typ benutzt, kann der Operator den falschen Wert des Datenbereichs zurückgeben und den Zugang zu einem Code-Bereich freigeben. Diese Regel stellt sicher, dass Code- und Datenbereiche korrekt festgelegt werden, um diese Fehler, die das Verarbeiten von Daten erlauben könnten, zu vermeiden.
Genau ein solcher Fehler war dafür verantwortlich, dass die Länge eines bestimmten Datenelements nicht verifiziert wurde und Hackern der Zugriff auf den Heartbeat des SSL-Austauschs gelang, der vor der Verschlüsselung und normalen Datenübertragung stattfindet. Die Hacker nutzten diese fehlende Verifikation, indem sie die Rückgabe eines sehr langen Datenelements aus dem Speicher veranlassten. Indem sie dies wiederholt taten, konnten sie praktisch alle Daten als Klartext aus dem Server ziehen und analysieren. So gelangten sie in den Besitz der persönlichen Daten von Millionen Kunden.

Fundament für Security

Weil es sich bei C um eine komplexe Programmiersprache handelt, besteht die Möglichkeit, dass subtile Fehler gemacht werden. Der Code ist dann zwar nach wie vor lauffähig, kann aber verborgene Schwachstellen enthalten, die für eine gewisse Zeit nicht zutage treten. Nun sind die Safety- und Security-Richtlinien, die solchen Situationen Rechnung tragen sollen, ebenfalls recht detailliert und komplex. Daher kann sich nicht darauf verlassen werden, dass ein menschlicher Programmierer, so erfahren er auch sein mag, intuitiv stets korrekten Code produziert und alle Standard-Richtlinien in Sachen Safety und Security befolgt. Hinzu kommt der immer stärker werdende Trend zu höheren ASILs, die nach Dokumentation und Nachweisen verlangen. Aus diesem Grund wird der Einsatz automatisierter Tools unabdingbar.

Die LDRA Tool Suite kann durch statische Analyse des Quellcodes die Konformität des Codes zu MISRA C, ISO 26262 und anderen Codierungsstandards erreichen. In diese Analyse lassen sich auch beliebige individuelle Regeln einbeziehen, die ein Entwickler oder sein Unternehmen spezifizieren wollen.
Darüber hinaus gibt es jedoch einen Bedarf an Tests, die auf statischer Analyse, dynamischer Code-Überdeckungs-Analyse und Modul-/Integrationstests basieren. Der Grundgedanke hinter diesem Paket aus Prüfwerkzeugen ist die Notwendigkeit, nicht nur Security, funktionale Sicherheit und die Einhaltung der erwähnten Standards zu gewährleisten, sondern auch die Fähigkeit zu bieten, Anforderungen vom Lastenheft bis zu ihrer Umsetzung im Code zu verfolgen sowie umgekehrt auch die Rückverfolgung zu den einzelnen Anforderungen zu ermöglichen (Bild 1).

Funktionstests erfordern die Prüfung auf korrekte und sichere Ausführung der im Code enthaltenen Operationen. Das geschieht durch dynamische Analyse des kompilierten Codes. Ebenso muss sichergestellt werden, dass der Code komplett geprüft wurde und dass keine Funktionen oder „tote“ Bereiche ausgelassen wurden. Zu diesem Zweck arbeiten die statische und die dynamische Analyse oft Hand in Hand, denn Daten und Kontrolle sind die beiden wichtigsten Security-Aspekte. Beispielsweise muss eruiert werden, wer Zugriff auf welche Daten hat, wer Lese- und wer Schreibberechtigung hat, welche Datenflüsse von und nach welchen Instanzen erfolgen und wie sich alle diese Faktoren auf die Kontrolle auswirken. Die mit „wer“ erfragten Personen können Entwickler und Bediener, aber auch Hacker sein. Ebenso kann es sich jedoch um Software-Komponenten handeln, die sich entweder in der Applikation selbst oder irgendwo im Netzwerk befinden.

Neben dem Scannen des Quellcodes auf Konformität zu MISRA und anderen Richtlinien verlangt Security also nach rigoroser und gründlicher Prüfung auf funktionale Schwachstellen sowie nach Beachtung der Programmierregeln und Richtlinien im Quellcode. Letzteres hängt von der automatischen Testgenerierung ab, und diese basiert wiederum auf der statischen Analyse des Codes vor seiner Kompilierung. Die von der statischen Analyse bereitgestellten Informationen helfen dem automatischen Testgenerator, die richtigen Stimuli für die Software-Komponenten der Applikation zu erstellen. Abgesehen davon können Funktionstests auf manuellem Weg anhand des Lastenhefts entwickelt werden. Das sollte auch Tests der funktionalen Sicherheit einschließen, wie etwa die korrekte Ausführung einer blockierungsfreien Bremsung.

Neben der Analyse auf die richtigen Programmierpraktiken hin hilft die statische Analyse der dynamischen Analyse auch bei Überdeckungstests, Funktionstests und der Kontroll- und Datenfluss-Analyse, indem sie die passenden Stimuli für den automatischen Testgenerator beisteuert. Letzteres ist entscheidend für die Markierung und Korrektur potenzieller Problembereiche sowie zum Produzieren von Kennwerten für die Software-Qualität. Unternehmen, die bei ihren Entwicklungen strenge Automotive-Standards einzuhalten haben, müssen für die Zertifizierung ihrer Software möglicherweise nachweisen, dass die Kopplung von Daten- und Kontrollfluss analysiert wurde. Die LDRA Tool Suite trägt dem mit grafischen Datenflussanalyse-Reports und Flussdiagrammen Rechnung (Bild 2).