this post was submitted on 06 Jan 2025
1 points (100.0% liked)
Android
0 readers
1 users here now
Android news, reviews, tips, and discussions about rooting, tutorials, and apps.
General discussion about devices is welcome. Please direct technical support, upgrade questions, buy/sell, app recommendations, and carrier-related issues to other communities.
Rules
Rules
- Stay on topic: All posts should be related to the Android operating system or ecosystem.
- No support questions/rants/bug reports: All posts should benefit the community rather than the individual. Please refrain from posting individual support questions, rants, or bug reports.
- Describe images/videos: Please provide an explanation in the self-post body when sharing images or videos. Memes are not allowed.
- No self-promotional spam: Only active members of the community can post their apps, and they must participate in comments. Please do not post your own website, YouTube, or blog.
- No reposts/rehosted content: Submit original sources whenever possible, unless the content is not available in English. Reposts about the same content are not allowed.
- No editorializing titles: Do not change article titles when submitting. You may add the author if relevant.
- No piracy: Do not share or discuss pirated content.
- No unauthorized polls/bots/giveaways: Do not create unauthorized polls, use bots, or organize giveaways without proper authorization.
- No offensive/low-effort content: Avoid posting offensive or low-effort content that does not contribute positively to the community.
- No affiliate links: Posting affiliate links is not allowed.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
@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.)
@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...
@[email protected] @[email protected] @[email protected] Ich nehme bisher kein »Draufhauen« wahr, sondern dass eine gemeldete Lücke nicht geschlossen/behoben wird, obwohl lange bekannt.
@[email protected] @[email protected] @[email protected] 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
@[email protected] @[email protected] @[email protected] 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".
@[email protected] @[email protected] @[email protected] Ich interpretiere das anders: "Instead of adopting the fixes we proposed, F-Droid wrote and merged their own patch [10], ignoring repeated warnings it had significant flaws (including an incorrect implementation of v1 signature verification and making it impossible to have APKs with rotated keys in a repository). [...]
@[email protected] @[email protected] @[email protected] 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.