Hans-Christoph Steiner @eighthave@librem.one

@IzzyOnDroid @obfusk @fdroidorg They key takeaway is:

If a binary repo maintainer is not careful about where they get their APKs and relies completely on AllowedAPKSigningKeys to verify the APKs, then this is an important issue.

2/2

@IzzyOnDroid @obfusk @fdroidorg All I'm asking is for #ResponsibleDisclosure. The tone you sense was my panic as I scrambled to figure out the proof-of-concept to ensure that #FDroid users are kept safe. Signature verification is a key part of that. I cleared my schedule this morning to deal with this.

Thanks to @obfusk to doing the hard work of the proof-of-concept and the patch. I posted my preliminary analysis of the issue on https://gitlab.com/fdroid/fdroidserver/-/issues/1128#note_1852935205

1/2

@IzzyOnDroid @obfusk @fdroidorg I see this was reported to #androguard yesterday https://github.com/androguard/androguard/issues/1030

Did you give them any advanced warning?

@IzzyOnDroid @obfusk @fdroidorg Part of the bug was known 11 months ago. The new proof-of-concept shows key details that were not previously known nor reported in the issue. Those were just dumped to the public. We asked for that yesterday, and you didn't send it to us, but withheld it to now publicly dump it. That code was posted to GitHub yesterday: https://github.com/obfusk/fdroid-fakesigner-poc/commits/master/

You could have just sent us that link yesterday before tooting it, that would have been better.

@IzzyOnDroid @obfusk @fdroidorg you just published this wide open, yet before, you wouldn't even send us the POC code that you had? I think you two need to learn what #ResponsibleDisclosure means.

@IzzyOnDroid @fdroidorg I looked around but could not find any message from you about this anywhere. If you think this is an important security bug, then please submit what you have ASAP so we can handle it. #ResponsibleDisclosure

@Mer__edith Try to find the stressed out, overworked dev who implemented some piece of macOS or Google that annoys you. You can't, they are hidden within the corp. That doesn't mean they aren't an asshole, it just means you can't interact with them. FOSS devs are vastly more likely to operate in public and respond to feedback from anyone. So there is a data bias at work here.

@Mer__edith seems pretty off base to call that FOSS culture. In my 30 years of working in FOSS, the people who are actually immersed in FOSS are much nicer and more helpful than in general. It is the people who treat FOSS contributors of any kind as some kind of service provider that are the shitty ones. Way back, I worked in corp tech support, and got treated shitty. So often, I see people laying on that kind of crap on volunteer FOSS devs on the internet. That is not FOSS culture.

@sehe @gentoobro Free software passion projects are wonderful things. Payment often kills the passion that makes them great. Maintenance of infrastructure is not a passion project and that is what we all should be paying for. I see the #EU moving towards this kind of funding. There are many opportunities for doing this well: for example, orgs like #NSA get billions to improve #cyber-defense. But they are subordinate to the offensive side who want the 0days. This needs to be exactly the opposite.

This just triggered a thought: the fact that a well resourced actor spent all this time on the #xzbackdor focused on #GNULinux distros because they were not able to reliably hack into GNU/Linux in general, so they had to resort to this quite expensive campaign to get access again. Yes, this is speculation and yes I'm a #FreeSoftware fanboy. But there is a lot of good evidence that the free software distro model is quite good for providing secure setups. So take this news as good news 😄

A popular dev culture these days is bult on always pulling in the latest library #updates whenever possible. There can be good reasons to do that but new library code must still be reviewed. Or at least, confirm that the maintainers have been doing that, and still are. If you've even been through a code audit, it becomes crystal clear that dependencies are part of the #security profile. #Debian provides another layer of review. I use deps from Debian and review when updating packages, to share.

@nazokiyoubinbou I agree it is a red flag, but it is also perfectly normal for people to want their changes to be merged, especially when they are doing it on a volunteer basis and they want to wrap up that piece of work. Software is so often a rabbit hole that can easily suck down all your time. That's why this is a vulnerability. Developers understand that people want things merged, and it is generally worthwhile to merge improvements if they don't cause problems, even if they are not "done".

@kuketzblog @IzzyOnDroid the #FDroid implementation that checks usesCleartextTraffic and cleartextTrafficPermitted is here:

https://gitlab.com/fdroid/issuebot/-/commit/cd76b15fd6be063fdb614040a26dfe5801629c0a

3/3

@kuketzblog @IzzyOnDroid thanks for the prompt, we just merged related work. Issuebot now reports service intent-filters and checks cleartextTrafficPermitted. `fdroid build` blocks APKs with testOnly. You might be interested in the <meta-data> check in issuebot. For many cases, API key configs are by far the most reliable way to spot that a tracking or proprietary library is actually enabled in the app, and not just accidentally included. <meta-data> fields are tracked in Exodus ETIP.

2/

Nice idea to check usesCleartextTraffic, but that particular check isn't worth much since, as the docs say:

> This flag is ignored on Android 7.0 (API level 24) and above if an Android Network Security Config is present.

Sounds like the IzzyOnDroid scanner would not catch `android:usesCleartextTraffic="false"` then in the Network Security Policy, sets `<base-config cleartextTrafficPermitted="true" />`. From what I've seen, most apps use Network Security Policy anyway.

1/