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
@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”
@pixelschubsi @IzzyOnDroid @stefanjahn @marcelklehr Hier werden einige Dinge absichtlich oder unabsichtlich durcheinander geworfen - mal schauen, ob ich das nochmal in einem Artikel beleuchte.
@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.