Codierungsstandard 14 neue MISRA-C-Regeln

Codierungsstandard MISRA-C - eine sicherheitskritische Software.
Codierungsstandard MISRA-C - für sicherheitskritische Software.

Der Codierungsstandard MISRA-C legt fest, wie C-Code aussehen muss, wenn sicherheitskritische Software entwickelt wird. Nun gibt es eine Erweiterung, die neben Safety auch Security mit einbezieht.

Es lohnt sich nicht, lange darüber zu philosophieren, ob Systeme, die gegen Angriffe abgesichert sein sollen, auch funktional sicher sein müssen oder ob es umgekehrt ist, ob sichere Funktion nur dann möglich ist, wenn auch die IT-Sicherheit gewährleistet ist. Fest steht, dass sich Safety und Security in vielen Bereichen überlagern. Die MISRA-Regeln definieren eine Untermenge der C-Befehle, die sich für die Entwicklung von sicherheitskritischen Systemen eignen. Diese Regeln zielten vorwiegend auf funktionale Sicherheit ab, sorgen aber genauso für die Security eines Systems, denn wenn der Code Schwächen aufweist, können sich potenzielle Angreifer diese Schwachstellen zunutze machen und das System beschädigen, Fehlfunktionen auslösen oder auf Daten oder Funktionen zugreifen, auf die sie nicht zugreifen dürfen. Mit der jüngsten Erweiterung des Regelwerks adressiert das MISRA-Komitee das wachsende IT-Sicherheitsbewusstsein, das sich im Zuge immer stärker vernetzter Systeme und des Internet of Things gebildet hat.

Welcher Standard für was?

Dieses Sicherheitsbewusstsein ist inzwischen nicht mehr ganz neu und wurde auch schon von Standardisierungsgremien aufgegriffen. So gibt es z.B. CWE, die „Common Weakness Enumerations“, ein Projekt zur Vermeidung von Software-Konstrukten, die zu Schwachstellen in der Software führen können. Ein anderes Beispiel sind die CERT Coding Standards, die das Software Engineering Institute der Carnegie Mellon University in Pittsburgh in den USA erarbeitet. Dieser Standard ist ein gutes Hilfsmittel für Programmierer, wenn sie konkrete Regeln suchen, nach denen sich sicherer (secure) Code entwickeln lässt. Die CERT-Standards berücksichtigen nicht nur C und C++, sondern auch Java und Perl und die Android-Plattform. Unter dem Dach der internationalen Standardisierungsorganisation ISO hat eine Arbeitsgruppe den Standard ISO/IEC 17961:2013 „C Secure“ erarbeitet. Im Gegensatz zu den vorher genannten Standards richtet sich der ISO/IEC-Standard nicht an die Programmierer, sondern an die Tool-Hersteller. C Secure ist ein Regelwerk, das durch statische Analyse erzwungen werden kann. Die Regeln sind eine Sammlung von Anforderungen, die ein Tool-Hersteller erfüllen muss, damit Code per statischer Analyse oder/und durch einen C-Compiler auf Sicherheitslücken analysiert werden kann. Der Standard wurde – wie die Jahresangabe in seiner Bezeichnung nahelegt – im Jahr 2013 veröffentlicht, ein Jahr nach der letzten Überarbeitung des MISRA-Standards.

Die 14 Regeln der neuen MISRA-C-Ergänzung gehen aus diesen Richtlinien hervor und übertragen sie in den MISRA-C-Standard. Sie konkretisieren die ISO-Regeln und machen daraus automatisch nachprüfbare Vorschriften. Das Amendment enthält sowohl breiter gefasste Direktiven als auch spezifische Regeln. Die Einhaltung dieser zusätzlichen Richtlinien gibt Entwicklern die Möglichkeit, ihren Code gründlicher zu analysieren und den Regulierungsbehörden zu versichern, dass sie sich an Codierungspraktiken gehalten haben, die die Safety- und Security-Aspekte berücksichtigen.

 

[ 1 ]

Dir 4.14: Die Gültigkeit von Werten aus externen Quellen muss überprüft werden.

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.

 

[ 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 Codebereich 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.

 

[ 3 ]

Regel 21.13: Jeder Wert, der an eine Funktion in <ctype.h> übergeben wird, muss als unsigned char darstellbar sein oder den Wert EOF haben.

Viele Inline-Bibliotheken (z.B. ctype) können den Zugriff auf nicht vorgesehene Daten freigeben, wenn an sie Daten übergeben werden, die außerhalb des vorgesehenen Bereichs liegen. Bei ctype handelt es sich um eine einfache Inline-Bibliothek, mit der ein Entwickler feststellen kann, von welchem Typ ein bestimmtes Zeichen (z.B. ein reguläres Zeichen oder eine Zahl) ist. Sie wird meist mit einer Wertetabelle implementiert, und häufig erfolgt keinerlei Prüfung auf Zugriffe außerhalb der Wertetabelle. Sie könnte deshalb für den Zugriff auf nicht vorgesehene Speicherbereiche genutzt werden, indem Werte außerhalb des typischen Bereichs von –127 bis +128 übergeben werden, die per Default vorzeichenlos sind.

 

[ 4 ]

Regel 21.14: Die Standardbi¬bliotheks-Funktion memcmp darf nicht zum Vergleich null-terminierter Strings benutzt werden.

Die Funktion memcmp ist für den Vergleich von Speicherblöcken vorgesehen, nicht aber zum Vergleichen von Strings (z.B. Passwörtern). Da die Funktion mehr als nur ein True oder False ausgibt, lässt sie sich zum Aufdecken von Passwörtern in Datenbanksystemen nutzen.

 

[ 5 ]

Regel 21.15: Bei den Zeiger-Argumenten für die Standardbibliotheks-Funktionen memcpy, memmove und memcmp hat es sich um Zeiger auf qualifizierte oder nicht qualifizierte Versionen kompatibler Typen zu handeln.

Die Funktionen memcpy, memmove und memcmp dienen dem Verschieben und Manipulieren von Speicherinhalten. Indem man an sie Datentypen übergibt, die nicht immer geeignet sind, wird der Weg zur Manipulation von beliebigen Elementen (darunter auch ausführbarer Code) im Speicher geebnet.

 

[ 6 ]

Regel 21.16: Bei den Zeiger-Argumenten für die Standardbibliotheks-Funktion memcmp muss es sich entweder um einen Zeiger-Typ oder die Typen essentially signed, essentially unsigned, essentially Boolean oder essentially enum handeln.

Diese Regel hat Ähnlichkeit mit Regel 21.15 und dient ebenfalls dem Zweck, den Zugriff auf den Speicher zu kontrollieren, um das Manipulieren nicht vorgesehener Speicherbereiche zu unterbinden.