Startseite > Embedded > Software > 14 neue MISRA-C-Regeln

Codierungsstandard

14 neue MISRA-C-Regeln

6. Juli 2016, 9:40 Uhr |

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Neue Regeln 7 bis 14

[ 7 ]

Regel 21.17: Die Verwendung der Stringbearbeitungs-Funktionen von <string.h> darf keine Zugriffe außerhalb der Grenzen jener Objekte zur Folge haben, auf die ihre Zeigerparameter Bezug genommen haben.

Die Funktionen in string.h beziehen sich üblicherweise auf Zeiger mit einem festgelegten oder dynamischen Bereich. In beiden Fällen muss darauf geachtet werden, dass Zugriffe auf den vorgesehenen Bereich beschränkt werden, damit nicht autorisierte Quellen nicht auf Speicherstellen außerhalb dieses Bereichs zugreifen können.

[ 8 ]

Regel 21.18: Ein an eine Funktion in <string.h> übergebenes Argument size_t muss einen geeigneten Wert haben.

Ähnlich wie in Regel 21.17 bezieht sich auch size_t speziell auf die Grenzen der Parameterzeiger. Da es sich bei Strings in C um Zeichen-Arrays handelt, ist deren Manipulation gleichbedeutend mit dem Manipulieren beliebiger anderer Speicherzeiger. Das Überprüfen des Werts der size_t-Argumente, die von diesen und an diese Funktionen übergeben werden, stellt sicher, dass geeignete Werte verwendet werden. So ist gewährleistet, dass andere Speicherbereiche des Prozesses nicht auf zweckwidrige Weise zum Ziel von Zugriffen oder Manipulationen werden, wodurch Daten oder die Kontrolle über einen Prozess auf einen Angreifer übertragen würden.

[ 9 ]

Regel 21.19: Die von den Standardbibliotheks-Funktionen localeconv, getenv, setlocale oder strerror übergebenen Zeiger sind nur so zu verwenden, als handele es sich bei ihnen um Zeiger des Typs const-qualified.

Diese Regel regelt ähnlich wie Regel 21.20 die Verwendung von Zeigern, um eine böswillige Manipulation von Strings zu verhindern.

[ 10 ]

Regel 21.20: Der von den Standardbibliotheks-Funktionen asctime, ctime, gmtime, localtime, localeconv, getenv, setlocale oder strerror übergebene Zeiger darf nicht im Anschluss an einen nachfolgenden Aufruf derselben Funktion verwendet werden.

Gebietsschema-Nachrichten steuern die Formatierung von Strings und definieren damit effektiv die Sprachlokalisierung der Software. Wenn Hacker die Formatierungsweise von Strings kontrollieren können, können sie sie zu beliebigen Ausgaben veranlassen und unter anderem auch die Programme kontrollieren, mit denen das erste Programm interagiert. Dies bedeutet, dass sich diese Strings nutzen lassen, um beliebige Befehle auszuführen und die Kontrolle über ein System zu erlangen. Das Kontrollieren des Gebietsschemas wurde bereits in Exploits genutzt, die Strings neu formatierten, um die Ausführung von Befehlen auf einem entfernten Computer zu ermöglichen.

Jobangebote+ passend zum Thema

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

[ 1 ]

Regel 22.7: Das Makro EOF darf nur mit dem nicht modifizierten Rückgabewert von Standardbiblio¬theks-Funktionen verglichen werden, die in der Lage sind, EOF zurückzugeben.

EOF ist als Markierung für das Ende einer Datei gedacht – jedoch nicht direkt, sondern nur als Bestandteil des Rückgabewerts einer Funktion. Da EOF nicht für die direkte Verwendung gedacht ist, können aus speziellen Verwendungsweisen von EOF Sicherheitslücken resultieren. Zum Beispiel muss die Verwendung des ‚speziellen Makro-Werts‘ EOF nicht unbedingt korrekt funktionieren. Wird auf unkorrekte Weise überprüft, ob die Verarbeitung einer Datei beendet ist, kann es zur Verarbeitung von nicht vorgesehenem Code kommen.

[ 12 ]

Regel 22.8: Der Wert von errno ist vor jedem Aufruf einer errno-setzenden Funktion auf null zu setzen.

Diese und die beiden folgenden Regeln haben ähnliche Zwecke. Errno dient zur Anzeige eines Fehlers, aber Funktionen setzen es nur auf ‚Fehler‘ und nicht unbedingt auf den Status ‚kein Fehler‘. Wenn der Wert nicht vor der Verwendung auf null gesetzt und der Wert manipuliert wurde, kann ein Fehler generiert werden, wenn in Wirklichkeit kein Fehler vorliegt, aber dennoch eine Fehlerbehandlung angestoßen wird. Diese fehlersetzenden Funktionen könnten manipuliert werden, um die Ausführung von Debugging-Code für arglistige Zwecke zu veranlassen.

[ 13 ]

Regel 22.9: Der Wert von errno ist nach dem Aufruf einer errno-setzenden Funktion auf null zu prüfen.

Bei dieser Regel geht es darum, errno korrekt einzusetzen und zu prüfen, ob der Wert nicht null ist. Da errno den Zugriff auf Code kontrolliert, der häufig für das Fehler-Debugging verwendet wird, muss es auf null gesetzt werden, bevor eine errno-setzende Funktion benutzt und geprüft wird, ob es nach wie vor den Wert null hat, sich also nicht geändert hat. Wird der Wert nicht ausdrücklich auf null gesetzt, lässt sich der Default-Wert manipulieren, um eine Verarbeitung der Error-/Debug-Fälle zu erzwingen.

[ 14 ]

Regel 22.10: Der Wert von errno ist nur dann zu überprüfen, wenn die zuletzt aufgerufene Funktion eine errno-setzende Funktion war.

Ähnlich wie bei den vorigen Regeln gilt auch hier, dass die Error-/Debug-Fälle Code enthalten, der während der Entwicklung nützlich ist, in der Produktion jedoch zum Herausschleusen sensibler Informationen oder für den zweckwidrigen Zugriff auf Funktionen genutzt werden kann. Ruft der Entwickler mehrere Funktionen auf, kann jede dieser Funktionen den Fehler setzen. Deshalb ist nach jeder Funktion, die den Fehler setzen kann, der Fehlerstatus zu prüfen.

Abweichungen möglich

In bestimmten Fällen erlaubt der MISRA-Standard auch Abweichungen vom Regelwerk. Das kann dann sinnvoll sein, wenn z.B. ein Automobilhersteller von seinen Zulieferern verlangt, einer bestimmten Version von MISCRA-C zu folgen, der Zulieferer aber gute Gründe dafür vorlegen kann, warum das nicht möglich oder sinnvoll ist. Dann können Auftraggeber und Auftragnehmer eine Vereinbarung treffen, dass in bestimmten Punkten vom Standard abgewichen werden kann