Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
24 Elektronik 25 2021 EmbEddEd TEchnology sie eingehalten werden oder nicht Ob eine Vorgabe entscheidbar oder unentscheidbar ist gilt ganz allgemein und hängt nicht vom verwendeten Analysewerkzeug ab Dass es unentscheidbare Probleme gibt kann man sich am Halteproblem Halting Theorem klarmachen Bei unentscheidbaren Vorgaben kann es False Positives und False Negatives geben Bei einem False Positive wird die Verletzung einer Vorgabe gemeldet obwohl in Wahrheit gar keine Verletzung vorliegt Bei einem False Negative wird keine Verletzung einer Vorgabe gemeldet obwohl eine solche vorliegt Bei einem statischen Analysetool ist die Möglichkeit von False Negatives problematisch denn selbst wenn das Werkzeug keinen Fehler meldet kann man nicht sicher sein ob nicht doch einer vorliegt Eigentlich muss man dies durch geeignete andere Maßnahmen überprüfen etwa einen Review Dies reduziert den Nutzen eines statischen Analysetools gewaltig Allerdings kann ein Werkzeug in Bezug auf eine bestimmte unentscheidbare Vorgabe »sound« sein Das bedeutet dass für diese Vorgabe False Negatives ausgeschlossen sind allerdings werden – wegen der Unentscheidbarkeit – False Positives vorkommen Auch diese müssen überprüft werden etwa durch einen Review aber der Aufwand ist normalerweise wesentlich geringer weil gezielter vorgegangen werden kann als bei der Suche nach möglichen False Nega tives Die Anzahl der False Positives bildet ein Kriterium für die Qualität eines Analysewerkzeugs man könnte zwei unterschiedliche Werkzeuge danach bewerten welches bei Soundness für eine unentscheidbare Vorgabe weniger False Positives beim gleichen Quellcode hat Leider fallen die am meisten interessierenden Safetybzw Security-Probleme beispielsweise Division durch null in die Kategorie unentscheidbar Nummerierungen von Schwachstellen Mit Common Vulnerabilities and Exposures CVE und Common Weakness Enumeration CWE gibt es zwei Nummerierungssysteme für Sicherheitslücken oder Schwachstellen in Software und auch in Hardware [1 2] Das Ziel ist eine gemeinsame Sprache zur Bezeichnung der Schwachstellen was durch die Nummerierung erreicht wird Beide Nummerierungen sind im Internet einsehbar werden von der Community gepflegt und von der Mitre-Organisation unterstützt Beispiele für Security-Vorgaben Im Folgenden werden einige Verletzungen von Vorgaben betrachtet und es wird bewertet inwieweit sie mittels Werkzeugen gefunden werden können und ob es sich mehr um ein Safetyoder um ein Security-Problem handelt Pufferüberlauf Im Bild 2 meldet das Werkzeug ECLAIR einen Pufferüberlauf [10] Dies liegt daran dass das Array s[] für den Namen nur ein Zeichen das Xvorsieht Wird nun ein Name mit mehr als einem Zeichen an der Stelle des Xin das Array hineinkopiert wird Speicher überschrieben Pufferüberlauf ist ein Klassiker unter den Security-Problemen denn durch das Ausnutzen eines Pufferüberlaufs könnte beispielsweise die Rücksprungadresse einer Funktion manipuliert werden wodurch der Rücksprung zu beliebigem Schadcode führen könnte Sowohl CERT als auch Csecure nennen dieses Problem CERT unter der Bezeichnung ARR30-C Do not form outofbounds … array subscripts und STR31-C Guarantee… sufficient space … Csecure in Abschnitt 5 22 Forming or using outofbounds … array subscripts [invptr] Die Common Weakness Enumeration führt es unter CWE-120 Classic buffer overflow Man kann aber auch der Meinung sein es handelt sich in erster Linie um einen Programmierfehler und hat mit Safety oder Security direkt nichts zu tun Falls Speicher durch einen Pufferüberlauf überschrieben wird ist dies ein Fehler der undefiniertes Verhalten Un definied Behavior bewirkt und das muss vermieden werden Verschmutzte Daten Im oberen Teil von Bild 3 liest die Funktion fgets den Inhalt einer Datei in den Puffer input buf[] ein Dieser Inhalt kommt für das Programm von außen und das Programm hat keine Information was in input buf[] enthalten ist somit sind in input buf[] sogenannte »tainted« verschmutzte Daten Im obigen Beispiel werden die verschmutzten Daten als Parameter an die Funktion system übergeben die diese Daten als Kommando ausführt Dadurch kann ein beliebiges Kommando ausgeführt werden was ein hohes Security-Risiko darstellt Dies führt dazu dass die Verletzung der Direktive D14 4 aus Amendment 1 von MISRA C 2012 gemeldet wird Amendment 1 enthält die zusätzlichen Security-Vorgaben s o Diesen Fall sollte man als Security-Problem betrachten allein von der Tatsache dass ein beliebiges Kommando an die Funktion system zur Ausführung übergeben wird tritt zwar noch kein undefiniertes Verhalten ein – jedoch kann die Ausführung des Kommandos dazu führen Bild 3 Verschmutzte Daten und wie sie gesäubert werden können Bild Hitex