zlacker

[return to "F-Droid Fake Signer PoC"]
1. kuschk+X8[view] [source] 2025-01-04 00:07:27
>>pabs3+(OP)
While none of that applies to F-Droids primary use case (the primary F-Droid repo builds all apps from source itself), it nonetheless looks like they failed to correctly handle the issue.

The only reason this didn't turn into a disaster was pure luck.

◧◩
2. Futuri+Jt[view] [source] 2025-01-04 03:37:27
>>kuschk+X8
The primary F-droid repo also hosts the app developer builds in case of reproducible builds, where F-droid will first build from source and then compare it with the dev's build. If its identical, it uses the dev build in the repo and if its not, the build fails.

The use of AllowedAPKSigningKeys afaik is to compare that key with the key used for signing the dev build. If its not the same, the dev build is rejected.

From what I've understood from this POC, its possible to bypass this signature check. The only exploit I can think of with this bypass is that someone who gets access to the developer's release channel can host their own signed apk, which will either get rejected by Android in case of update (signature mismatch) or gets installed in case of first install. But in either case, its still the same reproducible build, only the signature is different.

◧◩◪
3. rollca+Uc1[view] [source] 2025-01-04 14:44:42
>>Futuri+Jt
> The only exploit I can think of with this bypass is that someone who gets access to the developer's release channel can host their own signed apk, which [...] gets installed in case of first install.

That still enables a supply chain attack, which should not be dismissed - virtually all modern targeted attacks involve some complex chain of exploits; a sufficiently motivated attacker will use this.

◧◩◪◨
4. gruez+zh1[view] [source] 2025-01-04 15:24:11
>>rollca+Uc1
You missed the later part of the quote:

>But in either case, its still the same reproducible build, only the signature is different.

That means the attacker still has to compromise the source repo. If they don't and try to upload a backdoored apk, that would cause a mismatch with the reproducible build and be rejected. If you can compromise the source repo, you're already screwed regardless. Apk signature checks can't protect you against that.

◧◩◪◨⬒
5. hnacco+Yu1[view] [source] 2025-01-04 17:17:29
>>gruez+zh1
In a previous post you said that - in case of matching builds - the dev's version is used. Why is the "dev's" version relevant? And assuming I'm correct that it isn't. What is the added benefit vs. just building from source (from a known good state, e.g. by a blessed git hash)?
◧◩◪◨⬒⬓
6. gruez+bw1[view] [source] 2025-01-04 17:27:42
>>hnacco+Yu1
>In a previous post you said that - in case of matching builds - the dev's version is used

Which post are you talking about? >>42592150 was made by FuturisticGoo, not me.

Also, the wording on f-droid suggests the version that f-droid hosts is built by them, rather than a version that's uploaded by the dev. If you go on any app and check the download section, it says

> It is built by F-Droid and guaranteed to correspond to this source tarball.

[go to top]