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.
Autonomes Fahren | Tools 28 Elektronik automotive 04 2020 Der Input aus einer in diesem Fall undefinierten Quelle kommt durch einen Call der Funktion getenv die den Inhalt der Umgebungsvariable CONFIG ausliest Der Programmierer geht davon aus dass der Inhalt der Umgebungsvariable in den Puffer passt Allerdings wird die Größe der Variable nicht überprüft Ist sie länger als 100 Zeichen kommt es zum Buffer Overflow Ein Angreifer der CONFIG manipulieren kann kann so auch das fragliche Programm angreifen ohne darauf direkt Zugriff zu haben Da buf eine automatische Variable ist die gleich am Anfang des Stacks abgelegt wird wird jedes Zeichen das über die erlaubten 100 hinausgeht außerhalb der Grenzen des Puffers des Programms geschrieben Dabei könnte die Variable count überschrieben werden je nachdem wie der Compiler den verfügbaren Platz im Stack zuweist Geschieht das kontrolliert der Angreifer den Wert dieser Variablen Außerdem enthält der Stack auch die Adresse an die das Programm nach der Ausführung dieser einen Prozedur springen wird Um hierüber eine Attacke zu starten kann der Angreifer den Wert der Variablen auf einen speziell dafür entworfenen String setzen der eine Return-Adresse nach den Wünschen des Hackers beinhaltet Ist die Funktion dann durchlaufen wird die manipulierte Adresse an den Caller der Funktion zurückgeliefert Der Angreifer kann so eingeschleusten SchadCode zur Ausführung bringen Statische Code-Analyse ergänzt Testing Es ist kaum möglich solche potenziellen Sicherheitslücken im Testing aufzudecken Denn Testing findet Fehler nur dann wenn drei Bedingungen gleichzeitig erfüllt sind ➔ Der Testfall muss den fehlerhaften Code durchlaufen ➔ Der Fehler muss zu einer Error Condition führen ➔ Die Error Condition muss zu einer Abweichung des Ergebnisses von dem erwarteten Ergebnis führen Zudem muss ein lauffähiger Code vorhanden sein das Testing kann also erst in einer recht späten Phase des Entwicklungsprozesses greifen Dabei gilt Je später ein Problem im Code entdeckt wird desto aufwendiger und teurer wird die Beseitigung Dazu bietet sich die statische CodeAnalyse an Im Gegensatz zum Testing wird bei der statischen Analyse ein Programm nicht ausgeführt Das Tool zur statischen Analyse erstellt wie ein Compiler aus dem Code eine Intermediate Representation IR ein Modell das systematisch durchlaufen und mittels Checkern auf definierte Probleme Bild 2 Analyse-Tools wie CodeSonar überführen den Code zunächst in eine Intermediate Representation um anhand dieser alle möglichen Steuerungsund Datenströme zu untersuchen Bild GrammaTech Bild 3 Die Warnung vor einem Buffer Overrun zeigt den Effekt von Tainted Data Bild GrammaTech