Should someone stumble upon the security vulnerability disclosure at openwall.com/lists/oss-securit – be assured the patches have already been applied at #IzzyOnDroid (and also that androguard is already aware: github.com/androguard/androgua)

Also see the toot by the original finder: tech.lgbt/@obfusk/113765201775

#security

@IzzyOnDroid the regex fix is a good one, we'll look into merging that. I'd need to see a v2-signed APK that is installable on Android that demonstrates the exploit it in order to consider this an actionable security vulnerability. APKs signed by v1-only are not even installable on latest Android versions, and Android 7.0 and above support v2+ signatures. Looks like obfusk's proof of concept is a v1-only APK. Do you even ship v1-only APKs in IzzySoft anymore?

@eighthave The regex fix is also considered by Androguard, yeah. And I didn't make the POC; that area is not in my expertise¹. I could check if there are any v1-only APKs in our repo² (not aware of any right away, though, but we still have some older apps here – and there are still some older devices around; we support "device longevity" 😉). But v1 IS important here, as we still support signing key rotation³ (and have at least 1 app using that).

(1/2)

@eighthave (2/2)

¹ I can follow it, but not create such on my own
² we would need time to set up a script for that; remember we're just a very small team with no grants; most work is still on my shoulders, next to a full-time $dayjob
³ we didn't use your implementation for fdroidserver back in spring but applied the patches provided by Fay, so signing key rotation is still supported at IzzyOnDroid

@eighthave (3/2)

"I'd need to see a v2-signed APK that is installable on Android that demonstrates the exploit it in order to consider this an actionable security vulnerability."

I'd rather not wait until an exploit is out-and-about. The patch is easy and not complex. Better safe than sorry. And one should fix (even potential) vulnerabilities *before* they become exploits.

@IzzyOnDroid I understand your concern. From what I know, the IzzySoft repo relies much more on AllowedAPKSigningKeys to provide a secure repo than f-droid.org or guardianproject.info (the repos I'm involved in running). Both had extra verification before AllowedAPKSigningKeys existed, so there, its just an extra layer of protection. The goal of AllowedAPKSigningKeys is to make it easy for non-technical people to manage binary APK repos securely. That is a work in progress, and your reports help

@IzzyOnDroid indeed AllowedAPKSigningKeys was inspired by the various custom scripts and processes we had in place already. We welcome contributions to improve AllowedAPKSigningKeys. We don't currently have funding to work on it. We would gladly help someone put together a funding proposal to work on it.

@eighthave It's not just about F-Droid and Guardian, Hans. You are promoting fdroidserver for all those decentralized repositories, it's your software. IzzyOnDroid has not a single grant (wouldn't your Mobifree grant cover that?), our team is much smaller than yours (~3 vs ~30) – and not a single one here at IoD is being paid vs. 2+ full-time at F-Droid (we're all doing all this in our spare time, I spend 4+ hours each day after my regular 9h $dayjob for example, not counting weekends. (1/5)

@eighthave (2/5) Still we tried to contribute in the past, more than once (and also on this issue). Our contributions were refused then. But the patches we speak of are available at the POC, like last time. Feel free to use them, of course!

@eighthave (3/5) Wouldn't your Mobifree grant cover that work? The underlying issue even carries its tag: gitlab.com/fdroid/fdroidserver

@eighthave (4/5) quoting from f-droid.org/2024/05/24/mobifre

> For more than 14 years, F-Droid has been developing solutions which act as pieces of the alternative mobile ecosystem puzzle. So it was a natural fit for F-Droid to become a contributing partner in the broader Mobifree project.

@eighthave (5/5) And looking at Mobifree, from nlnet.nl/mobifree/

> Our goal is to help mobile technology evolve to a more healthy state, provide people with concrete new tools and more reliable infrastructure, in order to provide better security and allow users more agency and choice.

"Better security". Should be the perfect fit for a security issue, no? 😉

@IzzyOnDroid I'm not sure the point you're trying to make here. EU Horizon grants such as Mobifree are large partnerships between around 10 projects. The work and goals are all nailed down between the partners. These kinds of funds are not free money to spend as we please.

@eighthave I was just wondering, as the corresponding issue carries the Mobifree label. And sorry, we have all hands full with work on IzzyOnDroid – so all we can contribute are those patches, we cannot help you rolling them out at F-Droid.org.

The patches work fine, we use them ourselves. Not sure though how they harmonize with your alternative implementation, which we didn't merge at our end (we use the patches we proposed back then). But we even provide a patch for that variant, please test.

@IzzyOnDroid Things with the Mobifree label are things that are being considered as part of that grant. It is definitely not a promise. It is quite likely we will work on AllowedAPKSigningKeys as part of Mobifree, I'd like to, but no guarantees. Currently, I'm thinking of making AllowedAPKSigningKeys only support v2+ signatures, since v1 signatures are deprecated, on their way out, and really overly complicated. I see no sense in trying to build security guarantees on top of them.

@eighthave Thanks Hans! But you are aware that you still have v1-only APKs in the repo, right? Not saying AllowedAPKSigningKeys is active for them. And yes, it's older apps (just random findings). A full scan could reveal them all (we need to do the same here at IoD as well, have that on our list, but we are even more "understaffed" than you and still without any grants).

Follow

@IzzyOnDroid Since you're investing a lot of effort into AllowedAPKSigningKeys, I highly recommend switching the effort to parsing the signing certificate from v2+ signatures, and away from inspecting the deprecated v1 signatures. Apps with targetSdkVersion 30 or higher entirely ignore v1 signatures, so they are gradually disappearing from use.

@eighthave Isn't that what fdroidserver promises to provide to those using it to maintain a repository? We do not "invest a lot of effort into AllowedAPKSigningKeys" – we simply apply it consequently. Signature pinning is expected to be done by fdroidserver; we *accidentally* found flaws there, we even provided patches which were refused. We still have v1-only APKs as the F-Droid.org repo has them, yes. But we don't write/maintain fdroidserver. Are you saying it is unsafe for use by other repos?

@IzzyOnDroid I'm saying v1 signatures should not be something that anyone relies on any more. Our current thinking is to remove support for v1-only signatures from AllowedAPKSigningKeys because of the weakness of v1 signatures means we cannot provide good security, so it would only provide a false sense of security. For distributing v1-only signed APKs, I'd recommend verifying them via an alternate method other than certificate pinning.

Sign in to participate in the conversation
Librem Social

Librem Social is an opt-in public network. Messages are shared under Creative Commons BY-SA 4.0 license terms. Policy.

Stay safe. Please abide by our code of conduct.

(Source code)

image/svg+xml Librem Chat image/svg+xml