5 ms·

F-Droid Fake Signer PoC

234 points by pabs3 2y ago

CountHackulus 2y ago
Guess I'm immediately uninstalling F-Droid. That chain of events looks really poor for them.
- Larrikin 2y ago
  And using what instead?
  - donio 2y ago
    Not the parent and I will continue to use F-Droid but Obtanium is a popular alternative. It allows you to install apks directly from various supported sources (forges, F-Droid repos etc) so you typically use the apk that the app maintainer has produced in their CI pipeline rather than F-Droid's reproducible builds.
    - notpushkin 2y ago
      F-Droid would likely get APKs from the same place (if reproducible builds are on for the app in question). If this attack is implemented successfully, then that place was compromised as well, and Obtainium can’t do much here to detect that I’m afraid. Edit: on second thought, they could pin certificate hashes like F-Droid does on the build server, but verify them client-side instead. If implemented correctly this could indeed work. However, I think F-Droid with reproducible builds is still a safer bet, as attacker would have to get write access to source repo as well and hide their malicious code so that F-Droid can build and verify it.
  - CountHackulus 2y ago
    Nothing. I'll sideload what I need to. I didn't find it that useful.
    - yjftsjthsd-h 2y ago
      Okay, but sideloading is worse? AFAICT the problem we're discussing was in F-Droid doing extra verification (somewhat incorrectly, apparently) of an APK before handing it to Android to install. Regardless of F-Droid, Android will check signatures on updates against the installed version. So your response to F-Droid imperfectly checking signatures as an extra verification on first install... is to skip that entirely and do zero verification on first install? That's strictly worse for your security.
    - wobfan 2y ago
      Sideloading sounds like a massively worse option than using F-Droid even with this flaw. Humans are way more likely in making mistakes, and you lose a lot of safeguards in between you and the APK when you sideload. Also, you don’t get updates as fast, which is a whole problem in itself. So, IMO we should not fall into that trap of immediately removing apps that had a security flaw and falling back to a way worse alternative (which sideloading is) instead.
  - udev4096 2y ago
    Closest you'll get is Aurora Store if you don't want to give in to play store
Retr0id 2y ago
What's the practical impact?
- udev4096 2y ago
  A malicious app can bypass the certificate pinning feature to install the app. More info: https://gitlab.com/fdroid/fdroidserver/-/issues/1128 https://gitlab.com/fdroid/fdroidserver/-/issues/1128
kuschku 2y ago
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...
mrayycombi 2y ago
Great work.
deleted 2y ago
[deleted]
mappu 2y ago
Is it as bad as they're making it out to be? The fdroidserver get_first_signer_certificate can give a different result to apksigner, but then fdroidserver calls apksigner anyway for verification, and F-Droid mitigates the issue in various other ways. I think F-Droid were acting in the right up to that point; and then the latest update (regex newlines) is 0day? Has there been a response from F-Droid about the updates?
- KennyBlanken 2y ago
  Well, this is pretty concerning all on its own: > 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). This concerns me more than the vulnerabilities themselves. It's a pretty serious failure in leadership and shows that F-Droid is still driven by egos, not sound software engineering practices and a genuine interest in doing right for the community. F-Droid has numerous issues: * glacially slow to release updates even when security patches are released * not enforcing 2FA for developer accounts * no automatic vulnerability or malware scanning ...and more problems: https://privsec.dev/posts/android/f-droid-security-issues/ https://privsec.dev/posts/android/f-droid-security-issues/
bsimpson 2y ago
Tangential, but: I often wonder how secure these open source projects actually are. I'm curious about using Waydroid in SteamOS, but it looks like it only runs LineageOS (apparently a derivative of CyanogenMod). I know that people claim that open source is more secure because anyone can audit it, but I wonder how closely its security actually interrogated. Seems like it could be a massive instance of the bystander effect. All of it gives me a bias towards using official sources from companies like Apple and Google, who presumably hire the talent and institute the processes to do things right. And in any case, having years/decades of popularity is its own form of security. You know anyone who cares has already taken shots at Android and iOS, and they're still standing.
- mid-kid 2y ago
  Google isn't gonna build a ROM for waydroid so someone's going to have to make a build of Android, whom you'll have to trust. Google doesn't build ROMs for anything but their own phones. LineageOS is popular in this field because in essence it's a derivative of AOSP (the Android project as shipped by Google) with modest modifications to support a crapload of devices, instead of the handful that AOSP supports. This makes it easier to build and easier to support new platforms. The bulk of the security in AOSP (and thus, LineageOS) comes from all the mitigations that are already built into the system by Google, and the bulk of the core system that goes unmodified. The biggest issue is usually the kernel, which may go unpatched when the manufacturer abandons it (just like the rest of the manufacturer's ROM), and porting all the kernel modifications to newer versions is often incredibly tricky.
  - tredre3 2y ago
    > Google doesn't build ROMs for anything but their own phones. Are you suggesting that ROMs provided through Android Studio's emulator are somehow not built by Google?
- Dalewyn 2y ago
  >I know that people claim that open source is more secure because anyone can audit it, but I wonder how closely its security actually interrogated. The answer is that, no, nobody akshuarry audits anything. This has been proven time and time again, especially in the last few years. >All of it gives me a bias towards using official sources from companies like Apple and Google, who presumably hire the talent and institute the processes to do things right. What you get from commercial vendors is liability, you get to demand they take responsibility because you paid them cold hard cash. Free products have no such guarantees, you are your own liability.
panny 2y ago
I don't like people like this. They do the work of finding a bug, but rather than try to fix it, they grandstand and shout about how bad the thing they obviously enjoy is no good at all. If I find a vulnerability in code I enjoy, I work to fix it and then only after my ironclad fix is applied, do I mention that it existed and that I fixed it so it can never be exploited again. "Security researchers" IMO are the most cringe and worst examples of community members possible. They do not care about making things better, they only care about their own brand. Selling themselves, and climbing the ladder of embarrassed hard working people who do things for the love of doing.
- Idesmi 2y ago
  Hey. As someone who cries tears of joy when I see the software I support succeed, I share the sentiment. (I am just trying to push the visibility of your comment ;) )
- evujumenuk 2y ago
  Exactly. Ideally, we'd all follow the Benzite approach, which is to withhold any and all information from one's peers until a complete analysis has finished, and the best possible remedy to the problem has already been applied. Because how can a miscreant use a vulnerability if it hasn't even been published yet? As contributors, we enjoy a lot of trust, as we should. That's why it's not a problem if we make seemingly random changes that don't necessarily make a lot of sense, but seem relevant to security, when they actually fix an issue in the code. After all, it's necessary to prevent bad guys from gaining sensitive information, and to keep your colleagues from being unduly bothered with challenges they could possibly help with.
  - SAI_Peregrinus 2y ago
    Miscreants have a history of independently discovering vulnerabilities. Software vendors have a history of not fixing security issues. The current coordiated disclosure with a deadline forces vendors to fix their flaws while also allowing users to work around unfixed flaws.
- int_19h 2y ago
mschwaig 2y ago
I really wish we would take defining what it means for an artifact to be signed more seriously. Which key(s) is it signed with? What is the hash of the corresponding unsigned artifact? Signature verification tools should have some option which prints these things in a machine-readable format. I did some work on reproducibility of Android apps and system images with Nix, and while defining a build step which can automatically establish these relationships sounds a bit goofy, it can make the issues with underspecified edge cases visible by defining verification more strictly. I did not do this to look for those edge cases though. I am still working on that type of stuff now, but on more fundamental issues of trust we could start addressing with systems like Nix.
- 1oooqooq 2y ago
  blame browsers and the url padlock "cuz users are dumb" attitude. i still believe "pgp is too complex" was the most successful cia counter action after they lost the crypto wars to the people. solving via nix only works within the flawed assumptions that end users either fully trust google or fdroid and are incapable of anything else.
  - 486sx33 2y ago
    +1
  - rollcat 2y ago
    > "pgp is too complex" PGP is too complex. I've known my way around the command line before I learned how to hand-write, and I have to look up the commands to fetch the keys and/or verify the blob every single time. Keyservers regularly fail to respond. There's no desktop integration to speak of. The entire UX stinks of XKCD 196. Don't blame CIA for obvious deficiencies in usability.
    - Y_Y 2y ago
      I was with you right up until the end. I think the only thing that would stop me from sabotaging a small project like PGP (was in the early days) is moral aversion. FOSS and academic circles where these things originate is generally friendly and open, and there is plenty of money and length of rubber hose for anyone who doesn't welcome the mole into their project. I'm not saying I have evidence that this happened to PGP specifically, just that it doesn't seem at all implausible. If the CIA told me my code was never to get too easy to use, but otherwise I could live a long and happy life and maybe a couple of government contracts it would be hard to argue. Why a mass-market interface never took off (GPG and other descendants notwithstanding) may indicate that the whole cryptographic idea is inherently not amenable to user-friendliness, but I don't find that hypothesis as compelling. (It could also be an unlikely coincidence that there's a good solution not found for lack of looking, but that's even less plausible to me.)
throawayonthe 2y ago
[dead]
nathanmills 2y ago
Have they tried using Python 3.12? The regex engine is much more efficient now and could probably handle these certificate checks better. This also wouldn't be an issue if they just switched to Rust (memory safety solves these types of problems).

234 points by pabs3 2y ago

CountHackulus 2y ago

Guess I'm immediately uninstalling F-Droid. That chain of events looks really poor for them.

Larrikin 2y ago
And using what instead?
- donio 2y ago
  Not the parent and I will continue to use F-Droid but Obtanium is a popular alternative. It allows you to install apks directly from various supported sources (forges, F-Droid repos etc) so you typically use the apk that the app maintainer has produced in their CI pipeline rather than F-Droid's reproducible builds.
  - notpushkin 2y ago
    F-Droid would likely get APKs from the same place (if reproducible builds are on for the app in question). If this attack is implemented successfully, then that place was compromised as well, and Obtainium can’t do much here to detect that I’m afraid. Edit: on second thought, they could pin certificate hashes like F-Droid does on the build server, but verify them client-side instead. If implemented correctly this could indeed work. However, I think F-Droid with reproducible builds is still a safer bet, as attacker would have to get write access to source repo as well and hide their malicious code so that F-Droid can build and verify it.
- CountHackulus 2y ago
  Nothing. I'll sideload what I need to. I didn't find it that useful.
  - yjftsjthsd-h 2y ago
    Okay, but sideloading is worse? AFAICT the problem we're discussing was in F-Droid doing extra verification (somewhat incorrectly, apparently) of an APK before handing it to Android to install. Regardless of F-Droid, Android will check signatures on updates against the installed version. So your response to F-Droid imperfectly checking signatures as an extra verification on first install... is to skip that entirely and do zero verification on first install? That's strictly worse for your security.
  - wobfan 2y ago
    Sideloading sounds like a massively worse option than using F-Droid even with this flaw. Humans are way more likely in making mistakes, and you lose a lot of safeguards in between you and the APK when you sideload. Also, you don’t get updates as fast, which is a whole problem in itself. So, IMO we should not fall into that trap of immediately removing apps that had a security flaw and falling back to a way worse alternative (which sideloading is) instead.
- udev4096 2y ago
  Closest you'll get is Aurora Store if you don't want to give in to play store

Retr0id 2y ago

What's the practical impact?

udev4096 2y ago
A malicious app can bypass the certificate pinning feature to install the app. More info: https://gitlab.com/fdroid/fdroidserver/-/issues/1128 https://gitlab.com/fdroid/fdroidserver/-/issues/1128

kuschku 2y ago

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

mrayycombi 2y ago

Great work.

deleted 2y ago

[deleted]

mappu 2y ago

Is it as bad as they're making it out to be? The fdroidserver get_first_signer_certificate can give a different result to apksigner, but then fdroidserver calls apksigner anyway for verification, and F-Droid mitigates the issue in various other ways. I think F-Droid were acting in the right up to that point; and then the latest update (regex newlines) is 0day? Has there been a response from F-Droid about the updates?

KennyBlanken 2y ago
Well, this is pretty concerning all on its own: > 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). This concerns me more than the vulnerabilities themselves. It's a pretty serious failure in leadership and shows that F-Droid is still driven by egos, not sound software engineering practices and a genuine interest in doing right for the community. F-Droid has numerous issues: * glacially slow to release updates even when security patches are released * not enforcing 2FA for developer accounts * no automatic vulnerability or malware scanning ...and more problems: https://privsec.dev/posts/android/f-droid-security-issues/ https://privsec.dev/posts/android/f-droid-security-issues/

bsimpson 2y ago

Tangential, but: I often wonder how secure these open source projects actually are. I'm curious about using Waydroid in SteamOS, but it looks like it only runs LineageOS (apparently a derivative of CyanogenMod). I know that people claim that open source is more secure because anyone can audit it, but I wonder how closely its security actually interrogated. Seems like it could be a massive instance of the bystander effect. All of it gives me a bias towards using official sources from companies like Apple and Google, who presumably hire the talent and institute the processes to do things right. And in any case, having years/decades of popularity is its own form of security. You know anyone who cares has already taken shots at Android and iOS, and they're still standing.

mid-kid 2y ago
Google isn't gonna build a ROM for waydroid so someone's going to have to make a build of Android, whom you'll have to trust. Google doesn't build ROMs for anything but their own phones. LineageOS is popular in this field because in essence it's a derivative of AOSP (the Android project as shipped by Google) with modest modifications to support a crapload of devices, instead of the handful that AOSP supports. This makes it easier to build and easier to support new platforms. The bulk of the security in AOSP (and thus, LineageOS) comes from all the mitigations that are already built into the system by Google, and the bulk of the core system that goes unmodified. The biggest issue is usually the kernel, which may go unpatched when the manufacturer abandons it (just like the rest of the manufacturer's ROM), and porting all the kernel modifications to newer versions is often incredibly tricky.
- tredre3 2y ago
  > Google doesn't build ROMs for anything but their own phones. Are you suggesting that ROMs provided through Android Studio's emulator are somehow not built by Google?
Dalewyn 2y ago
>I know that people claim that open source is more secure because anyone can audit it, but I wonder how closely its security actually interrogated. The answer is that, no, nobody akshuarry audits anything. This has been proven time and time again, especially in the last few years. >All of it gives me a bias towards using official sources from companies like Apple and Google, who presumably hire the talent and institute the processes to do things right. What you get from commercial vendors is liability, you get to demand they take responsibility because you paid them cold hard cash. Free products have no such guarantees, you are your own liability.

panny 2y ago

I don't like people like this. They do the work of finding a bug, but rather than try to fix it, they grandstand and shout about how bad the thing they obviously enjoy is no good at all. If I find a vulnerability in code I enjoy, I work to fix it and then only after my ironclad fix is applied, do I mention that it existed and that I fixed it so it can never be exploited again. "Security researchers" IMO are the most cringe and worst examples of community members possible. They do not care about making things better, they only care about their own brand. Selling themselves, and climbing the ladder of embarrassed hard working people who do things for the love of doing.

Idesmi 2y ago
Hey. As someone who cries tears of joy when I see the software I support succeed, I share the sentiment. (I am just trying to push the visibility of your comment ;) )
evujumenuk 2y ago
Exactly. Ideally, we'd all follow the Benzite approach, which is to withhold any and all information from one's peers until a complete analysis has finished, and the best possible remedy to the problem has already been applied. Because how can a miscreant use a vulnerability if it hasn't even been published yet? As contributors, we enjoy a lot of trust, as we should. That's why it's not a problem if we make seemingly random changes that don't necessarily make a lot of sense, but seem relevant to security, when they actually fix an issue in the code. After all, it's necessary to prevent bad guys from gaining sensitive information, and to keep your colleagues from being unduly bothered with challenges they could possibly help with.
- SAI_Peregrinus 2y ago
  Miscreants have a history of independently discovering vulnerabilities. Software vendors have a history of not fixing security issues. The current coordiated disclosure with a deadline forces vendors to fix their flaws while also allowing users to work around unfixed flaws.
int_19h 2y ago

mschwaig 2y ago

I really wish we would take defining what it means for an artifact to be signed more seriously. Which key(s) is it signed with? What is the hash of the corresponding unsigned artifact? Signature verification tools should have some option which prints these things in a machine-readable format. I did some work on reproducibility of Android apps and system images with Nix, and while defining a build step which can automatically establish these relationships sounds a bit goofy, it can make the issues with underspecified edge cases visible by defining verification more strictly. I did not do this to look for those edge cases though. I am still working on that type of stuff now, but on more fundamental issues of trust we could start addressing with systems like Nix.

1oooqooq 2y ago
blame browsers and the url padlock "cuz users are dumb" attitude. i still believe "pgp is too complex" was the most successful cia counter action after they lost the crypto wars to the people. solving via nix only works within the flawed assumptions that end users either fully trust google or fdroid and are incapable of anything else.
- 486sx33 2y ago
  +1
- rollcat 2y ago
  > "pgp is too complex" PGP is too complex. I've known my way around the command line before I learned how to hand-write, and I have to look up the commands to fetch the keys and/or verify the blob every single time. Keyservers regularly fail to respond. There's no desktop integration to speak of. The entire UX stinks of XKCD 196. Don't blame CIA for obvious deficiencies in usability.
  - Y_Y 2y ago
    I was with you right up until the end. I think the only thing that would stop me from sabotaging a small project like PGP (was in the early days) is moral aversion. FOSS and academic circles where these things originate is generally friendly and open, and there is plenty of money and length of rubber hose for anyone who doesn't welcome the mole into their project. I'm not saying I have evidence that this happened to PGP specifically, just that it doesn't seem at all implausible. If the CIA told me my code was never to get too easy to use, but otherwise I could live a long and happy life and maybe a couple of government contracts it would be hard to argue. Why a mass-market interface never took off (GPG and other descendants notwithstanding) may indicate that the whole cryptographic idea is inherently not amenable to user-friendliness, but I don't find that hypothesis as compelling. (It could also be an unlikely coincidence that there's a good solution not found for lack of looking, but that's even less plausible to me.)

throawayonthe 2y ago

[dead]

nathanmills 2y ago

Have they tried using Python 3.12? The regex engine is much more efficient now and could probably handle these certificate checks better. This also wouldn't be an issue if they just switched to Rust (memory safety solves these types of problems).