F-Droid vulnerability allows bypassing certificate pinning

baby_bat I feel the same way, I am really happy that I'm now aware of the many issues F-Droid has and I stopped using it altogether. I started using Obtainium for my app updates instead.
I had to replace almost all of my apps (because of the different signature) but is was well worth it; I feel more at ease and many apps are now updated alot quicker also, furthermore, there is no longer that additional middleman (F-Droid) that can be compromised.
Thanks for all of the info guys!

Dumdum

I do all updates manually. I don't like not controlling updates and have never understood people's obsessions with automatic updates.

I am very fond of having control over updates too! So much so I revoke network access from the GrapheneOS System updater until I'm ready to install the update since as of right now it automatically downloads the update which is undesirable for me. I don't want anything being downloaded until I'm sure I'm ready to install it in the first place.

I also mainly use RSS feeds for apps now. I use obtainium only to fill in the blanks where RSS feeds are not available. I of course still use AppVerifier before installing where applicable.

Honestly it's kind of nice seeing people with similar preferences on updates.

ParanoidAndroid So it is already reported (https://gitlab.com/fdroid/fdroidserver/-/merge_requests/1466#note_2281771672) that this issue would not significantly impact apps in the f-droid.org repo.

Thank you for this link. It answers the question I had, what the implications for this certificate pinning vulnerability is.

Actually, according to F-Droid developers looking into this security vulnerability, it does not affect the default F-Droid repository at all, as the vulnerable functionality isn't even being used. All APKs have also been scanned, as an extra precaution, no signs of any tampering. Some third-party repositories might be using the vulnerable functionality, so they are working on a fix with high priority.

It is still not clear to me where it is they are using certificate pinning or why, but that question is not so important to answer anymore, as they are doing it in some very specific optional and disabled by default configuration only, according to F-Droid developers.

ParanoidAndroid I always been thinking about the situation like this:

PlayStore: relatively high security but not always safe to install (there was malware in the past)

F-Droid: relatively low risk of installing malware if build by F-Droid and you need to trust the dev if the build is reproducible - risk of signature pinning but this would not affect already installed apps right?

directly from Source: You need to trust the developer and the Source that the uploaded binary is safe

Is my picture of this situation correct? Am I missing out significant points? If I am correct, would it be that dumb to keep using F-Droid for updates?

I would say you have about the same protection from generic malware in both Google Play and F-Droid. The important thing is that they would both remove an app from their repository the moment someone reports there is malicious code in the app or its source code. And they will both make sure they have the genuine version of a certain branded app, and remove any non-genuine versions as soon as it would be reported to them. This is the big level of protection you get, root of trust. You don't get that if getting the app directly from the developer, on github or similar (unless the app happens to be in AppVerifier, in which case you can verify it anyway).

Personally I would never trust Google Play Services or any Google integrations in my threat model, since Google is one of the parties that has acted hostile towards my minority. The risk they would inject code to spy on us is maybe not that big, but the risk F-Droid or anyone in the open source community would is way way smaller. I looked into getting Google Play Services free versions of my privacy sensitive F-Droid apps directly from the developers, but they say no, use F-Droid. They only publish the Google Play version of their apps on github.

ParanoidAndroid Can you please explain what the implications are?

Yes. None. There are no implications for end-users of the official F-Droid repositories, since the vulnerable functionality isn't even used. Third-party repositories you add yourself might be vulnerable, but I don't know to what extent or how.

The vulnerability is in server code, so client apps like the F-Droid app are not affected either.

DeletedUser87 That's not entirely true. F-Droid does only scan with badness enumeration in mind, like a traditional antivirus. You still are at risk of getting malware in there, if it is custom written. They have no way to check it - they don't audit apps manually.

Why pin this vulnerability on F-Droid? I see this happen quite a few times here, while the (recommended) alternative is even less ideal: you as a user are most likely to not check for this either, and Obtanium does nothing of the sort to protect you (it doesn't even check the signatures and AppVerifier is less than useful with their very limited database).

In my book, any automated check, audit and/or larger userbase that is able to find out malpractice is a lot better than the just-use-Obtanium+AppVerifier mantra here.

Also "it only affects F-Droid repo". WTF? F-Droid still exists today only because of 3rd party repos. So you either fix all of it or none of it.

I don't really know what leads you to that conclusion. I consider the main repo to be quite helpful. If only AppVerifier would support such an amount of apps...

That said, if I were to use 3rd party installation sources anyway, I would consider not using Obtanium, but Izzy's 3rd party F-Droid repo: Izzy has a decent set of checks and balances before an app enters their repo, communicates extensively with the devs in order to produce cleaner APKs, updates are very frequent and many, if not most of the interesting FOSS apps that aren't in F-Droid's main repo are available there.

Maybe then this issue would come up, although "additional APK checks are in place with the IzzyOnDroid repo" and these issues even came to light because of IzzyOnDroid's additional checks.

DeletedUser87 I've seen a lot of people claiming this as some sort of benefit, when it isn't. It's just as bad as everyone else.

While I agree that absolutisms in this regard don't hold, I don't agree with your conclusion that it is "just as bad" (which is another absolutism).

App updates are slow

There aren't many apps I use that have access to critical data. Many are fully offline apps at that. Always being on the latest version isn't the holy grail, new releases are often the cause of new problems and F-Droid's delay of a few days has often allowed me to prepare and act accordingly.

That said, I don't update my browser via the main repo for this reason, so we're in agreement there.

outdated build environments

That's the only thing I'm wary of, although it has already been established here that the environment itself isn't EOL, just "Debian-outdated". That doesn't justify the use of older JDK's imho, though, so I agree they'd be better off using a more up-to-date distro.

they leaked their private keys for fdroiddata

This is very sloppy and shouldn't have happened. Also, it was analyzed, handled and reported, leading to vast improvements to the automation system. I'm not sure I have an issue with people making mistakes as much as with people holding it against them until the end of time.

Vanadium ships with loads of upstream vulnerabilities that get patched all the time. I don't see people here saying the Chromium base is completely insecure and therefore we should never trust it and its devs ever again.

DeletedUser87 So now you do think that 3rd party repos are useful

No, I picked. I'm not using IzzyOnDroid. I said clearly that:

if I were to use 3rd party installation sources anyway

...then it'd be IzzyOnDroid.

DeletedUser87 I'm sorry, maybe I got it wrong, but I thought we are on GrapheneOS and not Debian Bullseye LTS. App stability is a nice to have, but I suffered from this backwards thinking myself when I (in my eternal wisdom) decided to run Immich from the F-Droid repo, which was always lagging behind the server by like 3 (!) releases and still does to this day. Neither does it help when you are using mostly offline apps, other people don't. Especially those who don't know any better. Not to mention that even offline apps can be exploited by other apps if they have unpatched vulnerabilities.

That's fair enough, but honestly? I hate that part of GrapheneOS. Every single time I update, I have to reserve some bit of "headspace" for the chance something breaks. Especially when doing automated jobs (back to the F-Droid case), these kinds of problems are quite sensitive. Now I already agreed that using Debian LTS is not a good option, but bleeding edge in such an environment, all for that 0.000000000000000000000000001% chance that someone would abuse a vulnerability in the 48 hours a package wouldn't yet be updated... then I'd say there's a decent balance to find there.

Granted, this is a bit muddled as I'm combining three different cases to make a point (GOS updates, F-Droid build env. and before that F-Droid app cycle).

DeletedUser87 I don't know what else to do, except exert public pressure, because it's the last shot we've got.

I reckon this is also where "bad blood" comes into play. I mean, the fact that "exerting public pressure" like you said is expressed in terms ranging from "Can't even get their regex right" all the way to "bulls**t behavior" and other expletives, together with the entitlement (not yours, but of others) I've read seems to make this hostile instead of constructive. That's just sad, because you're basically on the same side, while having arguments over bikeshedding.

That said, I would indeed like to see F-Droid's priorities shift more towards having decent security measures in place.