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

What we know about the xz Utils backdoor that almost infected the world

arstechnica.com

Post reply on HN
Print view View original

111–120 of 336 posts

Re: What we know about the xz Utils backdoor that almost infected the world

#111

Post by shrubble »

mrkramer wrote: post #43

At the end of the day, backdoors in the open-source software projects will be caught sooner or later, the problem are backdoors in closed source projects ala NSA backdoors. To this day, I'm not completely sure if my Windows machine is secure or not. I remember Gates once said that governments in the early days of Windows demanded from Microsoft to show them the source code of Windows but even that is not enough since…

Microsoft was the very first to cooperate with the PRISM program...see the 2nd image here https://www.theguardian.com/world/2013/jun/06/us-tech-giants...

Re: What we know about the xz Utils backdoor that almost infected the world

#112

Post by [deleted] »

EdiX wrote: post #19

My personal takeaways from this: 1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar. 1a. As a consequence of (1) autogenerated artifacts should always be committed. 2. Autogenerated artifacts that everyone pagedowns over during code reviews is a…

[deleted]

Re: What we know about the xz Utils backdoor that almost infected the world

#113

Post by [deleted] »

mrkramer wrote: post #43

At the end of the day, backdoors in the open-source software projects will be caught sooner or later, the problem are backdoors in closed source projects ala NSA backdoors. To this day, I'm not completely sure if my Windows machine is secure or not. I remember Gates once said that governments in the early days of Windows demanded from Microsoft to show them the source code of Windows but even that is not enough since…

[deleted]

Re: What we know about the xz Utils backdoor that almost infected the world

#114

Post by Denvercoder9 »

aerhardt wrote: post #106
Denvercoder9 wrote: post #93

Earlier quoted context omitted.

> Like, meeting someone at several dev conferences should be a requirement at the very least. This is utterly and completely unfeasible. Most open source maintainers, especially those that are struggling and are pressured to hand-off maintenance, don't have the time, means and will to travel to meet up with prospective co-maintainers, not just once but multiple times. In practice it would just result in projects gett…

You could probably get about 80% of the job done with just 20% of the work. I’m not in OSS but I hire technical people remotely, and I know many people that do. Some consultant friends have caught blatant scams within the first couple of rounds of interviews on Zoom.

Interviewing is a different situation though, because you start having essentially no relationship with the interviewee, and you haven't seen their work. OSS projects don't just add everyone that asks as a co-maintainer. Usually it's someone that has contributed to the project for a while already, and through that has shown they understand the code, are capable of improving it, and can make sensible decisions about the road to take.

Re: What we know about the xz Utils backdoor that almost infected the world

#115

Post by dcow »

EdiX wrote: post #19

My personal takeaways from this: 1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar. 1a. As a consequence of (1) autogenerated artifacts should always be committed. 2. Autogenerated artifacts that everyone pagedowns over during code reviews is a…

Not agreeing or disagreeing, just curious how you draw conclusion (4)? This attack has nothing to do with systemd or its ecosystem etc.

Re: What we know about the xz Utils backdoor that almost infected the world

#116

Post by xorcist »

EdiX wrote: post #19

My personal takeaways from this: 1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar. 1a. As a consequence of (1) autogenerated artifacts should always be committed. 2. Autogenerated artifacts that everyone pagedowns over during code reviews is a…

Re: 1. People keep saying this. We should stop distributing tarballs. It's an argument that completely ignores why we have release artifacts in the first place. A release artifact contains more than just autoconf scripts.

There can be many reasons to include binary blobs in a release archive. Game resources, firmware images, test cases. There was today a comment that mpv includes parts of media files generated with proprietary encoders as test cases. That's good, not bad.

The well maintained library sqlite is everywhere, and has an excellent test suite. They release not one but two tarballs with every release, for different stages of compilation. It would be trivial to stop doing this, but it would make maintaining packages more work, which does nothing to improve security.

The reason Debian builds from curated tarballs are because they are curated by a human, and signed with a well known key. They could certainly build from git instead. But would that improve the situation? Not all projects sign their release tags. And for those that do, it is more likely to be automated. We the collective want changes to be vetted first by the upstream maintainer, then by the package maintainer, and would prefer these entities to be unrelated.

This time the process was successfully attacked by a corrupt upstream maintainer, but that does not mean we should do away with upstream maintainers. Several backdoor attempts have been stopped over the years by this arrangement and that process is not something we should throw away without careful consideration.

The same improvements we have been talking about for years must continue: We should strive for more reproducible builds. We should strive for lower attack surface and decrease build complexity when possible. We should trust our maintainers, but verify their work.

Re: What we know about the xz Utils backdoor that almost infected the world

#117

Post by haswell »

AndyMcConachie wrote: post #102
EdiX wrote: post #19

My personal takeaways from this: 1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar. 1a. As a consequence of (1) autogenerated artifacts should always be committed. 2. Autogenerated artifacts that everyone pagedowns over during code reviews is a…

[flagged]

Let’s step away from the extremist position and there’s an interesting problem underneath.

If a company or government organization is hiring engineers who will be responsible for critical code, they will undergo background checks at a minimum to ensure they are not an obvious threat to the organization. This isn’t about “country of origin”, but about the criminal history and ties of the individual regardless of origin.

In a government setting, security clearances will be required on top of basic background checks.

The FOSS community doesn’t have the tools to do this kind of screening, and arguably the openness of the community is what makes it successful.

But the uncomfortable reality is that there are indeed malicious actors, and the community doesn’t currently have a mechanism to proactively identify them and instead relies on discovering the results of their malicious behavior.

I don’t claim to know the solution, or if there even is one, but the existence of this comment thread is exhibit A for why we need to be thinking hard about how to proceed as a community.

FOSS projects are in the big leagues now, and will continue to come under threat from increasingly sophisticated actors.

Re: What we know about the xz Utils backdoor that almost infected the world

#118

Post by gunapologist99 »

redserk wrote: post #92
lenerdenator wrote: post #90

Earlier quoted context omitted.

I think you could interpret this as "you need to know, personally, the party you're handing this off to, and make reasonable judgments as to whether or not they could be easily compromised by bad actors". Like, meeting someone at several dev conferences should be a requirement at the very least.

1) Not everyone (current and potential future maintainers) has the time to go to dev conferences. 2) Simply meeting IRL is a terrible proxy for credibility.

> 2) Simply meeting IRL is a terrible proxy for credibility.

Disagree; trust your intuition, but you can never do that if you never meet IRL.

Also, it's not racist or xenophobic to recognize that some countries exercise nearly complete control over their citizens (and sometimes indirectly over non-citizens), and that those people could be putting themselves at extreme personal risk by disobeying those dictates (assuming they did disagree, which doesn't seem to be a given)

Re: What we know about the xz Utils backdoor that almost infected the world

#119

Post by retrac »

AndyMcConachie wrote: post #102
EdiX wrote: post #19

My personal takeaways from this: 1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar. 1a. As a consequence of (1) autogenerated artifacts should always be committed. 2. Autogenerated artifacts that everyone pagedowns over during code reviews is a…

[flagged]

I read the comment as -- we shouldn't hand control of valuable open source projects over to probable operatives of government security services. (Indeed, as many have mentioned, US intelligence might be behind this.)

Do you disagree with that? Or do you think OP meant something different? Because if they did it went right over my head.

Re: What we know about the xz Utils backdoor that almost infected the world

#120

Post by jmclnx »

glandium wrote: post #6
farmdve wrote: post #3

Earlier quoted context omitted.

And I think people should now look at all oddities with Valgrind. Since that is how the issue got discovered. And then look at the problematic library and look for similar outliers of fake personas taking over a project. It seems it is common practice for people to ignore these errors.

Do you remember the Debian openssl flaw? Okay, it's almost 20 years old now, so you may have forgotten, or you could be too young, I don't know. But it was caused by someone attempting to fix an oddity found by valgrind. https://blogs.fsfe.org/tonnerre/archives/24

I remember this and the like is a good write-up, thanks for the link. I have see things like this over the past 30+ years. So a couple of Items to add:

* Comment the hell out of hidden logic like this. Explain why nor what :)

* Better yet, even though that uninitialized buffer helped with performance. These days it would be better to take the hit and add a random initialization of that buffer. Maybe read /dev/urandom or some other thing.

You do not know who will come along after you, so try and make things explicit.

Post reply on HN