4 ms·

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

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.

gruez 2y ago
>The only reason this didn't turn into a disaster was pure luck. Is it? Or is it a case of "It rather involved being on the other side of this airtight hatchway"[1]? The apk signature done by fdroidserver seems totally superfluous. Android is already going to verify the certificate if you try to update an app, and presumably whatever upload mechanism is already authenticated some other way (eg. api token or username/password), so it's unclear what the signature validation adds, aside from maybe preventing installation failures. [1] https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
- ncr100 2y ago
  > Android is already going to verify the certificate.. Will it if it's a non Google distro of Android?
  - mid-kid 2y ago
    yeah, you can't update an app with a different signature than the one you've currently installed, that's a feature of the OS.
  - gruez 2y ago
    The behavior is in AOSP, so it should be in "non Google distro of Android" as well, unless the manufacturer decided to specifically remove this feature.
- Nullabillity 2y ago
  > The apk signature done by fdroidserver seems totally superfluous. Android is already going to verify the certificate if you try to update an app, and presumably whatever upload mechanism is already authenticated some other way (eg. api token or username/password), so it's unclear what the signature validation adds, aside from maybe preventing installation failures. If you try to update the app. Anyone installing the app from scratch will still be vulnerable. Effectively, both cases are Trust On First Use, but AllowedAPKSigningKeys moves the First Use boundary from "the first time you install the app" to "the first time F-Droid saw the app". Izzy wrote a blog post about it a while ago.[0] > and presumably whatever upload mechanism is already authenticated some other way (eg. api token or username/password) IzzyOnDroid (and, I believe, F-Droid) don't have their own upload UI or authentication, they poll the upstream repo periodically. [0]: https://f-droid.org/2023/09/03/reproducible-builds-signing-keys-and-binary-repos.html https://f-droid.org/2023/09/03/reproducible-builds-signing-k...
  - gruez 2y ago
    >Effectively, both cases are Trust On First Use, but AllowedAPKSigningKeys moves the First Use boundary from "the first time you install the app" to "the first time F-Droid saw the app". 1. What you're describing would have to happen on the f-droid app, but the vulnerability seems to be on fdroidserver? 2. Even if this actually affected the f-droid app, what you described seems like a very modest increase in security. The attack this prevents (ie. a compromised server serving a backdoored apk with a different signature) would also raise all kinds of alarms from people who already have the app installed, so practically such an attack would be discovered relatively quickly. >IzzyOnDroid (and, I believe, F-Droid) don't have their own upload UI or authentication, they poll the upstream repo periodically. Doesn't f-droid perform the build themselves and sign the apk using their own keys? They might be pulling from the upstream repo, but that's in source form, and before apks are signed, so it's irrelevant.
    - Nullabillity 2y ago
      > 1. What you're describing would have to happen on the f-droid app, but the vulnerability seems to be on fdroidserver? As far as I understand (I'm not an expert on F-Droid), this validation happens on the server side. The (repo) server verifies that the signature matches that of the first version it saw, the phone (when installing the APK) verifies that the signature matches that of the first version it saw. Android keeps the fdroidserver honest for upgrades, fdroidserver provides an additional bootstrap point for Android's trust. > 2. Even if this actually affected the f-droid app, what you described seems like a very modest increase in security. The attack this prevents (ie. a compromised server serving a backdoored apk with a different signature) would also raise all kinds of alarms from people who already have the app installed, so practically such an attack would be discovered relatively quickly. Sure, it's the difference between "automated tooling sees the problem immediately and addresses it proactively" vs "hopefully someone will ring the alarm bell eventually". > Doesn't f-droid perform the build themselves and sign the apk using their own keys? They might be pulling from the upstream repo, but that's in source form, and before apks are signed, so it's irrelevant. According to the linked blog post, not anymore. Apparently, these days they serve the author's original APK, but after verifying that they can rebuild it (modulo the signature itself).
wkat4242 2y ago
Yeah that's the big benefit of F-Droid, reproducible builds. It builds directly from github. I like that aspect of it a lot, it adds a lot of security that other app stores don't have. But yeah other repos don't :(
FuturisticGoo 2y ago
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.
- deleted 2y ago
  [deleted]
- rollcat 2y ago
  > 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.
  - gruez 2y ago
    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.
    - deleted 2y ago
      [deleted]
NotPractical 2y ago
From what I can understand the attack scenario is as follows: 1. User downloads an app from F-Droid that supports reproducible builds. 2. The developer's account is compromised and submits an app with a different-than-expected signing key. 3. A new user installs the app (existing users aren't affected due to Android's enforcement of using the same signing key for updates). 4. This user is (external to the app) contacted by the attacker and directed to install an update to the app from them. The update contains malicious code. F-Droid's response is concerning but this attack scenario seems pretty unlikely to work in practice.

gruez 2y ago

>The only reason this didn't turn into a disaster was pure luck. Is it? Or is it a case of "It rather involved being on the other side of this airtight hatchway"[1]? The apk signature done by fdroidserver seems totally superfluous. Android is already going to verify the certificate if you try to update an app, and presumably whatever upload mechanism is already authenticated some other way (eg. api token or username/password), so it's unclear what the signature validation adds, aside from maybe preventing installation failures. [1] https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...

ncr100 2y ago
> Android is already going to verify the certificate.. Will it if it's a non Google distro of Android?
- mid-kid 2y ago
  yeah, you can't update an app with a different signature than the one you've currently installed, that's a feature of the OS.
- gruez 2y ago
  The behavior is in AOSP, so it should be in "non Google distro of Android" as well, unless the manufacturer decided to specifically remove this feature.
Nullabillity 2y ago
> The apk signature done by fdroidserver seems totally superfluous. Android is already going to verify the certificate if you try to update an app, and presumably whatever upload mechanism is already authenticated some other way (eg. api token or username/password), so it's unclear what the signature validation adds, aside from maybe preventing installation failures. If you try to update the app. Anyone installing the app from scratch will still be vulnerable. Effectively, both cases are Trust On First Use, but AllowedAPKSigningKeys moves the First Use boundary from "the first time you install the app" to "the first time F-Droid saw the app". Izzy wrote a blog post about it a while ago.[0] > and presumably whatever upload mechanism is already authenticated some other way (eg. api token or username/password) IzzyOnDroid (and, I believe, F-Droid) don't have their own upload UI or authentication, they poll the upstream repo periodically. [0]: https://f-droid.org/2023/09/03/reproducible-builds-signing-keys-and-binary-repos.html https://f-droid.org/2023/09/03/reproducible-builds-signing-k...
- gruez 2y ago
  >Effectively, both cases are Trust On First Use, but AllowedAPKSigningKeys moves the First Use boundary from "the first time you install the app" to "the first time F-Droid saw the app". 1. What you're describing would have to happen on the f-droid app, but the vulnerability seems to be on fdroidserver? 2. Even if this actually affected the f-droid app, what you described seems like a very modest increase in security. The attack this prevents (ie. a compromised server serving a backdoored apk with a different signature) would also raise all kinds of alarms from people who already have the app installed, so practically such an attack would be discovered relatively quickly. >IzzyOnDroid (and, I believe, F-Droid) don't have their own upload UI or authentication, they poll the upstream repo periodically. Doesn't f-droid perform the build themselves and sign the apk using their own keys? They might be pulling from the upstream repo, but that's in source form, and before apks are signed, so it's irrelevant.
  - Nullabillity 2y ago
    > 1. What you're describing would have to happen on the f-droid app, but the vulnerability seems to be on fdroidserver? As far as I understand (I'm not an expert on F-Droid), this validation happens on the server side. The (repo) server verifies that the signature matches that of the first version it saw, the phone (when installing the APK) verifies that the signature matches that of the first version it saw. Android keeps the fdroidserver honest for upgrades, fdroidserver provides an additional bootstrap point for Android's trust. > 2. Even if this actually affected the f-droid app, what you described seems like a very modest increase in security. The attack this prevents (ie. a compromised server serving a backdoored apk with a different signature) would also raise all kinds of alarms from people who already have the app installed, so practically such an attack would be discovered relatively quickly. Sure, it's the difference between "automated tooling sees the problem immediately and addresses it proactively" vs "hopefully someone will ring the alarm bell eventually". > Doesn't f-droid perform the build themselves and sign the apk using their own keys? They might be pulling from the upstream repo, but that's in source form, and before apks are signed, so it's irrelevant. According to the linked blog post, not anymore. Apparently, these days they serve the author's original APK, but after verifying that they can rebuild it (modulo the signature itself).

wkat4242 2y ago

Yeah that's the big benefit of F-Droid, reproducible builds. It builds directly from github. I like that aspect of it a lot, it adds a lot of security that other app stores don't have. But yeah other repos don't :(

FuturisticGoo 2y ago

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.

deleted 2y ago
[deleted]
rollcat 2y ago
> 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.
- gruez 2y ago
  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.
  - deleted 2y ago
    [deleted]

NotPractical 2y ago

From what I can understand the attack scenario is as follows: 1. User downloads an app from F-Droid that supports reproducible builds. 2. The developer's account is compromised and submits an app with a different-than-expected signing key. 3. A new user installs the app (existing users aren't affected due to Android's enforcement of using the same signing key for updates). 4. This user is (external to the app) contacted by the attacker and directed to install an update to the app from them. The update contains malicious code. F-Droid's response is concerning but this attack scenario seems pretty unlikely to work in practice.