Back

@marcelklehr @kuketzblog Das ist auch meine letzte Info.

@pixelschubsi @stefanjahn @marcelklehr Das ist der Worst-Case, ja. Daher: »Fehlerhafte Signaturprüfungen können dazu führen, dass manipulierte oder unsichere APKs akzeptiert werden.«

Das ist genau der von dir beschriebene Fall. Wie wahrscheinlich dieser ist, das ist schwierig abzuschätzen.

@kuketzblog @stefanjahn @marcelklehr 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...

@pixelschubsi @stefanjahn @marcelklehr Ich nehme bisher kein »Draufhauen« wahr, sondern dass eine gemeldete Lücke nicht geschlossen/behoben wird, obwohl lange bekannt.

@kuketzblog @stefanjahn @marcelklehr 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 @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.

@pixelschubsi @stefanjahn @marcelklehr Das wird hier aber anders dargestellt: https://github.com/obfusk/fdroid-fakesigner-poc?tab=readme-ov-file#update-2024-12-30-1

@kuketzblog @stefanjahn @marcelklehr 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 Ich persönlich sehe bei dieser Lücke auch tatsächlich aufgrund des geringen impacts auch keine Notwendigkeit eines aufwendigen responsible disclosure Prozesses. Deshalb soll das jetzt nicht als Vorwurf an den Finder verstanden werden - sondern am Rest der Community.

Und ja: Wenn etwas auf fefe steht, dann bedeutet das häufig eben "Ich will draufhauen und Popcorn" und nicht "das ist extrem wichtig für eure Sicherheit". fefe ist Hacker-Populismus, sonst nichts

@kuketzblog @stefanjahn @marcelklehr 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.

@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
Es ist IMO ein großes Problem in der Community, das so Kleinigkeiten gigantisch aufgeblasen werden (eine App die Schadcode enthält führt Schadcode aus, wenn sie es geschafft hat ihren Schadcode durchs F-Droid Review zu bekommen) und sich dann niemand für die wirklich großen Dinge interessiert (Signal enthält seit Jahren Schadcode der dynamisch weiteren Schadcode nachlädt wo niemand so genau weiß, was der eigentlich tut).

@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.

@evelineraine korrekt. Die APKs werden dann von den Releases bei Codeberg, GitLab, Github & Co genommen. @marcelklehr

@IzzyOnDroid @evelineraine @marcelklehr

Bist du dir da sicher? Wenn ich eine neue Version meiner App veröffentliche, dann "lade" ich nur die Apk-Signatur ohne Code hoch. Diese Signatur wird an die vom F-Droid-Server gebaute APK angefügt und geprüft.

Das klappt natürlich nur, wenn F-Droid und ich binär die gleichen APKs baue.

Siehe https://gitlab.com/fdroid/fdroiddata/-/merge_requests/15090/diffs

@Tobiwan Dann ist Deine App eine der wenigen, bei der diese (ältere) Variante zum Einsatz kommt. Das sind insgesamt 9 Apps, von insgesamt ca. 400 RB Apps. Also ja, ich bin sicher Zum Vergleich: Im *.yml Deiner App steht nichts von "binaries" oder "binary". Schau z.B. mal auf metadata/org.ecos.logic.flip_a_coin.yml – da steht, von wo die APK genommen wird.
@evelineraine @marcelklehr

@IzzyOnDroid @evelineraine @marcelklehr Achso. Danke für die Info

@SupportGrapheneOS_667 @kuketzblog @IzzyOnDroid

Das stellt den Ansatz nicht infrage. Es stellt die Einstellung der Personen infrage. Es sei denn, du meinst, dass die F-Droid-Leute sinnwidrig zu diesem Ansatz agieren

@Underfaker @kuketzblog @IzzyOnDroid

Ja, war unglücklich formuliert meinerseits.