Skip to main content

mastodon - Link to source

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


Invalid regexp for the certificate · Issue #1097 · androguard/androguard

See: https://www.openwall.com/lists/oss-security/2025/01/03/1 Seems a good idea to patch ;) The regex in question -- ^META-INF/..(DSA|EC|RSA)$ -- is supposed to match all filenames that start with ...
GitHub
#security #izzyondroid
in reply to IzzyOnDroid ✅

Hans-Christoph Steiner
mastodon - Link to source
Hans-Christoph Steiner
• •
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?
in reply to Hans-Christoph Steiner

IzzyOnDroid ✅
mastodon - Link to source
IzzyOnDroid ✅
• •

@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)

@Hans-Christoph Steiner
in reply to IzzyOnDroid ✅

IzzyOnDroid ✅
mastodon - Link to source
IzzyOnDroid ✅
• •

@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

@Hans-Christoph Steiner
in reply to IzzyOnDroid ✅

IzzyOnDroid ✅
mastodon - Link to source
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.

@Hans-Christoph Steiner
in reply to IzzyOnDroid ✅

IzzyOnDroid ✅
mastodon - Link to source
IzzyOnDroid ✅
• •
@eighthave And PPS: That POC APK installed fine on Android 13 & 14 (targetSDK is < 30, as with the F-Droid client) 🤷‍♂️
@Hans-Christoph Steiner
in reply to IzzyOnDroid ✅

Hans-Christoph Steiner
mastodon - Link to source
Hans-Christoph Steiner
• •
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
in reply to Hans-Christoph Steiner

IzzyOnDroid ✅
mastodon - Link to source
IzzyOnDroid ✅
• •
@eighthave Well, if you think AllowedSigningKeys is the only protection we're using, you're a bit misinformed 😉 Of course we have multiple layers in place, too. But not all binary APK repos have, some are relying on the "built-in protection".
@Hans-Christoph Steiner
in reply to IzzyOnDroid ✅

Hans-Christoph Steiner
mastodon - Link to source
Hans-Christoph Steiner
• •
Good to hear you have more layers of verification. I'd like to read about what you're doing, since you've been handling the auto-download of APKs for a long time, so perhaps there is more we could add to `fdroid update`. Could you point me to them? There is a good foundation for us to build on: APK v2+ signatures are quite robust and APK signing keys tend to be quite stable over time. That makes it possible to automate checks so repo operators don't have to know all about signing.
in reply to Hans-Christoph Steiner

IzzyOnDroid ✅
mastodon - Link to source
IzzyOnDroid ✅
• •

@eighthave android.izzysoft.de/articles/n… outlines several of our layers. And you still have one of our scanners in your issuebot – though for some reason that seems not have to be run anymore for quite a long time (I never saw it in issuebot reports for about 2 years now).

You can find our scanning scripts at gitlab.com/IzzyOnDroid/repo (look at the Readme in the lib/ directory). We plan to make them available as Docker/Podman image, but no ETA yet.


Zusätzliche APK-Checks im IzzyOnDroid Repo

Nachdem der Library-Scanner nun seit mehreren Jahren im IzzyOnDroid Repo im Einsatz ist war es an der Zeit, einige zusätzliche APK-Prüfungen zu etablieren.
IzzyOnDroid
@Hans-Christoph Steiner
in reply to Hans-Christoph Steiner

Hans-Christoph Steiner
mastodon - Link to source
Hans-Christoph Steiner
• •
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.
in reply to Hans-Christoph Steiner

IzzyOnDroid ✅
mastodon - Link to source
IzzyOnDroid ✅
• •
@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)
@Hans-Christoph Steiner
in reply to IzzyOnDroid ✅

IzzyOnDroid ✅
mastodon - Link to source
IzzyOnDroid ✅
• •
(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! They're working fine with fdroidserver here at IzzyOnDroid 😉
This entry was edited (2 weeks ago)
in reply to IzzyOnDroid ✅

IzzyOnDroid ✅
mastodon - Link to source
IzzyOnDroid ✅
• •

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

@Hans-Christoph Steiner
in reply to IzzyOnDroid ✅

IzzyOnDroid ✅
mastodon - Link to source
IzzyOnDroid ✅
• •

@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? 😉

NLnet; NGI Mobifree

nlnet.nl
@Hans-Christoph Steiner
in reply to IzzyOnDroid ✅

Hans-Christoph Steiner
mastodon - Link to source
Hans-Christoph Steiner
• •
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.
in reply to Hans-Christoph Steiner

IzzyOnDroid ✅
mastodon - Link to source
IzzyOnDroid ✅
• •

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

@Hans-Christoph Steiner
in reply to IzzyOnDroid ✅

Hans-Christoph Steiner
mastodon - Link to source
Hans-Christoph Steiner
• •
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.
in reply to Hans-Christoph Steiner

IzzyOnDroid ✅
mastodon - Link to source
IzzyOnDroid ✅
• •
@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).
@Hans-Christoph Steiner
in reply to IzzyOnDroid ✅

Hans-Christoph Steiner
mastodon - Link to source
Hans-Christoph Steiner
• •
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.
in reply to Hans-Christoph Steiner

IzzyOnDroid ✅
mastodon - Link to source
IzzyOnDroid ✅
• •
@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?
@Hans-Christoph Steiner
in reply to IzzyOnDroid ✅

Hans-Christoph Steiner
mastodon - Link to source
Hans-Christoph Steiner
• •
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.
in reply to IzzyOnDroid ✅

Hans-Christoph Steiner
mastodon - Link to source
Hans-Christoph Steiner
• •
fdroidserver is fully safe for the tasks it was built for. It has been independently audited as well (we have two more audits coming up). If you have a trusted collection of APKs, then fdroidserver provides the entry point to a trustworthy pipe to the F-Droid client. It cannot protect against malicious upstreams, upstreams losing their signing keys, etc. It cannot fix the deprecated v1 signatures. Require v2+ signatures, and AllowedAPKSigningKeys works with no known weaknesses.
in reply to Hans-Christoph Steiner

Matija Nalis
mastodon - Link to source
Matija Nalis
• •
@eighthave What I'm wondering is does F-droid.org instance host any v1-signature apps? Or are they outright refused / deleted?
@IzzyOnDroid
@Hans-Christoph Steiner @IzzyOnDroid ✅
in reply to Matija Nalis

IzzyOnDroid ✅
mastodon - Link to source
IzzyOnDroid ✅
• •
@mnalis Same as IzzyOnDroid most likely: older apps which have long-time seen no updates anymore. At IoD, we've just removed several of those (which were additionally using weak keys, or had other issues as well), leaving only those in that have strong enough keys etc. Some were left for further investigation, in one case (app still actively maintained) we reached out to the devs asking for additional v2 signing. @eighthave
@Hans-Christoph Steiner @Matija Nalis
in reply to IzzyOnDroid ✅

Matija Nalis
mastodon - Link to source
Matija Nalis
• •
@eighthave Would it make sense (if those abandoned v1 apps are still useful so should not be archived/removed) to recompile and re-sign those abandoned apps with F-droid.org keys (I'm assuming they're not RB), so people who install them from F-droid these days won't be vulnerable to fake upgrades elsewhere on the net (as I'm understanding is the risk currently)?
Or maybe tag them with that "Vulnerable" flag that F-droid apps (esp. browsers) get occasionally?
@Hans-Christoph Steiner
in reply to Matija Nalis

IzzyOnDroid ✅
mastodon - Link to source
IzzyOnDroid ✅
• •
@mnalis I guess none of us have tried those old ones for RB – and with the projects dead and their devs no longer around, that would not help anyway (as with RB, both F-Droid & IoD would ship the upstream APK, which has that signing issue). Wile at IoD we build apps from source FOR RB, we don't sign ourselves. But (most of) the v1-only apps at F-Droid just needed to be re-signed (adding v2) as they are signed by F-Droid – right, @eighthave ?
@Hans-Christoph Steiner @Matija Nalis
⇧