Hans-Christoph Steiner @eighthave@librem.one
Joined Aug 2019
@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.
Hans-Christoph Steiner
boosted
PSA: The panic button features built into F-Droid break when targeting newer Android SDK versions (e.g. #targetSdkVersion) due to new restrictions.
It might be possible to get them working again, but we currently do not have the bandwidth to maintain this. We welcome contributions to get it going again. Until then, removing the panic features looks to be our only responsible course of action. #CalyxOS includes built-in panic features like app removal, so that is a recommended replacement.
@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
Hans-Christoph Steiner
boosted
This week in #FDroid was published again.
You should read it if you're on Android 7 or older. For those on newer versions we have following tl;dr, but you're also welcome to read it all:
- 1.20 is in the making with even better repo handling
- custom Anti-Features will be on by default
- TetheredNet will be a new AF
- our website still has problems with localization
- Bunny Media Editor is new
- Secreto is now known as Sekreto
- 2 removals, 10 additions and 206 updates
Hans-Christoph Steiner
boosted
Risk of socially engineered backdoors in critical software seems like an indictment of open-source projects, but it could happen anywhere, EFF’s Molly told @theintercept - in fact, this one was found only due to the project’s open nature.
https://theintercept.com/2024/04/03/linux-hack-xz-utils-backdoor/
Hans-Christoph Steiner
boosted
Bullying in Open Source Software Is a Massive Security Vulnerability https://www.404media.co/xz-backdoor-bullying-in-open-source-software-is-a-massive-security-vulnerability/
@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 😄
Hans-Christoph Steiner
boosted
Some thoughts about attribution in the XZ backdoor, having just wasted so many hours digging into the details.
The email addresses used for a couple of years at least by the parties involved have absolutely *zero* trace in any kind data breach or database beyond Github/Gitlab, and maybe Tukaani and Debian and a few mailing lists.
Normally when I see this, the assumption is that we're dealing with a single-use or single-purpose email address that was created either for fraud or b/c someone is super paranoid about privacy.
The people in the latter camp who do this tend to have other tells that give them away, or at least *some* trace or home base in the online world. Especially if we're talking on the order of years using that address.
Either way, very few people do opsec well, and for every year you're operating under the same name, nick, number, email, etc you dramatically increase the risk of screwing up that opsec. And almost everyone does, eventually.
To see this complete lack of presence in breached databases once or twice in the course of an investigation is rare, but to find it multiple times suggests we're dealing with an operation that was set up carefully from the beginning. And that almost certainly means a group project (state-sponsored).
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/
Hans-Christoph Steiner
boosted
First more detailed analysis of the backdoor AFAIK, in this Bluesky thread: https://bsky.app/profile/did:plc:x2nsupeeo52oznrmplwapppl/post/3kowjkx2njy2b
So the backdoor’s intention isn’t compromising SSH sessions but rather executing arbitrary code on vulnerable Linux servers. The payload is hidden within the RSA key sent to the SSH server during authentication. This payload has to be signed with some unknown Ed448 key which only the attackers possess. If the signature is deemed correct, the payload is passed to system() (executes it as a shell command). Otherwise the code falls back to the default SSH behavior.
Had this backdoor been discovered a few months later, we would now have a lot of vulnerable servers all over the world. And only the attackers would be able to detect from outside which ones are vulnerable, because only they can send a correctly signed payload that would trigger command execution.
Planting a command execution backdoor into most Linux servers out there sounds too ambitious for someone driven by monetary interests, there are simpler ways to build a botnet. The level of sophistication and long-term planning indicates a state-level actor. Unfortunately, there isn’t a shortage of candidates. With quite a few Western governments pushing for lawful interception lately, I wouldn’t rule out any country at this point.
Hans-Christoph Steiner
boosted
It is now possible to re-order the position of repositories in the list. The repo at the top has the highest priority while the repo at the bottom has the lowest priority. Only if an app is available from more than one repo, the priority matters.
For example, if NewPipe's repo was added and the user always wants to prefer apps from that repo, they can move it to the top. In older versions of F-Droid, newly added repos were implicitly granted higher priority than repos added before.
Hans-Christoph Steiner
boosted
If the app is available from more than one repository, the box in the app details screen becomes a drop-down where the user can see all repos and choose which one should be used for installation, updates and app information.
Joined Aug 2019
