Live data from Hacker News

Timeline of the xz open source attack

research.swtch.com

241–250 of 482 posts

Re: Timeline of the xz open source attack

#241
post #197

Earlier quoted context omitted.

That's a great first step, but ready your pitchforks for this next take, because the next step is to completely eliminate Turing-complete languages and arbitrary I/O access from standard build systems. 99.9% of all projects have the capability to be built with trivial declarative rulesets.

Java's Maven is an interesting case study, as it tried to be this:. A standard project layout, a standard dependency mechanism, pom.xml as standard metadata file, and a standard workflow with standard target(clean/compile/test/deploy). Plugins for what's left. There might have been a time where it worked, but people started to use plugins for all kinds of reasons, quite good ones in most cases. Findbugs, code coverag…

Most of these could still be covered with IO limited to the project files though.

There is a sizable movement in the Rust ecosystem to move all build-time scripts and procedural macros to (be combined to) WASM. This allows you to write turing-complete performant code to cover all use-cases people can reasonably think of, while also allowing trivially easy sandboxing.

It's not perfect, for example some build scripts download content from the internet, which can be abused for information extraction. And code generation scripts could generate different code depending on where it thinks it's running. But it's a lot better than the unsandboxed code execution that's present in most current build systems, without introducing the constraints of a pure config file.

Re: Timeline of the xz open source attack

#242
post #95
post #88

Earlier quoted context omitted.

Look how brilliantly they selected their target project: (1) xz and the lib are widely used in the wild including linux kernel, systemd, openSSH; (2) single maintainer, low rate of maintenance; (3) the original maintainer has other problems in his life distracting them from paying closer attention to the project. I am wondering how many other OSS projects look similar and can be targeted in similar ways?

I'm thinking 95% of home automation which is full of obscure devices and half baked solutions which get patched up by enthusiasts and promptly forgotten about. Controlling someone's lights is probably less important than Debian's build fleet but it's a scary proposition for the impacted individual who happens to use one of those long tail home assistant integrations or whatever.

A lot of home automation controls EV charging these days too. Imagine an attack that syncs a country’s EV fleet to charge in a minute where demand is at a peak. You could cause some damage at the switchgear I bet if not worse

Re: Timeline of the xz open source attack

#243
post #226

Why do I feel like this set of posts by Russ about supply chain security will end up with a proposal/concrete first implementation of a supply-chain-verified-build process that starts at chip making - simple enough to analyze and rebuild independently- to bootstrap a go runtime that provides an environment to do secure builds. Reflections on Trusting Trust becomes even more interesting if you consider photolithograph…

I’m of the opinion that there are backdoors in most of our software and a lot of our hardware. xz just happened to be caught because it was hogging resources.

Re: Timeline of the xz open source attack

#244
post #123

Earlier quoted context omitted.

> Far too many people, including developers, seem to just accept upgrades as always-good instead of carefully considering the risks and benefits. Another example of this was log4j: if you were still using the old 1.x log4j versions, you wouldn't have been vulnerable to the log4shell vulnerability, since it was introduced early in the 2.x series. The old 1.x log4j versions had other known vulnerabilities, but only if…

> Another example of this was log4j: if you were still using the old 1.x log4j versions, you wouldn't have been vulnerable to the log4shell vulnerability Lol, this exact thing happened at my last gig. When I first learned of the vulnerability I panicked, until I found out we were so outdated it didn't affect us. We had a sad laugh about it. > "so that when another vulnerability happens, upgrading to a fixed version (…

A lot of people were in that exact same situation. So many, that the original author of log4j 1.x released a fork to allow these people to keep using the old code while technically being "up to date" and free of known vulnerabilities: https://reload4j.qos.ch/

Re: Timeline of the xz open source attack

#245

One big take away for me is that we should stop tolerating inscrutable code in our systems. M4 has got to go! Inscrutable shell script have got to go! Its time to stop accepting that the way we've done this in the past is the way we will continue doing it ad infinitum.

That would be an improvement for sure... but this is not fundamentally a technical problem.

Reading the timeline, the root cause is pure social engineering. The technical details could be swapped out with anything. Sure there are aspects unique to xz that were exploited such as the test directory full of binaries, but that's just because they happened to be the easiest target to implement their changes in an obfuscated way, that misses the point - once an attacker has gained maintainer-ship you are basically screwed - because they will find a way to insert something, somehow, eventually, no matter how many easy targets for obfuscation are removed.

Is the real problem here in handing over substantial trust to an anonymous contributor? If a person has more to lose than maintainership then would this have happened?

That someone can weave their way into a project under a pseudonym and eventually gain maintainership without ever risking their real reputation seems to set up quite a risk free target for attackers.

Re: Timeline of the xz open source attack

#246
post #108

Timeline reads like a "pig butchering" or romance scam. Except the goal is not money, but control. Attackers find a vulnerable but critical library in the supply chain. Do a cross check on maintainers or owners of the code (reference social media and other sources to get more information). Execute social engineering attack. Talk to maintainer(s) "off list" to gain rapport. Submit a few non-consequential patches that…

I'm amazed more people aren't talking about the "off list" part or asking Colin if he's willing to provide those emails/conversations.

That’s more of a LEO concern. Maybe attackers got sloppy and leaked info in email headers?

Re: Timeline of the xz open source attack

#248

A service that measured "credibility" or "activity" of a username/email could be really useful here. At least, it would be a leading indicator that something _might_ be up. In particular the aside here about the email addresses are suspect: https://research.swtch.com/xz-timeline#jia_tan_becomes_maint... would be useful info for Lasse Collins before taking the pressure campaign seriously.

What about just using 'web of trust', for example with GPG? If the user's key is signed by people that met up with the actual person, it would be much harder to make fake identities.

There was an article from 2019 [0] that someone on HN linked recently about how "web of trust is dead", but it seems to concern scalability problems with the keyserver, which resulted in DoS attacks, which made them disable the feature by default. The concept should presumably still be good, assuming the issues specific to the GPG keyserver can be avoided.

[0] https://inversegravity.net/2019/web-of-trust-dead/

Re: Timeline of the xz open source attack

#249

Maybe one of the outcomes of this could be a culture change in FOSS towards systematically banning rude consumers in Github issues, or, just in general, a heightened community awareness making us coming down on them way harder when we see it happen.

[deleted]

Re: Timeline of the xz open source attack

#250

I think this can be made much more difficult by enforcing a policy of open builds for open source. It shouldn't be possible to inject build files from a local machine. All build assets should come from the source repository. Artifacts should come from Github Actions or some other tool that has a clear specification of where all inputs came from. Perhaps Github could play a role in helping to automate any inconvenienc…

Yes the whole "let's take a mystery meat tarball from a repo that isn't the project repo" seems suspect. Github+ even has a scheme for signing artifacts such that you have some level of trust they came from inside their Actions system, derived from some git commit. This would allow the benefits of a modular build for a large product like a distro, while preserving a chain of trust in its component parts. +Not advocat…

as I wrote in a different thread, some projects don't have any source control.

From the big ones - 7z, ncurses are both tarballs only.

Post reply on HN