Ergebnisse des zweiten Sicherheitsaudits

Das zweite komplette Sicherheitsaudit von F-Droid ist abgeschlossen. Wir sind zufrieden mit den Ergebnissen, die erneut bestätigten, dass das Kernsicherheitsmodell und die Standardoperationen solide sind. Das Audit wies auf Probleme im Core-Build-Prozess hin, wo wir momentan auf manuelle Überprüfung durch vertrauenswürdige Mitwirkende vertrauen, um uns zu schützen. Dieses Audit zeigte auch, dass wir noch daran arbeiten müssen, um unser Ziel zu erreichen, dass der Android-Client selbst dann sicher bleibt, wenn er sich mit einem bösartigen Server verbindet, z. B. wenn ein nicht vertrauenswürdiges Repository manuell eingefügt wird, das von seinem Betreiber zu Exploit-Zwecken erstellt wurde. Der vollständige Auditbericht ist hier abrufbar: report_otf_fdroid.pdf (cached copy).

Das Audit wurde von Radically Open Security geleitet, die naturgemäß Partner von F-Droid sind, da sie den Schwerpunkt auf freie Software und offene Prozesse mit uns teilen. Dank gebührt Open Tech Fund für die Auditorensuche und die Übernahme deren Kosten.

Weitere Informationen über F-Droid’s Schutzvorkehrungen, finden Sie in der Dokumentation unter Sicherheitsmodell.

Abbau von Vertrauensanforderungen

Ein entscheidender Bestandteil dieses Audits war, uns neuerlich dazu zu drängen, das notwendige Maß an Vertrauen in die verschiedenen Teile und Teilnehmer bei allen Vorgängen in F-Droid zu reduzieren. Client-/Serversysteme sind für gewöhnlich auf der Annahme aufgebaut, dass der Serverbetreiber absolut vertrauenswürdig ist. Es gibt viele vertrauenswürdige Mitwirkende, die an F-Droid arbeiten, und die Leute, die an den Kernbestandteilen arbeiten, bringen eine lange und gute Erfolgs- und Erfahrungsgeschichte mit. Nichtsdestotrotz ist es von hohem Wert, ein System zu haben, das nicht auf vertrauenswürdige Menschen und ihre Computer angewiesen ist. Unser Ziel ist es, alle Teile des F-Droid-Ökosystems so voranzubringen, dass sie nach dem Principle of Least Privilege arbeiten.

Neue Apps und Updates werden über Merge-Requests und git-Commits an fdroiddata übermittelt. Diese Änderungen werden dann für immer im git-Verlauf gespeichert. In der Vergangenheit verließ sich der Code auf alles in fdroiddata, da die Commits von Menschen nach jedem bösartigen Bit durchsucht werden. Dieses Modell hat eine sehr gute Erfolgsgeschichte in F-Droid wie auch in vielen anderen, von vielen Leuten in der Open-Szene entwickelten Projekten. Debian ist ein wunderbares Beispiel dafür, da fast ein tausend Debian-Entwickler Commit-Privilegien besitzen, die ihnen Root auf jedem Rechner, auf dem Debian läuft, geben konnten.

Dieses Audit half uns bei der Fragestellung: Welche Art Privilegien können beschränkt oder entfernt werden, ohne dabei die Arbeitsweise der Mitwirkenden zu verändern? Es erfasste auch eine Anzahl von Problemen, inwiefern der Code sich auf die Einträge in fdroiddata verließ, inwiefern er von Menschenhand committed und überprüft worden war, dann aber doch auf anderen Code verweisen konnte, der Exploits enthalten könnte.

Eine Reduktion des Vertrauens, das diversen Teilen geschenkt wird, reduziert den Druck bei der Mitarbeit, und erlaubt uns als Gemeinschaft, allen Arten von Mitarbeitern weitere Sachen zu öffnen. Wenn ein Mitwirkender fühlt, dass seine Prüfung die letzte Verteidigungslinie gegen die Ausnutzung von F-Froid darstellt, bringt das eine große Belastung bei der Prüfung mit sich.

Rechteerweiterung

Im Code der Rechteerweiterung oder bei der Zusammenarbeit von F-Droid-Client und Rechteerweiterung wurden keine Probleme festgestellt.

F-Droid Kern

Diese Erkenntnis weist eine Standardpraxis in Android als unsicher aus: “Es ist möglich, auf einem Gerät ein SSL-Zertifikat zu installieren und die Anwendung auszuführen, um deren Datenverkehr auf dem Proxy zu erfassen.” Android macht es nicht einfach, versehentlich ein Zertifikat auf dem Gerät zu integrieren, und es stellt auch eine dauerhafte Benachrichtigung auf, wenn eines vorhanden ist. Wir glauben, dass das Befolgen dieser Empfehlung die Sicherheit im wirklichen Leben nicht nennenswert verbessern würde. Es würde legitime Anwendungsfälle der Zertifikatinstallation zur Beobachtung des Datenverkehrs auf einem Gerät ausschließen. Zum Beispiel: Firmen-Firewalls, die den Datenverkehr beobachten müssen, um den Vorschriften nachzukommen; oder Prüfung des realen Verkehrs von F-Droid im normalen Betrieb.

Das kann nur dazu ausgenutzt werden, um die URL zu ändern, die dem Anwender in der TOFU-Abfrage angezeigt wird. Der Anwender trägt bei Bestätigung die Verantwortung dafür, was in dieser Abfrage gelistet ist. Es sollte behoben werden, erscheint aber nicht als dringend. Es wird engeschlossen werden, wenn wir den ganzen “App Repo”-Prozess überarbeiten.

Das ist ein Android-immanentes Problem. Wenn eine APK with SHA256 signiert ist, wird diese APK auf Android vor 4.3 nicht funktionieren. Die Verwendung eines größeren RSA-Signierschlüssels wäre ebenfalls ideal. Da aber das Migrieren von Signierschlüsseln in Android nicht unterstützt wird, wäre das ein sehr schwieriges Projekt. F-Droid enthält weitere Schutzvorkehrungen zur Validierung von APKs, einschließlich GPG-Signaturen für APKs, neben dem insgesamt sicheren F-Droid-Verteilungsmechanismus.

Die HTTPS-Pinning-Einrichtung könnte definitiv verbessert werden. Da HTTPS-Pinning nicht essentiell ist, um den Vorgang abzusichern, erlangte es nie eine hohe Priorität. Die Integrität des Dateiservers bleibt durch die Signatur in der Indexdatei geschützt. In f-droid.org und dem Guardian Project Repo, sind die Schlüssel zum Abgleich dieser Signaturen im Client eingebaut.

Nah/Tausch

4.1.10 OTF-010 stellte ein ernsthaftes Problem dar, das dank Radically Open Security’s offenen Auditverfahrens, sobald es bekannt wurde, behoben wurde. Es machte es möglich, Phishing-Anzeigen über den Tauschvorgang unterzubringen, konnte aber nur im selben Netz ausgenutzt werden, in dem sich das Zielgerät befindet.

Die Sicherheit des Nahtauschs baut größtenteils auf dem begrenzten Angriffsspielraum auf, da er nur über Bluetooth oder ein örtliches, auf das aktuelle Subnetz beschränktes WLAN funktioniert. Er ist zudem nur für eine sehr begrenzte Zeit aktiv, während der Benutzer ihn unmittelbar durchführt. Dann wird, der Dateiintegrität wegen, dem Index-Signierschlüssel bei der ersten Nutzung vertraut, danach werden alle Dateien gegen den verifizierten Index abgeglichen. Auch wenn die Sicherheit dieses Vorgangs noch verbessert werden kann, wurde er entwickelt, um viel unsicherere, weit verbreitete Methoden zu ersetzen.

Idealerweise würden alle Bluetooth-Verbindungen die native Bluetooth-Verschlüsselung und alle IP-Verbindungen HTTPS verwenden. Die Bedienungsprobleme, die mit einer Ergänzung, die dies unterstützt, verbunden wären, würden wahrscheinlich die Nahtausch-Funktion, ohne einen beträchtlichen Brocken Arbeit, nahezu unbrauchbar machen.

fdroidserver

Auf dem Weg zu den niedrigsten Berechtigungen

Die Build-Metadatendateien werden verwendet, um eine App und ihren Build-Prozess zu beschreiben. Sie werden in der Regel von vertrauenswürdigen Parteien (z.B. der Person, die den Repo laufen lässt) erstellt oder durch Merge-Anfragen überprüft. Diese Ergebnisse hätten nur bei Repos Probleme verursacht, die Metadatendateien aus nicht vertrauenswürdigen Quellen enthalten, ohne sie zu überprüfen. Für f-droid.org können die Metadatendateien nur über Git-Commits in fdroiddata auf die Produktionsserver heruntergeladen werden. In der Git-Historie wurden keine Versuche unternommen, diese auszunutzen und es wurden keine Merge-Requests gestellt. Die meisten dieser Probleme betreffen nur den Erstellungsprozess der App, z.B. fdroid build. Repos aus binären APKs und fdroid update wären nur von 4.1.3 OTF-003 betroffen.

Beseitigung von Schwachstellen, die zu Exploits verkettet werden könnten

Die verwendeten Datenformate ermöglichen die Codeausführung aus serialisiertem Code. Die Build-Metadatendateien werden nun mit deaktivierter Codeserialisierung geladen, die apkcache-Datei wurde von pickle auf JSON umgestellt und wir werden die config.py-Datei auf YAML mit sicherem Laden umstellen.

Denial-of-Service

Es wurden einige Probleme gefunden, die es Mitwirkenden mit vertrauenswürdigem Zugriff ermöglichen, Teile des Systems vom Arbeiten auszuschließen.

Experimentelle Drozer-Integration

Als Teil der Bazaar2-Förderung, wurde ein experimentelles Feature zur Integration von Drozer in das F-Droid-Projekt programmiert. Dieses Feature befindet sich immer noch im Alpha-Stadium und kommt in keiner Produktionseinrichtung zur Anwendung. Diese Angelegenheiten sind echte Probleme, aber es gibt derzeit keine Pläne, sie zu lösen, da es keine Pläne gibt, die Drozer-Integration weiter voranzutreiben. Wir begrüßen Beiträge von denjenigen, die gerne sähen, dass das geschieht.

f-droid.org-Internetseite

Die Verschiebung der gesamten Internetseite von Wordpress auf eine statisch generierte Site zahlte sich durch eine hohe Sicherheitsdividende aus, es wurden keine bearbeitungsbedürftigen Probleme auf der Internetseite gefunden. Auch wenn beide Befunde dahingehend richtig sind, dass böswilliges JavaScript in die Beschreibungen einfließen könnte, lassen weder die f-droid.org-Internetseite noch der Android-Client eine Ausführung von JavaScript aus den Beschreibungen heraus zu. Die f-droid.org-Website schützt sich gegen eine heimtückische JavaScript-Einschleußung durch eine strenge Sicherheitsrichtlinie für HTTP-Inhalte. Der F-Droid-Client führt niemals CSS, JavaScript, oder gefährliche HTML-Tags aus, da er das HTML über Html.fromHtml() anzeigt, bei der das Laden von Bildern deaktiviert ist.

Im Idealfall enthielte der Index-Erzeugungsprozess in fdroid update robuste CSS/HTML/Javascript-Prüfungen, damit eine böswillige Einschleußung sowohl durch die Index-Lieferanten wie auch die Konsumenten verhindert wird. Dies würde zu einer Stärkung der “Herdenimmunität” führen, für jeden, der mit Daten arbeitet, die durch Verwendung irgendeines F-Droid-Tools erzeugt wurden.

Die Verknüpfungen werden nur im “Links”-Abschnitt angezeigt. Nachdem eine Überprüfung jener URLs von Menschenhand stattfindet und diese URLs Commits in git sind, ließen wir sie ohne Absicherung geöffnet. Es gibt darüberhinaus weitere URLs, wie die Homepage, Issue Tracker usw. Ich glaube, wir sollten die komplette URL auf der Benutzeroberfläche einblenden, wenn sie nicht geläufigen Mustern folgt. Auch Google Play enthält einen Link zu einer Internetseite, die der Autor einer App anbietet.

Ein Verbesserungsvorschlag dazu wäre ein Scan dieser URLs mittels der Google Safe Browsing API.

Repomaker

Repomaker ist ein Web-Tool, das es wirklich leicht macht, eigene F-Droid-Repositories einzurichten. Es ist ein neues Projekt, das immer noch als eine Beta-Version angesehen werden sollte. Es gab ein Problem mit hohem Gewicht, (CVE-2018-7753) wurde in einer Upstream-Bibliothek gefunden, Mozilla’s bleach. Es wurde Mozilla mitgeteilt und umgehend korrigiert. Es gab drei weitere mit geringen Auswirkungen, die behoben sind.

Befunde, die nicht relevant oder zu kleinlich sind

Dies sind Probleme, die zwar technisch gesehen zutreffend aber im Kontext, wie F-Droid den Code verwendet, irrelevant sind.

Der BluetoothServer wird einzig und allein dazu genutzt, Dateien an die Bluetooth-Verarbeitung des F-Droid-Clients zu liefern, was mit einem Browser nichts zu tun hat. Er führt definitiv kein HTML/CSS/Javascript aus und zeigt keine Webseiten an. Ohne eigens in ihm erstellten Code, der diese Informationen empfängt, wäre es niemals möglich, sie in einem Browser anzuzeigen.

Der Download-Vorgang lädt nur Dateien in ein privates Verzeichnis herunter. Die Dateivalidierung geschieht während des Installationsvorgangs für alle Dateien. Nach dem Download gleicht der Installationsprozess den SHA-256 gegenüber dem im signierten Dateiindex ab.

Dieser Code wird nur verwendet, um JAR-Signaturen auf der index.jar für den Nearby/Swap-Prozess zu erstellen. Android schützt kritische Dateien durch Dateiberechtigungen vor dem Löschen. Nur die Datei index.jar wird überhaupt vom Zipsigner-Code behandelt.

Der eingebaute Webserver von NanoHTTPD wird immer nur für öffentliche Informationen verwendet. Außerdem werden die Teile des Codes in der NanoHTTPD-Bibliothek, die temporäre Dateien erstellen, wahrscheinlich nie in F-Droid verwendet.

Verschleierung wird hier nicht als Sicherheitsmechanismus, sondern als leichtgewichtiger Anti-Piraterie-Mechanismus eingesetzt. Die verschleierten Informationen müssen letztendlich der App zur Verfügung stehen, um sie zu nutzen. So würde es immer einen Weg geben, die verdeckten Informationen zu extrahieren, wie wir es in den Jahrzehnten des Softwarekopierschutz-Wettrüstens gesehen haben.

Dateinamen in Java werden nicht von einer Shell ausgeführt. Nur das Zeichen / ist bei Dateisystemen und Dateibearbeitungscode problematisch. Im Idealfall würden alle von der F-Droid-Software erzeugten Dateien unabhängig davon, wo und wie sie verwendet werden, sicher sein, aber es scheint, dass der einzig mögliche Weg zur Desinfektion von Dateien auf den Endpunkten liegt, die die Dateien nutzen (z.B. fdroidclient oder f-droid.org).