Recent searches
Search options
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. 
https://gitlab.com/fdroid/fdroidserver/-/merge_requests/1466
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 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
@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.
@IzzyOnDroid @stefanjahn @marcelklehr @kuketzblog Das stimmt, ich hab ja auch "Updates" gesagt :) Wichtig ist und bleibt aber, dass nur der Original-Quellcode im F-Droid repository landet.
@pixelschubsi im F-Droid Repository landet die APK Datei 
Und das ist in diesem Fall die vom Entwickler. Der Quellcode selbst ist hier ja auch nicht das Problem (dafür wird ja auf RB geprüft) – es sind vielmehr die Signatur-Blöcke. Und die werden, wie Mike schon schrieb, nicht vollständig/korrekt geprüft. @stefanjahn @marcelklehr @kuketzblog
@IzzyOnDroid @stefanjahn @marcelklehr @kuketzblog Ja, aber kaputte Signatur-Blöcke haben halt keine Auswirkungen auf den ausgeführten Programmcode der Apps, wenn diese nicht im Quellcode schon Schadcode haben, der dynamisch Schadcode nachlädt. Die Signaturblöcke werden ja nicht einfach ausgeführt. Deswegen ist der maximale Impact hier eben, dass die App mit kaputten Signaturblöcken im Repository landet und deswegen Updates nicht mehr funktionieren.
@pixelschubsi lies den POC nochmal. In den Signaturblöcken kann man alles mögliche verstecken, und dann "anderweitig" zur Ausführung bringen. @stefanjahn @marcelklehr @kuketzblog
@IzzyOnDroid @stefanjahn @marcelklehr @kuketzblog Das gleiche gilt für alle anderen binaries die im Quellcode so rumfliegen, ich kann dir auch Schadcode in eine .png packen. Der Code der code aus Binärdateien oder Drittquellen ausliest und dynamisch zur Ausführung bringt ist IMO bereits Schadcode und sollte nie in F-Droid landen. Die Signaturblöcke sind zwar hier ein zusätzlicher Weg, aber eben bei weitem nicht der einzige um Schadcode auszuliefern, wenn Code dynamisch geladen wird.
@IzzyOnDroid @stefanjahn @marcelklehr @kuketzblog
Das Niveau auf dem wir uns hier bewegen ist nicht weit entfernt von:
"Kritische Sicherheitslücke in F-Droid: Wer einen Browser aus F-Droid installiert und dann damit auf eine Webseite geht, führt potentiell Schadcode (JavaScript) aus"
@kuketzblog@social.tchncs.de@pixelschubsi @IzzyOnDroid @stefanjahn @marcelklehr Hier werden einige Dinge absichtlich oder unabsichtlich durcheinander geworfen - mal schauen, ob ich das nochmal in einem Artikel beleuchte.
@kuketzblog @IzzyOnDroid @stefanjahn @marcelklehr Das klingt nach einer guten Idee. Frag doch dann am besten auch mal bei Hans nach und skizziere einen praktisch möglichen Angriff auf das F-Droid repository und erkläre inwiefern der nicht zuvor einen andere, schwerwiegenderen Angriff erfordert, statt nur so halbe Horrorstories.
@kuketzblog @IzzyOnDroid @stefanjahn @marcelklehr Die Debatte erinnert mich etwas an die Story mit microG's signature spoofing, wo auch am Anfang alle erzählt haben, dass das grauenvoll unsicher ist weil es Signaturen bricht - und 10 Jahre und Millionen Nutzer später ist immer noch kein praktisch umgesetzter Angriff darauf bekannt.
Ich könnte jetzt noch was von bestimmten egozentrischen Leuten mit Agenda erzählen, aber dann steht hier gleich eine Trollarmee auf der Matte.