F-Droid vulnerability allows bypassing certificate pinning

ParanoidAndroid

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

Can you please explain what the implications are?

ryrona

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

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

DeletedUser87

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

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.

SovereignCopper

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

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

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.

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

Well, guess what? They won't. Because they have ignored the problem for years and will likely keep ignoring it until armageddon strikes.

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

Eh, they were lucky some random dude even noticed it. Could've just as well been a black hat who then would've sold it on Raidforums or something and armageddon WOULD have struck. They were saved purely by dumb luck. If they hadn't "analyzed, handled and reported (to whom?)" it, I would be actually scared.

There is no excuse here. As I already stated multiple times, there's a pattern of systematic failure inside the F-Droid project. They can't get their code right (not even the f***** regex), they treat CVEs like it's just another Tuesday, they don't understand security, because they rely on "ifs" and "buts" and they generally just seem not to care. Doing the bare minimum to keep the show running.
And you can't defend this bulls**t behavior by stating that they also did something good. It doesn't matter. It doesn't matter because the negatives outweigh the positives here. They have been aware of every single problem they (currently) have for YEARS and nothing is changing. I don't know what else to do, except exert public pressure, because it's the last shot we've got. They were consulted and warned by multiple, very knowledgeable people and they don't give a f. That needs to change.

GrapheneOS

SovereignCopper

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.

The system is still designed is an incredibly insecure way and is run by people who do not build things with security in mind or prioritize it. There is no way that it should work anything like this. It is not simply a mistake.

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.

There's quite a difference between having memory corruption bugs in C++ code for a browser vs. designing a package repository in an incredibly insecure way. Chromium didn't really have a viable alternative to C and C++ at the time, but new software does, and Chromium should be criticized for not quickly migrating to a memory safe low-level language as Android is doing.

F-Droid doesn't ship all the available fixes for upstream vulnerabilities in the many outdated dependencies they're using and shipping to end users in app builds. They often take years to ship important updates and adopt new APIs released to address security vulnerabilities. Do you think it would be fine if Vanadium stayed on Chromium 132 for the next 2 years and started disabling upstream security features inconvenient to us along with not adopting new ones?

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 use a bunch of end-of-life tools with unpatched security vulnerabilities. Debian doesn't truly provide the kind of security support people imagine it does. Backporting a subset of the patches for issues with CVE assigned is not providing most security patches. F-Droid builds with more than an outdated JDK.

SovereignCopper

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.

DeletedUser87

SovereignCopper 48 hours a package wouldn't yet be updated

48 hours?! That's a best (best best) case scenario. Let's have some examples:

Aurora Store (F-Droid build 4.6.3, current 4.6.4. not on F-Droid yet)
• Izzy: 23.12.
• F-Droid: 02.01. (lag of 11 days)
Home Assistant (F-Droid build 2024-12.1-minimal)
• Github: 01.12
• F-Droid 09.12 (lag of 8 days, a lot of pre-releases and current release behind)
Tasks.org (F-Droid build 14.1, current build 14.4.1)

• Github: 26.11.
• F-Droid: 29.11. (lag of 3 days, currently 7 (!) builds behind)
Delta Icon Pack (F-Droid build 1.99)
• Github (version 1.98): 01.12
• F-Droid: 09.12. (lag of 8 days)

This is throughout the landscape. I've even seen some apps being MONTHS behind the current release, although less common.

SovereignCopper hostile instead of constructive

There is no more constructive with these people. You can talk to a wall 50 times, but it will keep being a wall. You need to use brute force to get through, as is the case here. There is comments dating back more than a DECADE (almost 12 years to be exact) that address the very same thing we are complaining about today. Do you honestly think, that after almost 12 years (likely longer, I'm too lazy to search) some nice words and a gift basket is going to change anything? It is clearly an attitude problem and there just is no. other. way.

GrapheneOS

SovereignCopper

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.

Debian takes years to ship many security patches, not 48 hours, and Debian LTS doesn't have official security support. You're operating under the incorrect belief that most security vulnerabilities get CVE assignments particularly in the kinds of projects that it's built from or that or that they actually ship those quickly. It doesn't work that way for Debian stable and certainly not LTS.

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.

F-Droid has an egregiously poor approach to security and has consistently engaged in cover ups, attacks on security researchers and attempts at discrediting them with fabricated stories and harassment. They're genuinely untrustworthy people who shouldn't have a highly trusted position. F-Droid doesn't simply have regular slip ups and vulnerabilities but rather an insecure architecture and approach from top to bottom where security is not and has never been prioritized. Not only that, but they do not acknowledge most of the issues and do not take serious steps to address to huge problems with the architecture. Papering over symptoms of the huge architectural issues one by one rather than designing for security is not taking it seriously. There are very few people looking into it so you can't expect to see a steady stream of vulnerability reports and it does not mean they aren't there.

Here's an example of the people involved engaging in harassment, then covering it up and subsequently fabricating stories about it they posted across many platforms:

https://archive.ph/j7qql

Why would anyone trust their cover ups of security flaws and potentially breaches in their blog posts? Why do you expect they'd admit to it and tell anyone when they've been repeatedly caught in situations like that blatantly lying about security and engaging in incredibly underhanded and dishonest attacks on security researchers in an attempt to discredit them?

SovereignCopper

DeletedUser87 I wasn't referring to F-Droid's update policy there, but in general sense about a Linux package manager for the build environment. Sorry for the confusion.

When it comes to F-Droid's track record on keeping apps up-to-date, yeah it could and perhaps should be better.

more than a DECADE (almost 12 years to be exact)

This seems to have been based primarily on a wrong assumption made by m0xie back then:

The bulk of applications distributed through fdroid are signed by keys that belong to the fdroid maintainers, and which are kept online. This means that the fdroid maintainers themselves, or any attackers who compromise fdroid, are capable of pushing malware to your device.

(when in fact no keys were held online at all).

I don't know if it helps to pile up every issue from the past, however big or small, instead of looking at the current situation and trying to improve it, but as far as I can judge, that hasn't proven to be easy and I recognize this is why there is bad blood between F-Droid and others.

elisa4501

DeletedUser87

splattergames, would you be willing to indicate if you have a past history with the F-Droid organization without revealing personal details? I'm trying to better understand your viewpoint. (Full disclosure: I have no association past or present with any apps or orgs mentioned in this thread).

DeletedUser87

SovereignCopper I haven't linked his wrong assumption though, but the following comment which addresses the same issues we have today. In particular, this part:

I can't willingly participate in something that I believe is a bad idea. I can't sign and distribute packages through fdroid, because I believe that fdroid is harmful, and I don't want to endorse harmful activity.

I understand that many of the people commenting here probably understand how insecure fdroid is, but value a full OSS stack more than the security of their device. That's fine, but I think anyone that completely understands the risks is also completely capable of building TextSecure from source themselves. It's the people that don't understand the risks that I'm worried about.

This exact comment could have been write at any point in the last 12 years. And that's inexcusable.

DeletedUser87

elisa4501 Nope, I have never even had a conversation with any of them. This is just my personal opinion from what I have seen over time. A few years ago, when I had less technical understanding, I was actually a big proponent of F-Droid. Fortunately, that viewpoint has changed dramatically over the past couple of months.

This is actually based on 2 things:

My disgust for people who refuse good ideas based on the "I am the boss" principle, which seems to be the case for some F-Droid maintainers who are in charge. This is kind of personal, since I had a boss once who would act this way. That dude would spend 2 hours trying to remove his Apple ID from a MacBook by deleting the hard drive and reinstalling the OS a bunch of times, instead of typing in his password - which was the correct solution I suggested. He valued authority over good ideas. F that.
My disgust for people who see security as an afterthought. And most certainly companies that scam their customers (Fortinet, Palo Alto, Cisco, Ivanti and so on) with false claims or abysmal security.

It certainly stems from following the rabbit hole and seeing how the whole saga is developing over time.

The original title of this post was: "The F-Droid "horrible security" saga continues" and it's what I'm trying to get across. It's been going on for an eternity and the more time passes, the worse it seems to get.

elisa4501

sky9000 Chain of trust here is a shit show

this is more true than I'd like.

When I onboard people to GOS and tell them the GOS dev team recommends the Play Store as a secure source of apps they usually reject this saying they are trying to leave Google (with some having been been burned by Play Store malware).
When I try to explain Accrescent they say it is too sparse in app details and offerings.
With Obtanium, some are bugged that there is often more than one apk to choose from and they have to figure it out. Sometimes they can't get the download link right. They stop using it.
With Appverifier, they are frustrated most apps don't verify. Once they hear about verification, they want all apps to verify.
When they see FDroid, they usually like the UI and are excited. If I tell them about FDroid weakness, they are quite confused about what to do.

What is the future?

Thanks for the interesting thread.

GrapheneOS

elisa4501 F-Droid has no future in a privacy/security focused mobile ecosystem. The core developers do not understand the basics of security, do not care about it and have consistently proven they cannot be trusted. They should not be in control of anything important, let alone being a major single point of failure for distributing open source apps that's bound to turn out horribly. If F-Droid infrastructure gets compromised and the people using it get shipped a whole bunch of apps with malware injected, that won't be surprising in any way and no one can claim we didn't try to warn people and steer them away from it. It should end up being a way people criticize GrapheneOS as if we directed anyone towards using it. We fully expect that to happen and consider it quite a serious problem how many of our users are making use of it. The main thing holding back better alternatives if F-Droid itself and F-Droid is never going to become a secure and trustworthy source of apps. The sooner people move on and start focusing on alternatives, the sooner those will start having far more resources and apps. F-Droid is not trying to build something that fits into what we're trying to build.

Themble

GrapheneOS The sooner people move on and start focusing on alternatives, the sooner those will start having far more resources and apps.

Is Obtainium a decent alternative? Is it imperative in order to have proper security, to use AppVerifier along with it?

n2gwtl

GrapheneOS
A lot of privacy focused apps have directed us to download from FDroid - Molly, Thunderbird, Proton.It is very difficult to make a right decision from the beginning because of the lack of clarity.

Moving away from FDroid now feels like the transition from an IPhone to GrapheneOS. Too many apps configured to work with a homelab that now all have to be redone.

ryrona

Themble Is Obtainium a decent alternative?

Questionable. I think the two sides of the coin has been discussed above. With Obtainium you don't put any trust in F-Droid, but on the other hand, you put all that trust in yourself instead.

Think of using F-Droid as installing apps in Linux from the official repositories, and Obtainium as downloading exe-files from the web in Windows. Neither is necessarily better or worse for the security for someone that knows what they are doing. F-Droid seems clearly better if you don't know what you are doing, so you don't end up installing malware or vulnerable versions.

Is it imperative in order to have proper security, to use AppVerifier along with it?

If an app verifies with AppVerifier, you put the trust in AppVerifier instead of yourself or F-Droid. So generally, that would be a very good choice over using Obtainium without AppVerifier.

DeletedUser95

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

Do keep in mind you technically have to trust the developer no matter what app source you use. As there's always a possibility of malware slipping through no matter the source. And also a benefit of getting it directly from the source yourself is if provided you are willing to do so you can take steps and precautions to manually verify it yourself. Which is quite nice as it places a factor of trust in yourself rather than putting ALL of your trust in app sources.

Ultimately in terms of you asking guidance on how to proceed.. Well it's genuinely a matter of two things.

Your threat model
What you value most

Following up from 1. As in what are you trying to protect yourself from and how severe or dangerous is the threat to you?
Following up from 2. As in what do you value most? Security? Privacy? Overall control? Feature theatre? Minimalism? The list goes on and on of things people can value more than other things.

Point is I wouldn't say it's necessarily dumb to keep using F-Droid if your threat model and priorities do not demand good security. It's your call. Just do always keep it's massive issues in mind if you do. That should go for any method too always keep in mind of the issues or shortcomings it has.

I will say though in terms of mainly wanting to use FOSS software you could subscribe to F-Droid's RSS news feed! I never really see people talk about this but it's a genuinely good way to still engage with FOSS apps without having to have F-Droid installed because general F-Droid news aside it tells you about certain big noteworthy App changes, what apps got updated though I would suggest ignoring the updates part since it's been discussed several times that F-Droid lags behind pretty badly on updates. And most importantly what new apps got added! Which would be important in trying to discover new FOSS apps. And then of course you can use the F-Droid website to find quick links to the app's source to read more about it or install it from there. This method allows you to still easily engage with FOSS apps but without the necessity of having F-Droid badly compromising your security.
Even if you use/continue to use F-Droid though I'd say the you should still use the RSS feed or check the news section of their site every now and then. It's quite informative!

ParanoidAndroid

DeletedUser95

Thanks for this detailed advice! I am still trying to get my thougts ordered about this topic. So basically for me the question is why I should use Obtainium over F-Droid..

F-Droid's security is a point but when F-Droid builds the app it is more or less guaranteed, that the app was build from the source code. This is not the case when Obtainium is the installation-source because the signature that can be verified has nothing to do with the Code.

If my assumption is correct I don't get why I should trust many developers when using Obtainium instead of only trusting F-Droid. Isn't the Security compromised with each app that is installed and updated via Obtainium?

Eirikr70

n2gwtl I have done that shift and didn't find it that hard. You mainly have to reenter your path and reidentify.

DeletedUser95

n2gwtl

n2gwtl A lot of privacy focused apps have directed us to download from FDroid - Molly, Thunderbird, Proton.It is very difficult to make a right decision from the beginning because of the lack of clarity.

I agree. This is quite problematic as it gives the user the idea that F-Droid is secure and trustworthy. Especially when you got big apps like those on there. Actually pretty much most of the only decent VPN providers are on there as well. Which as you said is only a problem cause of the lack of clarity and information.

n2gwtl Moving away from FDroid now feels like the transition from an IPhone to GrapheneOS. Too many apps configured to work with a homelab that now all have to be redone.

Depends on what apps you use. Most of my apps had backups or were even configured to use data outside of themselves entirely so my transition only really took a few hours at most.

« Previous Page Next Page »