Beim Lesen des zugehörigen Issues zur Signaturproblematik bei F-Droid habe ich den Eindruck, dass das Problem dort entweder nicht verstanden oder heruntergespielt wird. Das ist besorgniserregend. :think_bread:
https://gitlab.com/fdroid/fdroidserver/-/merge_requests/1466
#fdroid #android #security #sicherheit #poc
@kuketzblog@social.tchncs.de was wäre deine Empfehlung? Fdroid vom Handy löschen bis es gefixt ist?
Finde ich trotzdem heftig:
Trotz angebotener Hilfe (Patches auf dem Silbertablett) wird in alter Manier “verschlimmbessert”.Stellt den Ansatz von open source auch irgendwie in Frage.
Hin und wieder sollte man doch über seinen Schatten springen.Die Lösung des Problems kurz skizziert: Eine gründliche Überarbeitung der Zertifikatsprüfung bei F-Droid, einschließlich der Einführung von Standards zur Prüfung aller Signaturblöcke (auch unbekannter) und einer korrekten Validierung von v1-Zertifikaten.
Zitat: […] Especially it does not affect the repository on f-droid.org to our knowledge.
Natürlich tut es das. F-Droid signiert zwar selbst, übernimmt aber bei reproduzierbaren Builds die APKs inkl. Signatur der Entwickler. Fehlerhafte Signaturprüfungen können dazu führen, dass manipulierte oder unsichere APKs akzeptiert werden.
Edit: “bei reproduzierbaren Builds” hinzugefügt.
@kuketzblog@social.tchncs.de mmh, ich dachte immer F-Droid hat einen eigenen build step für die apps im f-droid.org repository und übernimmt gerade nicht die APKs der Entwickler
deleted by creator
@marcelklehr @kuketzblog So war mein Verständnis auch. Ich dachte der Entwickler kann nur Code hochladen. Anderseits wieviele Buildsysteme muss dann F-Droid anbieten? Gibt ja zig Möglichkeiten mit was man für Android Apps entwickelt.
@stefanjahn @marcelklehr @kuketzblog
In den Metadaten zu einem F-Droid-Repository kann ein öffentlicher Schlüssel hinterlegt werden, sodass auf dem Server nur noch .apk für eine bestimmte App akzeptiert werden, die mit diesem Schlüssel signiert sind.
Diese Signaturprüfung hat aktuell Fehler, die unter Umständen dazu führen könnte, dass in einem F-Droid repository .apk mit Signaturen sind, die dort laut Metadaten nicht sein dürfen.
@stefanjahn @marcelklehr @kuketzblog
Das offizielle F-Droid repository benutzt diese Funktion auch in ihren Metadaten um bei reproduzierbar gebauten .apk die Signatur des ursprünglichen Entwicklers zu erzwingen. Allerdings werden wie bereits erwähnt, alle .apk die im F-Droid repository sind, auf dem Server von F-Droid gebaut und dann entweder eine eigene Signatur, oder im Falle reproduzierbaren .apk die Signatur der Original-App angehängt.
@stefanjahn @marcelklehr @kuketzblog
Der schlimmstmögliche Angriff auf dem offiziellen F-Droid-Repository ist also nicht, wie von @kuketzblog behauptet, dass eine “manipulierte oder unsichere” .apk im offiziellen F-Droid repository landet, sondern nur, dass eine kaputte oder falsche Signatur an die reproduzierbar gebaute .apk angehängt wird.
@stefanjahn @marcelklehr @kuketzblog
Das führt im schlimmsten Fall dazu, dass der Publisher einer App (der erst eine entsprechend präparierte .apk mit kaputter Signatur veröffentlichen muss) damit erreichen kann, dass Updates seiner eigenen App im F-Droid kaputte Signaturen haben und diese durch den Nutzer nicht mehr installierbar sind.
Und ich bin mir nicht mal sicher, ob dieser Angriff überhaupt möglich ist, gegeben wie der Buildserver die Signatur kopiert.
@pixelschubsi @stefanjahn @marcelklehr @kuketzblog
“und diese durch den Nutzer nicht mehr installierbar sind.”
Auch nicht ganz korrekt. Wenn die App bereits auf dem Gerät installiert ist, würde ein Update wohl fehlschlagen. Eine Neuinstallation würde aber (nach meinem Verständnis) nach wie vor funktionieren.
@stefanjahn @marcelklehr @kuketzblog
Theoretisch könnte man sich auch noch ein Szenario ausdenken, wo der Publisher einer App in der kaputten Signatur Schadcode einbettet und in dem reproduzierbar gebauten open source code seiner app Logik hat, die den Schadcode aus der Signatur sucht und ausführt. Da gibt es aber verschiedene Gründe die diesen “Angriff” nahezu unmöglich machen (Länge der Signatur, Einschränkungen in Android welcher Code ausführbar ist, usw.)
@kuketzblog@social.tchncs.de Das geht nicht nur dir so
