Der neue Personalausweis NPA spaltet Anwender und Experten in Deutschland: Einige preisen die hohe Sicherheit für jeden Bürger, andere befürchten Überwachung und Fälschbarkeit. Bei genauem Hinsehen fangen die Probleme jedoch bereits viel früher an. Manche Installationsroutine hat eine Leiche im Keller.

Von Sicherheit als ganzheitlichem Prozess predigen Sicherheitsberater gerne und meinen damit, dass es nicht nur darauf ankommt, ob ein Produkt oder eine Lösung die richtige Kryptographie und ein geeignetes Verschlüsselungsprotokoll verwendet. Es sollten auch die Benutzer mit den Sicherheitsfunktionen vertraut und die umgebende Informationstechnik auf dem neusten Stand sein.

Dazu gehört auch die Installation der beteiligten Softwarekomponenten. Wer etwa SCM Microsystems Basiskartenleser SCL011 einsetzen möchte [1], um seinen neuen elektronischen Personalausweis auszulesen (siehe Abbildung1), freut sich zunächst über die vorhandenen Linux-Treiber [2]. Da ein Kartenleser sich jedoch komplex in die Linux-Distribution einklinkt, unterstützt der Hersteller die Anwender mit einem Installationsskript, das er als Bash-Skript ausführt.

So gilt es, zunächst den über USB verbundenen Kartenleser überhaupt anzusprechen. Das Paket »libusb« installieren die meisten Distributionen bereits mit. Das Low-Level-Protokoll PC/SC, das auf serielle Leitungen setzt, müssen die meisten Systemverwalter erst – beispielsweise über das Paket »libpcsclite1« – unter Debian und seinen Derivaten einspielen.

Umsichtige Prüfung

Nach diesen Vorbereitungen darf der Admin als Root das der Treiberbibliothek beigelegte Skript »install.sh« ausführen (Listing1). So installiert er die herstellerspezifische Software für den Leser, der offiziell nach der technischen Richtlinie TR 03119 des Bundesamts für Sicherheit in der Informationstechnik [3] zugelassen ist.

Hier lauern erste Hürden: Der Code geht davon aus, dass sich der Anwender mit seiner Shell im ausgepackten Installationsverzeichnis befindet. Ruft er das Skript von einem anderen “Current Working Directory” aus auf, droht Unheil.

Klappt das Anlegen des »bundle_path« – trotz fehlender Prüfung, ob das Verzeichnis schon existiert – eher zufällig wegen des Parameters »-p«, so kopiert der »cp«-Befehl in Zeile 19 eventuell die falschen Dateien, da das Skript von einem Aufruf aus seinem Installationsverzeichnis ausgeht, was nicht zwangsläufig stimmt.

Hinterlistige Leere

Gerade wer solche Pakete in »/tmp« auspackt, ist aber nicht davor gefeit, dass ein Kollege oder Anwender dann eigene Dateien mit der Endung »bundle« dem Skript unterschiebt. Wenn ein Angreifer etwa mutmaßt, dass der Admin aus dem »/tmp«-Verzeichnis heraus arbeitet, kann er dort Dateien anlegen, die Leerzeichen enthalten und die mit der Zeichenfolge »bundle« enden.

Defensive neue Dateien

Die For-Schleife in Zeile 29 kommt damit nicht zurecht. Das Suchmuster »*.bundle« ohne doppelte Anführungszeichen expandiert die interpretierende Shell zu mehreren Argumenten und setzt sie schließlich in Zeile 30 ein. Die Symlinks legt das Skript immerhin mit Rootrechten an und überschreibt damit im ungünstigsten Fall auch Systemdateien.

Um diese Probleme zu vermeiden, befolgen erfahrene Bash-Entwickler einige Faustregeln. Zunächst einmal gilt als gute Praxis, jede Interpolation von Variablen, die ein »$« einleitet, durch Doublequotes zu schützen. So entstehen nicht mehr Argumente als vorgesehen.

Zweitens sollte das Anlegen neuer Dateien und Verzeichnisse nur dort geschehen, wo ausschließlich Root den Schreibzugriff hat, um zu vermeiden, dass Angreifer Symlinks anlegen und damit Systemdateien überschreiben. Und schließlich gilt es als gute Praxis für Skripte, zu prüfen, unter welcher UID der Anwender sie ausführt und von wo aus.

Kommando zurück!

Der Installer »install.sh« birgt noch eine weitere Merkwürdigkeit: Im unteren Teil des Skripts konstruiert er seinerseits sein Gegenstück »uninstall.sh« (siehe Listing2). Dazu baut er diese Datei Zeile für Zeile auf und fügt die Angaben einzeln dem neuen Bash-Skript hinzu. Ganz abgesehen von der miserablen Lesbarkeit eines Skripts, das ein anderes erzeugt, lauern dabei Gefahren – besonders beim Quoting.

Zeile 18 ist ein gutes Beispiel: Wenn der Backslash vor der eingebauten Variablen »$?« fehlt, würde der Kommando-Interpreter den Rückgabewert des letzten Kommandos zur Zeit des Erzeugens des Skripts einsetzen, nicht wie gewünscht zur Laufzeit des Uninstallers.

Das Skript von SCM macht diese Fehler zwar nicht, aber eleganter wäre es schon gegangen: Mit so genannten Here-Dokumenten lassen sich gerade mehrzeilige Texte gut in den Code einbetten. Dazu notiert der Entwickler beispielsweise:

cat <<EOF > "$installpath/uninstall.sh"
#!/bin/bash
# Code und Kommentare
[UCC:x00-fake-italic][...]
EOF

Wenig bekannt ist, dass Entwickler in diesem verbatim eingebetteten Code sogar Variablen verwenden dürfen. Kleinere Stückchen Programmcode können sie darüber hinaus mit »$(Kommando)« einbetten. Das macht den Code oft deutlich lesbarer. Die Bash kennt noch ein paar Spezialitäten beim Delimiter der Here-Dokumente. Traditionell verwenden Bash-Entwickler meist »EOF« als Trenner, aber jede Zeichenfolge ist erlaubt. Wer diesen String am Anfang in einfache Anführungszeichen setzt, weist damit die Shell dazu an, wirklich jedes Zeichen des Dokuments literal zu verwenden und nicht einmal mehr Substitutionen mit »$« durchzuführen.

Unsicheres Installationsskript für Sicherheitslösung

Gerade Installationsroutinen, die es zudem oft erfordern, dass der Admin sie mit privilegierten Rootrechten aufruft, bergen Gefahren, wenn der Entwickler einen bestimmten aktuellen Pfad voraussetzt oder ohne Prüfung Dateien schreibt.

01 #!/bin/bash
02 # Install script
03
04 # Identify the bundle path:
05 # Try to get the USB bundle path on the fly
06 bundle_path=`pkg-config libpcsclite --variable=usbdropdir`
07 ini_path="/usr/local/scm/ini"
08 ini_name="scl011.ini"
09
10 [ ... distributionsabhängiges Ermitteln von "$bundle_path" ... ]
11
12 # Installation of the driver bundle(s)
13 # Create the appropriate directory for
14 # placing the bundle(s)
15 mkdir -p $bundle_path
16
17 # Copy the driver bundle(s)
18 echo "Copying driver bundle(s) to $bundle_path"
19 cp -rf ./proprietary/*.bundle $bundle_path
20 [ ... Fehlerbehandlung ... ]
21
22 # Create symbolic link from open source
23 # pcscd bundle path
24
25 if [ "$bundle_path" !=      "/usr/local/pcsc/drivers" ]; then
26         echo "Creating symbolic links from              /usr/local/pcsc/drivers"
27         mkdir -p /usr/local/pcsc/drivers
28         cd ./proprietary
29         for bundle in *.bundle; do
30             ln -sf $bundle_path/$bundle
                      /usr/local/pcsc/drivers
31         done
32         cd ..
33
34         echo "Created symbolic links"
35 fi

Dabei reichen auch Tests nicht aus, ob die geplante Datei schon existiert, da sich sonst eine Race-Condition ergibt. Letztlich wäre es doch eine Blamage, wenn eine ansonsten sorgfältig entwickelte Security-Anwendung wie ein Kartenleser bereits Probleme mit der Installation hätte. SCM ist informiert.

Abbildung 1: SCMs Kartenleser SCL011 holt sich kontaktlos Daten vom neuen elektronischen Personalausweis. Bei der Installation der Linux-Treiber lauern jedoch Fallen durch Symlink-Attacken.

01 # Create uninstall script
02
03 echo "#!/bin/bash" > uninstall.sh
04 echo "# Uninstall script" >> uninstall.sh
05
06 echo "" >> uninstall.sh
07 echo "echo \"Uninstalling...\"" >> uninstall.sh
08 echo "" >> uninstall.sh
09
10 echo "" >> uninstall.sh
11 echo "# Uninstallation of the driver bundles(s)" >> uninstall.sh
12 if [ "$bundle_path" != "/usr/local/pcsc/drivers" ]; then
13   echo "# Remove symbolic link from open source pcscd bundle path" >> uninstall.sh
14   echo "echo \"Removing symbolic links from/usr/local/pcsc/drivers\"" >> uninstall.sh
15   cd ./proprietary
16   for bundle in *.bundle; do
17     echo "rm -rf /usr/local/pcsc/drivers/$bundle" >> ../uninstall.sh
18     echo "if [ \$? != 0 ]" >> ../uninstall.sh
19     [...]