F-Droid vulnerability allows bypassing certificate pinning

missing-root · 8 Jan

Wow... yes I update manually too. This simply is not a scaleable solution. It is an ease to have somewhat background updates.

And no, F-Droid is not only better than Obtainium because of that. I hope that you didnt really only get that. The client is extremely minimal, so that some repos dont even work with it, and only work with Droid-ify.

Obtainium is an entire browser. It renders HTML and runs Javascript, follows redirects and more. I use both, but Obtainium is not the secret tool that is better than all others.

baby_bat · 8 Jan

GrapheneOS can I just say what an absolutely fascinating read this entire thread has been, i had zero clue f droid's security was so borked. until today most of my apps were from obtanium, accrescent, and f droid, but after learning all this i uninstalled f droid and replaced my f droid apps with either the play store version or directly from obtainium. thank you so much for keeping security at the forefront

DDumdum · 8 Jan

missing-root yes I update manually too.

Shouldn't say blatantly untrue statements then.

And no, F-Droid is not only better than Obtainium because of that. I hope that you didnt really only get that. The client is extremely minimal, so that some repos dont even work with it, and only work with Droid-ify.

I simply don't care. Did you not get the part where I said I'm happy using Obtainium?

but Obtainium is not the secret tool that is better than all others.

Never said it was. Stop pretending I did.
The same can be said of Fdroid.

HHomerJay · 8 Jan

xuid0
It is mentioned to use these repos with F-Droid on the website.

missing-root · 8 Jan

Dumdum

Nobody is talking about you or me. Start thinking wider... These issues make Obtainium suboptimal.

Pocketstar · 9 Jan

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!

CCarlos-Anso · 9 Jan

FlipSid what would be the error code, if there is one, in the case of a rejection?

Error message is
'package conflicts with an existing package'

UUpstate1618 · 10 Jan

I think Obtanium can update apps in the background automatically.
Both in Apple App Store and Google Play, auto update feature won't update your apps as soon as new version released. If you want the latest update, you have to manually check for updates or even check apps one by one (Apple). This is annoying.

DDeletedUser95 · 10 Jan

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.

SovereignCopper · 10 Jan

Upstate1618 Play Store is perfectly capable of automatically updating your apps.

I've never seen Obtanium automatically update any of the apps, even though it's been enabled and the apps were installed via Obtanium, not another app and even manually updated via Obtanium at least once (so Android has correctly set Obtanium as the installation source). Obtanium even has unrestricted background permissions. As such, I don't think Obtanium is in any way reliable for automatic updates.

PParanoidAndroid · 13 Jan

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. I know, of reproducible builds (to my understanding the APK is directly uploaded if the build is reproducible). But isn't this similar to downloading the APK directly from the developers repo? Wouldn't that carry the same risk?

Can somebody offer some guidance on how to proceed? I want to avoid proprietary software on my phone whenever possible...

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?

Anyway thank you for pointing out this issue and to spread the awareness!

DDeletedUser87 · 13 Jan

ParanoidAndroid F-Droid: relatively low risk of installing malware if build by F-Droid

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.

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.

PParanoidAndroid · 13 Jan

DeletedUser87

I don't know how the repo system works with f-droid, but how would you make sure, that 3rd-party repos are safe? Is that even possible?

Isn't that still safer than having no audit at all? (For example when you use the binary from github)

Rryrona · 13 Jan

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.

PParanoidAndroid · 13 Jan

ryrona

It answers the question I had, what the implications for this certificate pinning vulnerability is

Can you please explain what the implications are?

Rryrona · 13 Jan

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.

SovereignCopper · 13 Jan

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

SovereignCopper · 13 Jan

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.

DDeletedUser87 · 13 Jan

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

I think you misunderstood me. I am not saying other platforms do it better. I'm only saying that the often recited fallacy of F-Droid being "malware free because they scan and have reproducible builds" holds true to this day. 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.

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

I don't like the main repo and I don't recommend it to anyone. App updates are slow (yes, because of F-Droid), they use outdated build environments and not long ago they leaked their private keys for fdroiddata. I can't trust it and neither should you.

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

So now you do think that 3rd party repos are useful and have "many, if not most of the interesting FOSS apps that aren't in F-Droid's main repo". Just pick one. Either go defend the horrible security of F-Droid or admit that the vulnerability IS in fact really bad.

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.

You know why they came up this way? Because Izzy cares and knows that they are very much affected.
It's the sheer stupidity of the F-Droid maintainers that has led to this clusterf***, which could've been avoided an eternity ago.

SovereignCopper · 13 Jan

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.