@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”
@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 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.
@kuketzblog@social.tchncs.de @stefanjahn@freiburg.social @marcelklehr@fosstodon.org Naja, man muss dazu natürlich wissen, dass die “significant flaws” eben keine Sicherheitslücken sind; das wird ja auch nicht behauptet. Es werden halt technisch korrekte APKs als ungültig abgelehnt. Ist ein Problem, sollte man auch beheben, aber ist eben keine Sicherheitslücke.
@kuketzblog@social.tchncs.de @stefanjahn@freiburg.social @marcelklehr@fosstodon.org Nein, das wird da genauso dargestellt. Das ursprüngliche Problem wurde durch Änderungen, die die F-Droid-Entwickler selbst gemacht haben behoben, die patches des Entdeckers der Lücke wurden nicht genutzt. Bei den Änderungen von F-Droid selbst gab es bekannte Probleme, die aber keine Sicherheitslücken darstellten. Eine Sicherheitslücke darin wurde erst mit Datum 2024-12-30 gefunden und direkt veröffentlicht. Der Finder selbst sieht den impact aber “lower”.
@kuketzblog @stefanjahn @marcelklehr Interessant auch, dass keiner in der Community bemängelt, dass hier kein responsible disclosure zum Einsatz kam. Klar, muss man nicht, aber dann ist die Beschwerde, dass eine Lücke mit effektiv geringem Impact nicht in 7 Tagen über Neujahr gefixt wurde doch schon etwas abgehoben.
@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.
@kuketzblog@social.tchncs.de @stefanjahn@freiburg.social @marcelklehr@fosstodon.org du meinst seit ein Paar Tagen mit “lange”? Die ursprüngliche Lücke die letzten April gefunden wurde, wurde bereits letzten Mai geschlossen, es wurde nur vor ein Paar Tagen eine neue Lücke an ähnlicher Stelle im gleichen repository als “Update” veröffentlicht.
@kuketzblog@social.tchncs.de @stefanjahn@freiburg.social @marcelklehr@fosstodon.org Wie gesagt, für diesen Angriff müsste der Schadcode, der den Schadcode aus der Signatur nachlädt, bereits im Open-Source code der App sein. Wenn wir bereits Schadcode im Open-Source code der App annehmen, kann durch diese Lücke auch kein zusätzlicher Schaden entstehen.
Ich will nicht sagen, dass man diese Lücke nicht schließen sollte. Es ist aber ein Klassiker in der Community, bei einem sehr komplexen Thema wie diesem einfach ohne Verstand drauf zu hauen…
@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.)
@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.
@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 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
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.
@kuketzblog@social.tchncs.de
> Das Paradoxe an Systemen wie GrapheneOS ist, dass sie oft sicherer sind als die Standard-ROMs, die von Herstellern wie Google angeboten werden.
Uff. Das ist extrem subjektiv. Klassische Betriebssystem-Sicherheit ist bei ungefähr allen Android-basierten Systemen bereits extrem hoch (deutlich besser als was man so für Desktop nutzt). Inzwischen ist das auch kaum ein Problem, kritischer stattdessen ist Malware, die dem Nutzer sagt "gib mir Zugriff auf …
@kuketzblog@social.tchncs.de @IzzyOnDroid@floss.social @stefanjahn@freiburg.social @marcelklehr@fosstodon.org 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.