NuGet Paketverwaltung

Paketmanager: erst denken, dann tippen

Paketverwaltungen oder -manager sind längst nicht mehr nur Bestandteil von Betriebssystemen, sondern finden sich seit längerem auch im Zusammenhang mit Entwicklungsumgebungen bzw. Programmier- und Scriptsprachen wieder. Beispiele sind Composer für PHP, NuGet für .NET oder npm für JavaScript.

Die Hauptaufgabe der Paketverwaltungen ist das unkomplizierte Einbinden von Bibliotheken in Softwareprojekte. Angefangen bei der Suche in einem zentralen Register nach benötigten Bibliotheken oder Funktionen, sorgt der Paketmanager auch meist für die richtige Integration der einzelnen Bestandteile in das bestehende Projekt. Zudem lädt ein Paketmanager automatisch andere Pakete nach, auf denen das gewünschte Paket aufbaut.
Es gibt nicht wenige Pakete die ein Dutzend oder mehr Abhängigkeiten – sog. Dependencies – zu andern Paketquellen haben.

Ein weiterer Vorteil der Paketmanager ist die einfache Aktualisierung von verwendeten Paketen und deren Dependencies. Statt die verschiedenen Quellen der einzelnen Projekte nach Updates und Patches zu durchsuchen, erledigt die Paketverwaltung diesen Job zentral.

Insbesondere in großen Bibliotheken und Frameworks sind die Abhängigkeiten zu anderen Projekten teilweise unübersichtlich. Daraus ergeben sich Probleme und Gefahren, die sich jede_r Entwickelr_in oder Projektleiter_in bewusst machen sollte.

Ungesehener Code

Neben den vielen Abstraktionsebenen durch verschiedene Frameworks in modernen Softwareprojekten bringen die Dependencies weiteren Quellcode mit sich, der, streng genommen, von den Projektbeteiligten vor der Integration auditiert werden müsste. Das gleiche gilt für alle Updates dieser Pakete.

In den meisten Fällen handelt es sich bei den Paketquellen um Open-Source Projekte, so dass auf einen Codereview-Prozess der Community gehofft werden kann. Letztendlich ist jedoch jeder selbst für den ausgeführten Code in seinen Projekten verantwortlich.

Abhängigkeit

Ein weiters Problem wird bereits durch das Wort Dependencies selbst benannt: Was passiert bspw. wenn grundlegende Paketquellen von jetzt auf gleich verschwinden?

So geschehen im März 2016, als das Paket left-pad von seinem Entwickler aus der Paketverwaltung npm für JavaScript gelöscht wurde. Tausende Projekte und Frameworks, darunter Node.js und Babel, ließen sich nach einem Update der Paketquellen nicht mehr nutzen.1
Der Grund für die Depublizierung war eine namenrechtliche Auseinandersetzung zu einer anderen Paketquelle (kik) des Entwicklers und dem Unternehmen hinter dem gleichnamigen IM.2

Typosquatting

Neben den infrastrukturellen Risiken der Paketverwaltungen bietet deren Funktionsweise jedoch auch Schwachstellen für aktive Angriffe.
Ein gezieltes Szenario, der zumeist mit einem CLI zu bedienenden Paketmanager, wäre mit der sog. Typosquatting Methode denkbar.

Typosquatting (zu engl.: squat = besetztes Haus, dt. Lehnübertragung: Tippfehlerdomain) ist eine Form von Cybersquatting, die darauf beruht, dass eine Person einen Uniform Resource Identifier (URI, also die Adresse der Website) in einem Webbrowser versehentlich falsch eintippt und dann auf eine alternative Seite geführt wird, die dem Typosquatter gehört.3

Nikolai Philipp Tschacher hat sich in seiner Bachelor Thesis mit genau diesem Thema auseinandergesetzt und untersucht, wie erfolgreich ein Übertragung des Typosquatting Angriffs auf populäre Paketmanager ist.

Dabei hat er nach einer Möglichkeit gesucht, bereits während der Installation eines Pakets, Code auf dem jeweiligen System ausführen zu können. Seine Betrachtung beschränkte sich auf die Paketmanager PyPi für Python, npm für JavaScript und rubygems.org für Ruby.

Der ausgeführte Code lieferte Informationen über das jeweilige System und die zur Installation des Pakets verwendeten Benutzerrechte an einen Webserver der Universität Hamburg zurück.

Das Ergebnis nach 214 erstellten und veröffentlichten Pakete mit ähnlichen Namen von populären Paketquellen ist erstaunlich bis beunruhigend.

Insgesamt kamen 45.334 HTTP Requests von 17.289 eindeutigen Hosts zusammen. Das bedeutet, dass der in den Paketen eingeschleuste Code auf über 17.000 Systemen innerhalb des etwa zwei monatigen Versuchs ausgeführt wurde.
Davon wurden 43,6% der Installationen mit Administrationsrechten ausgeführt. Ein Großteil der Hosts wurde mit Linux betrieben (8.614), gefolgt von Windows (6174) und OS X (4.758).4

Gesunder Menschenverstand

Paketmanager bieten einen hohen Komfort für Softwareentickler_innen und die Nutzung von bestehenden Bibliotheken bedeutet für das einzelne Projekt meist einen nicht unerheblichen Zeitgewinn. Außerdem ist die Devise, dass Rad nicht ständig neu erfinden zu wollen, nicht grundsätzlich verwerflich.

Es sollte jedoch die Frage erlaubt sein, welchen Mehrwert eine Bibliothek wie bspw. das genannte left-pad Paket, das im wesentlichen eine Zeichenkette mit Leerzeichen auf eine bestimmte Länge auffüllt, im Verhältnis zu den angeführten Risikofaktoren bietet.5

Dependencies erhöhen ohne Zweifel die Komplexität von Softwareprojekten. Grundsätzlich empfiehlt es sich natürlich, die Abhängigkeiten in Applikationen so gering wie möglich zu halten.
Zudem schadet ein regelmäßiger Blick in den eingebundenen Code sicher nicht. Informationen über die Community hinter den jeweiligen Paketquellen und deren Aktivität lassen sich bei Open-Source Projekten relativ einfach finden.

Im Zweifel ist der gesunde Menschenverstand auch in dieser Angelegenheit der beste Ratgeber.