Bildergalerie
Freischalten der SSA Funktion im Property-Bereich.
SSA Analysefenster im Inspector XE.
Codezuordnung des Problems 78.
Erweiterte Problembeschreibung des Problems 78.
Sourcecode-Darstellung des Problems 78.

Das Konzept des neuen Entwicklungstoolpakets basiert auf einer statischen Sicherheitsanalyse (Static Security Analysis = SSA). Sowohl mit Intel Fortran als auch in Intel C/C++ geschriebene Programme können damit auf Sicherheitslecks überprüft werden. SSA unterscheidet etwa 250 Sicherheitsfehlerarten.

Dazu wird der Quellcode mit dem neuesten Intel C/C++ Compiler b.z.w. der Version12.0 des Intel Fortran-Compilers und unter Zuhilfenahme der graphischen Benutzerschnittstelle (GUI) des Intel Inspector XE analysisert. Da nur der Quellcode untersucht wird, wird hier von einer statischen (im Gegensatz zu einer dynamischen) Analyse gesprochen. Diese Untersuchung ist übrigens auch auf Sourcecode möglich, der zunächst nicht mit Intel-Compilern erstellt wurde. Man würde diesen Quellcode mit den Intel Compilern neu übersetzen, dann die Analyse auswerten, Fehler bereinigen und – falls man im ursprüngliche Compilerumfeld bleiben möchte – die Programmlecks ebenfalls im Originalquellcode beseitigen und mit dem ursprünglichen Kompiler neu übersetzten.

Intel Parallel StudioXE besteht übrigens nicht nur aus dem Fortran- und C++ Compilern, sondern auch aus diversen Bibliotheken. Darüberhinaus gehören zu dieser Suite auch der Intel Vtune Amplifier XE, ein Analysetools das u.a. dem Auffinden von Hotspots und Concurrency-Analyse paralleler Programme dient, und der Intel Inspector XE, der das Aufspüren von Data-Races, Deadlocks und Memory Leaks erledigt. Die Beseitigung der mit dem Inspector XE gefundenen Fehler erhöhen ebenso wie die SSA die Codequalität. Im Gegensatz zur SSA arbeitet die Fehlerbeseitigung des Inspector XE mit einer instrumentierten, dynamischen Fehleranalyse, die während der Programmausführung durchgeführt wird.

Die SSA-Funktion der Intel Compiler und des Inspector XE sind nicht nur für die Softwareentwickler sondern auch für die Softwareingenieure der Qualitätsabteilungen gedacht, um Anwendungen gegen Sicherheitsangriffe resistent(er) zu machen. Dafür eignet sich der Command-Line Modus. Um diese langen Kommandos fehlerfrei zu generieren, kann man die Kommandos vom Inspector XE über dessen GUI (Buttons) generieren. Die eigentliche Kommandozeile wird dann per ‚Cut und Paste‘ erzeugt.

Die SSA-Funktionalität ist übrigens nur in Verbindung mit dem Gesamtentwicklungspaket (Bundle) Intel Parallel Studio XE b.z.w seinem Pendant dem Intel C++ Studio XE freigeschaltet.

Sicherheitslecks und Details zum SSA Konzept

Viele Sicherheitsschwachstellen, die willkommene Einladungen für Hacker sind, werden durch SSA aufgedeckt. Vor allem profitieren komplexe Applikationen davon, die dynamisch nur schwer auf Sicherheitslücken im Runtimemodus umfassend zu testen sind.
Obwohl es eine Vielfalt von Hacker-Sicherheitsattacken gibt, haben sich einige Muster der Vorgehensweise herauskristalisiert. Die weitverbreiteste Ursache von Programmschwachstellen ist die ungenügende Analyse von Eingabedaten und vor allem solcher Daten, die von einem entfernten Nutzer (Remote User) herstammen. Wenn dieses Einfalltor gefunden ist, nutzt der Hacker diese Schwäche, um bösartigen Code auf den PC zu laden und auszuführen. Oft geschieht dies durch fehlerhaftes Speicher- und Heapmanagment (z.B. Buffer Overflow oder Übertretung von Speichergrenzen).

Deswegen ist das Aufrechterhalten der Programmspeicherintegrität unter allen Umständen zu wahren und die unsichere Nutzung von ungeprüften Daten zu vermeiden.
Die SSA-Technologie deckt viele dieser Ursachen auf wie etwa:

• Buffer overruns, Arithmetischer Overflow, Teilen durch Null,
• nicht initialisierte Variablen und Objekte
• inkorrekte Nutzung von Zeigern, die über definierte Feldgrenzen  hinausreichen
• Speicherleaks
• Fehlerhafte, sicherheitskritische Nutzung parallelen Bibliotheken und Spracherweiterungen (OpenMP*, Cilk+,..)
• Fehlerhafte Nutzung von Zeichenketten, Speicherbereichen und Bibliotheksroutinenformatierungen
• Nichtgeprüfte Eingabedaten
• Heap Korruption durch inkorrekte dynamische Speicherallokation

Ein einfaches fehlerbehaftetes Programmierbeispiel sei hier kurz angeführt und dessen Probleme erläutert

char *p1, *p2 = (char *)malloc(10);
p1 = p2;
free(p1);
*p2 = ‘a‘; //Speicher wird verwendet nachdem er freigegeben wurde
free(p2); // Erneute (zweimalige) Freigabe des gleichen Speicherraums

Es ist leicht zu erkennen, wie Speicherdaten im Heap modifiziert werden, nachdem der Heap bereits freigegeben wurde. Ausserdem wird derselbe Speicher zum zweiten mal freigegeben, was das Heapmanagement durcheinanderbringen kann.

Begleitende Vorbereitungen für SSA

Zunächst einmal muss man in der Entwicklungsumgebung ( IDE) den Intel-Compiler auswählen, um SSA freizuschalten. Zur Nutzung der statischen Sicherheitsanalyse sollte eine neue SSA spezifische ‘Built‘-Konfiguration erstellt werden (zusätzlich zu den ‘Debug‘ und ‘Release‘ Builts). Dazu werden spezifische Compiler Optionen genutzt. Man kann SSA auch im Debug-Built verwenden, was zwar einen ersten Eindruck über die Sicherheitslecks generiert. Leider werden aber die Objektmodule des Debug-Modus überschrieben.

Der Prozess eine neue Built-Konfiguration zu erzeugen ist von Applikation zu Applikation unterschiedlich. Wenn der Built-Prozess aber mit einem IDE wie Microsofts Visual Studio oder Eclipse gesteuert wird, ist die Aufgabe recht einfach und vor allem sehr schnell zu bewältigen.
An einem Beispiel eines C++ Programms sollen die wesentlichen Schritte etwas detaillierter und mit Bildunterstützung erläutert werden:

Eine eigene SSA Built-Konfiguration wird über den ‘Configuration Manager‘ eingestellt. Dort wird ein eigener Name (hier ‘Source Code Analysis‘) für den SSA Built gewählt, wobei die vorher verwendeten Debug-Settings übernommen werden.
Falls noch nicht geschehen, muss spätestens an dieser Stelle der Intel C/C++ Compiler eingeschaltet werden.

Nun wird die SSA Funktion aufgerufen. Dies geschieht mittels der Project-Properties. Dort wird unter ‘Diagnostics‘ die SSA Option auf ‘All Errors and Warnings (/Qdiag-enable:sc3)‘ gesetzt (Bild 1).

Damit ist die Vorbereitung abgeschlossen und mit dem grünen Dreiecksymbol in der Mitte der Menüleiste des IDE kann der SSA-Lauf gestartet werden. Die Resultate werden anschliessend in ein SSA- Subdirectory geschrieben.

Unter dem Windows Betriebssytem erscheinen im Inspector XE automatisch die Resultate des gerade beendeten SSA-Testlaufs.

Auswertung der SSA Resultate mit dem Inspector XE

Das erste Fenster im Inspector XE zeigt Bild 2. Dieses Fenster besteht aus drei Hauptbereichen:

1. Der linke obere Ausschnitt zeigt eine Tabelle mit den Sicherheitsproblemen, die vom Entwickler untersucht werden müssen. Dise Tabelle kann sortiert werden, indem man auf den Spaltenkopf klickt. Standardmässig ist die Liste nach Gewichten mit Werten von 1 bis 100 bewertet. Höhere Zahlenangaben bedeuten eine höheres Gewicht. Probleme, die ein höheres Gewicht zugewiesen bekommen haben, sind von ernsterer Natur und sollten zuerst bearbeitet werden.

2. Der linke unter Fensterausschnitt zeigt mehr Details zu den Codebereichen des gerade mit dem Mauszeiger selektierten Problems.

3. Der rechte Ausschnitt beschreibt die verfügbaren Filterfunktionen. Damit kann kontrolliert werden, welche Probleme angezeigt oder verborgen und damit für den Betrachter herrausgefiltert sind.

Problemanalyse mittels Inspector XE

Ein relativ einfaches Problem respräsentiert der Fehler P78 ( der vierte Fehler im linken oberen Ausschnitt des Bildes 2. Gemäss der Kurzbezeichnung ‘unsafe format specifier‘ handelt es sich um das Problem eines unsicheren Formatbezeichners. Weitere Details finden sich im schraffierten gelben Bereich darunter. Die Zahl 15 zeigt die Gewichtung.
Die Problemkategorie ‘Format‘ bedeutet, dass sie einer falschen Nutzung der printf-Formatspezifikation zuzuordnen ist. Klickt man auf die Zeile mit dem Problem P78 erhält man Bild 4.
Der Eintrag in Bild 3, den man im linkeren unteren Fensterauschnitt sieht, zeigt an, dass das Problem den Staus Neu (New) besitzt. Er wurde zum ersten mal während eines Testlaufes erkannt.

 

In Bild 3 sieht man auch die Quellcodezurodnung (Datei parse.cpp, Zeile 187). Wir erkennen auch die Rolle , die die Quellcodereferenz spielt. ‘Format Mismatch‘ deutet an, dass ein Format Zeichenkette benutzt wurde. Es wird auch der Name der Funktion,die einen ‘GetString‘ und eine Parametersignatur zeigt, dargestellt.

Um noch mehr Details über das Probelm zu erhalten, kann man tiefergehende Informationen anforderen. Einige SSA-Fehler sind technisch recht schwierig auszumachen und benötigen weitere Erklärungen. Ein Klicken auf die rechte Maustatse im oberen rechten Ausschnitt (Bild 2) bringt ein Pop-Up Fenster. Wählt man ‘Explain Problem‘ erhält man die ‘Unsafe format specifier‘ Beschreibung (Bild 4).

Mit diesen Informationen ist es dann möglich, den Bezug zum Fehler im Quellcode herzustellen und das Problem zu lösen. Der schnellste Weg ist auf das Plus-Zeichen (siehe Bild 5) zu drücken.
Nun wird klarer, wo das Problem liegt. Der gelb gekennzeichnete Aufruf ‘fscanf‘ benutzt das Format Zeichenkette mit einen ‘ %s ‘ Formatbezeichner. Dieser liest Eingabezeichen bis zur nächsten neuen Zeile und speichert die Daten in das Feld ‘data‘ ab. Es gibt dabei keine Garantie, dass die Anzahl der gelesenen Zeichen keinen Overflow über die Feldgrenzen hinaus erzeugen. Damit könnte Speicher, der neben dem Feld liegt, inkorrekterweise überschrieben werden. Glücklicherweise kann man in diesem kurzen Codeausschnitt den Fehler umfassend betrachten und an dessen Korrektur gehen.
Es muss sichergestellt werden, dass eine begrenzte Anzahl von Zeichen eingelesen wird, die in das Feld ‘data‘ passen.