Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Timeline of the xz open source attack

research.swtch.com

Post reply on HN
Print view View original

301–310 of 482 posts

Re: Timeline of the xz open source attack

#301

Post by tamimio »

jvanderbot wrote: post #54

> It's also good to keep in mind that this is an unpaid hobby project. That's the root cause. At some point a corp/gov consortium needs to adopt key projects and hire out the maintainers and give them real power and flexibility, perhaps similar to the way a nation might nationalize key infrastructure. But this is against the core ethos at some level. Freedom and safety can be antagonistic.

You are implying that governments are more technically competent and more trustworthy than open source communities..

Re: Timeline of the xz open source attack

#302

Post by Vegenoid »

tamimio wrote: post #292

This attack doesn’t exploit a technical issue or bug, it exploits the open source philosophy, and unless the community will come up with a systematic process to counter it, expect more sophisticated attacks similar to it in the future. This time we got lucky that some smart nerd -I am a nerd too, this is a praise not to be taken in a bad way- noticed and notified the community in less than 20 days of the second backd…

Can you explain what aspects of the open source philosophy were exploited, and what possible mitigations might be?

Re: Timeline of the xz open source attack

#303

Post by wumeow »

intunderflow wrote: post #145
rsc wrote: post #40

Earlier quoted context omitted.

lcamtuf's two posts argue that this may simply not be an open-source maintainer's job to defend against. ("The maintainers of libcolorpicker.so can’t be the only thing that stands between your critical infrastructure and Russian or Chinese intelligence services. Spies are stopped by spies.") That doesn't mean we shouldn't try to help burnt out committers, but the problem seems very hard. As lcamtuf also says, many th…

Why the assumption this is a Russian or Chinese intelligence service? Western governments aren't above this sort of conduct: https://www.mail-archive.com/cryptography@metzdowd.com/msg12...

Countered in the very same thread: https://www.mail-archive.com/cryptography@metzdowd.com/msg12...

Re: Timeline of the xz open source attack

#304

Post by semi-extrinsic »

eadmund wrote: post #279
kibwen wrote: 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.

I think that what we need is good sandboxing. All a sandboxed Turing-complete language can do is perform I/O on some restricted area, burn CPU and attempt to escape the sandbox. I would like to see this on the language level, not just on the OS level.

I have been thinking the exact same thing, and specifically I would like to try implementing something that works with the Rye python manager.

Say I have a directory with a virtualenv and some code that needs some packages from PyPI. I would very much like to sandbox anything that runs in this virtualenv to just disk access inside that directory, and network access only to specifically whitelisted URLs. As a user I should only need to add "sandbox = True" to the pyproject.toml file, and optionally "network_whitelist = [...]".

From my cursory looking around, I believe Cloudflare sandbox utils, which are convenience wrappers around systemd Seccomp, might be the best starting point.

Edit: or just use Firejail, interesting...

You mention sandboxing on the language level, but I don't think it is the way. Apparently sandboxing within Python itself is a particularly nasty rabbit hole that is ultimately unfruitful because of Python's introspection capabilities. You will find many dire warnings on that path.

Re: Timeline of the xz open source attack

#305

Post by 01HNNWZ0MV43FF »

oefrha wrote: post #106
lukaslalinsky wrote: post #24

The social side of this is really haunting me over the last days. It's surprisingly easy to pressure people to giving up control. I've been there myself. I can't even imagine how devastating this must be to the original author of XZ, especially if he is dealing with other personal issues as well. I hope at least this will serve a strong example to other open source people, to never allow others to pressure them into…

I’ve given semi-popular projects that I no longer had the bandwidth to maintain to random people who bothered to email, no pressuring needed. While those projects are probably four to five magnitudes less important than xz, still thousands of people would be affected if the random dude who emailed was malicious. What should I have done? Let the projects languish? Guess I’ll still take the chance in the future.

I guess all you can do is not give the brand away.

Put a link saying "Hey this guy forked my project, I won't maintain it anymore, he may add malware, review and use at your own risk"

Re: Timeline of the xz open source attack

#306

Post by ok123456 »

psanford wrote: post #193

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.

With all the CI tooling and containerization, it seems to be going in the opposite direction.

Re: Timeline of the xz open source attack

#307

Post by ok123456 »

Inf0s3c wrote: post #168
nrawe wrote: post #78

"It's also good to keep in mind that this is an unpaid hobby project." ~ Lasse Collin, 2022-06-08. As someone working in security, the fact that _foundational_ pieces of the computing/networking rely on motivated individuals and essentially goodwill is mind blowing. There are great aspects to the FOSS movement, but the risks – particularly the social engineering aspects as demonstrated here – and potential blast radi…

Also in security and 100% tired of the code slingers who get annoyed by security reviews Here on HN it’s been derided as “company just checking a box for compliance but adds no functionality. It slows us down when we want to disrupt!” - developer of yet another todo list or photo editor app… Buffer overflows and the like are one thing. Notions from this blog that certain normal files won’t be well reviewed is a bad s…

A security review or snake oil AI black box didn't stop this. It was stopped by a 'code slinger' who noticed a performance regression in ssh.

Deloitte coming in a checklist would have NEVER stopped this one.

Re: Timeline of the xz open source attack

#308

Post by tamimio »

exacube wrote: post #38

Is the real identity of Jia Tan known, even by Lasse Collin? I would think a "real identity" should be required by linux distros for all /major/ open source projects/library committers which are included in the distro, so that we can hold folks legally accountable

Nope, identities won’t solve it, you can have people coerced, blackmailed, threatened, or simply just a “front” while there’s a whole team of spies in the background. The process should be about what’s being pushed and changed in the code, but I would be lying to say I have a concrete concept how it is possible.

Re: Timeline of the xz open source attack

#309

Post by 1024core »

I am reminded of the infamous Sendmail worm from 1989(?).

If this compromised OpenSSHd had become the default across millions of systems all over the world, could a worm-like thing have brought a major chunk of the Internet down? Imagine millions of servers suddenly stuck in a boot-loop, refusing to boot.

And all because one owner of a library had some mental health issues. We should not have such SPOFs.

Post reply on HN