Binärcode-Analyse: Software- Qualität in fremden Händen

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

GrammaTech, Inc.

Zahlreiche Geräteentwickler kaufen die Embedded Software für ihr Industrie- oder IoT-Gerät von Drittanbietern zu. Doch wie ist zu gewährleisten, dass Code aus Händen Dritter zuverlässig und sicher ist?

Vertrauen ist die Mutter der Sorglosigkeit – Dieses Bonmot des spanischen Schriftstellers Baltasar Gracián y Morales aus dem 17. Jahrhundert gilt auch bei der Software-Entwicklung. Die Sorglosigkeit, wie in den vergangenen Jahren Software in vielen Bereichen entwickelt wurde, ist heute kaum mehr akzeptabel.

Immerhin nimmt Software im Zuge der digitalen Transformation, die aktuell abläuft, eine grundsätzlich andere Stellung ein als bisher. Sie wird die kritische Basis für physikalischen Produkte, für Dienstleistungen und für Geschäftsmodelle. Dabei nimmt Embedded Software als unverzichtbare Grundlage des Internet of Things eine besonders dominante Rolle ein.

Eine Herausforderung ist dabei, dass der Code auch für IoT-Devices immer komplexer wird: Bis vor kurzem mussten sich die wenigsten Embedded-Entwickler mit Fragen nach Netzwerk-Stack, Verschlüsselung und dergleichen beschäftigen. Immer mehr Funktionen, mehr Rechenleistung und neue Anforderungen bei Management und Wartung der Devices machen die Entwicklung kompliziert.

Eine Lösung dafür, die Entwicklungsabteilungen zunehmend nutzen, ist die Integration von Codeteilen aus externen Quellen. Das Marktforschungsunternehmen VDC Research ermittelte in einer Studie von 2016, dass im Embedded-Bereich fast 45 Prozent der Code-Basis aktueller Projekte von Dritten stammt. Gut die Hälfte davon steht laut der Studie als Open Source zur Verfügung. Die andere Hälfte wird kommerziell - und in der Regel in Binärform - vertrieben.

Bildergalerie

Risiko durch extern zugekauften Code

Innerhalb der Software Supply Chain entsteht dadurch ein unwägbares Risiko: Ist der Code aus externen Quellen sicher und entspricht er den Standards der eigenen Entwicklungsabteilung? Unter anderem sind folgende Bereiche davon betroffen:

Security: Mit dem Einsatz von Code aus externen Quellen werden möglicherweise vorhandene Sicherheitslücken in das eigene Projekt übernommen. Das stellt das eigene Unternehmen vor zwei Herausforderungen: Sicherheits-Updates des Code-Zulieferers müssen zeitnah in die eigene Anwendung übernommen und an die Kunden ausgerollte werden. Zudem kann der fremde Code versteckte und auch böswillige Schwachstellen aufweisen, für die das eigene Unternehmen geradestehen muss.

Zertifizierung: Entwickler, die Anwendungen in kritischen Bereichen wie Medizintechnik oder Avionik entwickeln, müssen sich bei Programmierung und Testing an klare Standards und Normen halten. Code Dritter, der in das eigene Projekt einfließt, muss nach denselben Standards zertifiziert sein. Die entsprechende vollständige Dokumentation seitens des Code-Zulieferers muss also vorliegen - oder der fragliche Code selbst zertifiziert werden. Bei Binärcode kann das ohne die richtigen Tools extrem schwierig werden.

Qualität: Fehler im externen Code müssen nicht gleich sicherheitsrelevant sein. Performance-Probleme oder Abstürze reichen aus, um den eigenen guten Ruf zu ruinieren. Zusätzliche Kosten für Updates oder sogar eine komplette Neuentwicklung sind da schon fast das kleinere Übel.

Verschleierung: Binärcode gegen Obfuscation

Eine manuelle Prüfung mag bei Quellcode zumindest theoretisch noch möglich sein, bei binären Dateien kommt man so nicht weiter. Zudem sollte nicht vergessen werden, dass der Quellcode nicht zwingend das fertige Produkt vollumfänglich repräsentiert. Jeder Compiler hat seine Eigenarten unter bestimmten Bedingungen, etwa beim Lesen von Union-Datentypen, mit dem unterschiedliche Datentypen im selbem Speicherbereich abgelegt werden können. Der Compiler entscheidet hier, wie er damit umgeht. Erst im Binärcode zeigt sich das Ergebnis.

Definition „Eingebettete Software“

Was ist Embedded Software?

Ein ähnlicher Effekt tritt auf, wenn Schadcode böswillig in den Quellen versteckt wird. Durch diese so genannte „Obfuscation“ ist es kaum möglich, einen Schadcode in den Quellen nachzuvollziehen. Ein Paradebeispiel dafür ist der Exploit im Project Unreal IRCD von 2010 (CVE-2010-2075), bei dem externe Daten über eine Socket-Verbindung ungeprüft Systembefehle ausführen konnten. Im Quellcode erscheint die betreffende Stelle als ein harmloses Makro zum Debug-Loggin (siehe Bild 1). Hinter der Verschleierung steht ein System Call, alles weist auf eine Insider-Sache hin. Im Binärcode hingegen zeigt sich das ganze Ausmaß der Bedrohung. Denn alle Obfuscation-Anstrengungen wurden vom Compiler aufgelöst, der Call fällt sofort ins Auge (siehe Bild 2).

Es ist also auf jeden Fall sinnvoll, Code aus externen Quellen ebenso zu überprüfen wie die eigene Entwicklungsarbeit. Dazu empfehlen fast alle Standards wie DIN EN 51508 ab einer gewissen Kritikalität der Anwendung den Einsatz statischer Analyse. Hierbei wird die Software nicht ausgeführt, sondern ein Modell erzeugt, das geprüft werden kann. Und damit auch mögliche Error Conditions, die in Test-Szenarien meist nicht auftreten, aber später für Probleme sorgen können.

Bildergalerie

Die meisten Tools sind jedoch nicht in der Lage, binären Code hinreichend zu untersuchen. CodeSonar von GrammaTech hingegen kann sowohl Binärcode als auch Quellcode auf Schwachstellen untersuchen. Dazu gehören Buffer Overrun/Underrun, Command Injection, Integer Overflow of Allocation Size, SQL Injection und Non-constant Format String

Das Tool erzeugt dazu ein Modell des gesamten Programms mit allen Source- und Binary-Bestandteilen: Was als Quellcode vorliegt, wird geparst und Binär-Code wird disassembliert. CodeSonar erzeugt daraus eine einheitliche Präsentation, die die Semantik beider Teile konsistent abbildet. Um mögliche Fehler zu erkennen, durchläuft das Werkzeug das Modell interprozedural und sucht nach Anomalien. Das Analyse-Tool ermittelt alle möglichen Zustände, die das Programm einnehmen kann. So können auch Fehler gefunden werden, die in definierten Test-Szenarien nicht auftreten.

Durch die Möglichkeit, die Analyse zu automatisieren, skaliert das bei CodeSonar implementierte Verfahren auch für große und komplexe Software-Projekte. Für die Entwickler und für das Unternehmen bedeutet das: Sichere Software bei einer kürzeren Time to Market. - und externen Herstellern muss nicht weiter blind vertraut werden.

Dieser Beitrag ist ursprünglich auf unserem SchwesterportalElektronikpraxis.deerschienen.

* Mark Hermeling ist Senior Director Product Marketing bei GrammaTech, Inc.

(ID:44896109)