Wie Open-Source-C++-Code Sicherheitsrisiken mit sich bringen kann

Open-Source-Bibliotheken und -Frameworks sind eine hervorragende Möglichkeit, Entwicklungsprojekte schnell auf den Weg zu bringen. Open Source ermöglicht Entwicklern Großes, ohne das Rad neu erfinden und Lösungen für Probleme entwickeln zu müssen, die bereits gelöst wurden.

Allerdings birgt jede Ergänzung eines Projekts um Code das inhärente Risiko, potenzielle Schwachstellen einzuführen, die durch Fehler oder böswillige Absicht hineingelangt sein können.

Dieser Artikel zeigt, wie Open-Source-Code Schwachstellen in die Software-Lieferkette einbringt. Außerdem erfahren Sie, wie Sie Schwachstellen in der C++-Open-Source-Sicherheit mithilfe automatisierter Schwachstellen-Scanner erkennen können.

Wie Open-Source-Code Sicherheitsrisiken mit sich bringt

Das Open-Source-Software-Ökosystem ist eng miteinander vernetzt. Wenn Sie eine Open-Source-Komponente in Ihren Code einbinden, bringt diese Abhängigkeiten mit sich. Es ist schwierig, kontinuierlich den Überblick über die Sicherheitsprobleme zu behalten, die in den einzelnen Abhängigkeiten stecken könnten. Außerdem können Sie sich nicht immer darauf verlassen, dass Paketverantwortliche diese Schwachstellen rechtzeitig beheben. Das bedeutet, dass sich in den Open-Source-Paketen Ihrer Codebasis ungepatchte Schwachstellen befinden können.

Daten aus aktuellen Untersuchungen von Snyk und der Linux Foundation zeigen, dass die Behebung von Schwachstellen in Open-Source-Projekten immer länger dauert: 2018 waren es 49 Tage, 2021 bereits 110 Tage. Die Behebung von Schwachstellen in Open-Source-Projekten dauert fast 20 % (18,75 %) länger als in proprietären Projekten. Aufgrund dieser Komplexität sind Open-Source-Anwendungen mit bekannten Schwachstellen ein attraktives Ziel für Hacker.

Schwachstellen durch Pufferüberläufe sind in hardwarenahen Programmiersprachen wie C oder C++ weit verbreitet, da Entwickler den Speicher selbst zuweisen müssen. C und C++ schützen Anwendungen nicht davor, dass Clients Daten über die festgelegten Grenzen eines Puffers hinaus abrufen oder schreiben. Dadurch sind C++-Open-Source-Projekte anfällig. Bei Anwendungen mit unzureichender Speicherverwaltung können Angreifer diese Schwachstelle ausnutzen und ausführbaren Code in das Programm einschleusen.

Betrachten Sie beispielsweise den Glibc-Fehler in der Bibliothek libresolv der GNU C Library. Dieser Fehler machte Glibc anfällig für Pufferüberlauf-Angriffe, wenn die Bibliotheksfunktion getaddrinfo verwendet wurde.

Ein Angreifer kann diese Schwachstelle ausnutzen, indem er einen Client dazu bringt, eine schädliche Domain abzufragen. Anschließend kann er eine Payload zurückgeben, die den Fehler auslöst. Hat der Client Root-Rechte, kann dies das System kompromittieren und zu einem Man-in-the-Middle-Angriff führen. Glibc wird auf Millionen von Systemen mit dem Linux-Kernel eingesetzt. Daher kann jedes System betroffen sein, auf dem eine Version von Glibc mit dieser Schwachstelle läuft.

Was ist eine Software-Lieferkette?

Der Begriff „Lieferkette“ wird traditionell in der Fertigungsindustrie verwendet. Ein Autohersteller kann beispielsweise einige Teile selbst herstellen und andere Teile von anderen Unternehmen beziehen. Das bedeutet: Bevor ein Auto seinen Besitzer erreicht, haben viele Menschen mit unterschiedlichen Werkzeugen daran gearbeitet.

In der Software funktioniert die Lieferkette ganz ähnlich. Die Software-Lieferkette umfasst alles, was in Ihren Code einfließt oder mit ihm in Berührung kommt – von der Entwicklung bis zur Bereitstellung. Dazu gehören Code und Binärdateien, die Entwickler, die am Projekt gearbeitet haben, sowie die Repositorys, in denen es bereitgestellt wird. Auch Build-Tools, Paketierungsskripte und die Anwendungsinfrastruktur zählen dazu. Die Sicherheit der Lieferkette ist von entscheidender Bedeutung.

Da die Software-Lieferkette aus vielen Elementen besteht, kann sie sehr komplex werden. Hacker nutzen diese Komplexität gerne aus.

Schwachstellen in der Software-Lieferkette

Bei einem Angriff auf die Software-Lieferkette nutzen Angreifer vorgelagerte Komponenten, die mit dem Ziel ihres Angriffs verbunden sind, um sich Zugriff zu verschaffen. Sie können auch die Dienste angreifen, die die Software verteilen oder ausführen. Diese vorgelagerten Komponenten sind dabei nicht unbedingt das Angriffsziel – sie dienen lediglich als Zugangsmöglichkeit.

Die drei wichtigsten Angriffsziele in einer Lieferkette sind Abhängigkeiten, Pipelines und Pipeline-Abhängigkeiten.

Abhängigkeiten

Angreifer nehmen Open-Source-Abhängigkeiten ins Visier, die Entwickler beim Erstellen von Anwendungen einbinden. Wenn ein Angreifer eine bekannte Schwachstelle ausnutzt, um Malware in ein typisches Open-Source-Paket einzuschleusen, sind Softwareanwendungen, die dieses Paket als Abhängigkeit installieren, gefährdet. Da Softwareanwendungen möglicherweise mehr als eine Abhängigkeit enthalten, in der sich weitere Abhängigkeiten befinden, ist es schwierig, mögliche Schwachstellen nachzuverfolgen. Dadurch werden Abhängigkeiten zu einem leichten Angriffsziel.

Pipelines

Bei einem Pipeline-Angriff nehmen Angreifer die Continuous-Integration- und Continuous-Deployment-Pipeline (CI/CD-Pipeline) ins Visier, da sie eine große Angriffsfläche bietet. Sie kann auf Standardkonfigurationen, Sicherheitsanmeldedaten, Datenbanken und proprietären Code zugreifen. Wenn Angreifer daher schädlichen Code in eine CI/CD-Pipeline einschleusen und diese kompromittieren, können sie eine Hintertür in Anwendungen schaffen, die diese Pipeline nutzen.

Pipeline-Abhängigkeiten

Angreifer können auch Pipeline-Abhängigkeiten ins Visier nehmen, um Zugriff auf eine Build-Umgebung zu erhalten. So nutzten die Angreifer beim Codecov-Sicherheitsvorfall die Anmeldedaten eines Docker-Images, um ein Bash-Skript zum Hochladen von Daten zu ändern. Sie passten das Skript so an, dass es ihnen die Umgebungsvariablen der Codecov-Nutzer sendete.

Schwachstellen in Open-Source-Abhängigkeiten erkennen

Auch wenn Open-Source-Code seine eigenen Probleme mit sich bringen kann, können Entwickler damit dennoch Erstaunliches leisten und auf der Arbeit anderer aufbauen. Entwickler müssen jedoch Schwachstellen erkennen und die Qualität des Open-Source-Codes prüfen können, den sie in ihren Projekten verwenden. Für die meisten Unternehmen ist es jedoch nicht praktikabel, die Ressourcen für manuelle Code-Reviews und Audits von Open-Source-Code vor dessen Verwendung aufzuwenden.

Es wäre schwierig, in jeder C/C++-Abhängigkeit der Lieferkette Schwachstellen wie Pufferüberläufe, Nullzeiger, Integer-Überläufe und -Unterläufe zu erkennen. Eine Nullzeiger-Schwachstelle in einem Open-Source-C/C++-Code, der in unserer Software-Lieferkette verwendet wird, kann beispielsweise von Hackern angegriffen werden und zu einem Absturz führen. Dabei spielt es keine Rolle, ob der Anwendungscode selbst keine Schwachstellen enthält: Die Schwachstellen im Open-Source-Code machen die Anwendung unsicher.

Es gibt zwei zentrale Methoden, um Schwachstellen in Open-Source-Abhängigkeiten zu erkennen: eine sichere Software-Lieferkette schaffen, in der jeder Beteiligte vertrauenswürdig ist, und automatisierte Schwachstellen-Scanner wie Snyk für C/C++ verwenden.

Eine sichere Software-Lieferkette schaffen

Alle Beteiligten in der Lieferkette im Blick zu behalten und sicherzustellen, dass sie vertrauenswürdig sind, ist in der Theorie eine gute Lösung, aber in der Praxis äußerst schwer umzusetzen. An der Software-Lieferkette sind zahlreiche Entwickler beteiligt, die für verschiedene Bibliotheken und Komponenten einer Anwendung verantwortlich sind.

Automatisierte Schwachstellen-Scanner wie Snyk für C/C++

Eine praktikablere Lösung ist die Analyse von Open-Source-Code auf Sicherheitslücken. Manuelle Scans können jedoch zeitaufwendig und fehleranfällig sein. Best Practice ist es, Open-Source-C++-Code mit einem automatisierten Schwachstellen-Scanner wie Snyk zu scannen.

Mit Snyk Open Source erhalten Entwickler einen Überblick über den verwendeten Open-Source-C++-Code. Die Snyk CLI wandelt die Dateien in digitale Signaturen – sogenannte Hashes – um. Diese werden mit den Snyk-Datenbanken abgeglichen, um eine Liste passender Open-Source-Komponenten zu erstellen. Entwickler können Schwachstellen erkennen, indem sie diese Liste mit der Snyk Vulnerability Database abgleichen.

Im Gegensatz zu anderen Schwachstellen-Scannern, die einzelne Dateien scannen, berücksichtigt Snyk den Kontext der Dateien. Mithilfe ergänzender Dateien wie Readme-Dateien und Installationsskripten reduziert Snyk die Anzahl falsch positiver Schwachstellenmeldungen. So werden unnötige Meldungen minimiert und Entwickler können sich auf die erforderlichen Korrekturen konzentrieren.

Sobald eine Schwachstelle erkannt wird, benachrichtigt Snyk die Entwickler in der IDE oder CLI und ermittelt automatisch das minimale Upgrade, das die Schwachstelle behebt, ohne anderen Code zu beschädigen.

Fazit

Die Beliebtheit von Open-Source-Software nimmt zu. Dadurch enthalten immer mehr Anwendungen Bibliotheken und Komponenten von Drittanbietern, die von unbekannten Personen entwickelt und gepflegt werden. Da diese Bibliotheken in öffentlichen Repositorys zu finden sind, können Angreifer weniger sichere Bibliotheken ausnutzen, um sich Zugriff zu verschaffen.

Um Schwachstellen bei der Arbeit mit Open-Source-Code in C++-Projekten zu vermeiden, sollten Sie einen automatisierten Schwachstellen-Scanner wie Snyk Open Source verwenden. Damit können Sie Open-Source-C++-Projekte in Ihrer Anwendung auf Schwachstellen scannen, schädliche Bibliotheken erkennen und Ihre Software vor einer Kompromittierung schützen.

In der Snyk-Dokumentation für C/C++ erfahren Sie, wie Sie Ihre C/C++-Projekte scannen.