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

261–270 of 336 posts

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

#261

Post by marcosdumay »

Karellen wrote: post #248
marcosdumay wrote: post #229

Earlier quoted context omitted.

> Is libc a problem for the ecosystem? Absolutely yes. And also the size of the kernel. Those two currently have a much better guaranteed quality than systemd, thus systemd is a much more pressing issue. But they don't stop being a problem just because they are not the largest one.

> [libc and the kernel] currently have a much better guaranteed quality than systemd, What are you basing that on?

Historical behavior.

There doesn't exist anything else this could be based on.

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

#262

Post by DiggyJohnson »

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]

You are accusing GP of something very serious, and while I see the direction you're coming from, I don't understand how accusations or insinuations like theone you're providing here are acceptable without significant additional justification or explanation.

Does that make sense? Do you think there's a chance that the person you're replying to is "not racist"?

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

#263

Post by lenerdenator »

clnhlzmn wrote: post #198
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.

This is really not the responsibility of unpaid developers.

Big vendors should pay to get to know them, because they're the ones making the money off of the developers' work, but "I don't want to meet anybody and want to just manage the project" is the FOSS version of "just trust me bro".

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

#264

Post by growse »

marcosdumay wrote: post #250
growse wrote: post #164

Earlier quoted context omitted.

The notification can be done by sending some data to $NOTIFY_SOCKET. That's all sd_notify does.

Notice that the protocol specification is way more complex than that, and already changed since systemd was released. All the library does is sending some data through the socket, but that's not at all what the docs tell you to do.

The docs could be better, sure, but where did this idea what "interfaces can never be changed" come from?

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

#265

Post by lelanthran »

andrewstuart wrote: post #41

I don’t suppose this will lead the us govt to invest heavily in the open source projects behind SSH?

> I don’t suppose this will lead the us govt to invest heavily in the open source projects behind SSH?

The cynic in me wants to know, what makes you think Jia Tan wasn't one of their "investments"?

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

#266

Post by cozzyd »

usrusr wrote: post #103

What I haven't seen discussed much is the linking mechanism that allowed the lib to hook into RSA_public_decrypt. Plenty of talk about what could or could not be achieved by even more process separation and the like, but little about that function call redirect. Could it be possible to establish a way to link critical components like the code for incoming ssh with libraries in some tiered trust way? "I trust you when…

would it be sufficient to monitor the symbols called by ltrace, somehow?

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

#267

Post by dan_mctree »

mrkramer wrote: post #49
yosito wrote: post #4

Are we ever going to figure out who Jia Tan is?

Are we ever going to figure out who Satoshi is? Probably not anytime soon but we can look for clues. Jia was obviously interested in OSS security and fuzzing[0] but my wild guess is that s/he is not a state actor. I would rather assume s/he is a hobbyist opportunistic hacker who got trigged by the thought "If I can exploit this, why not?". I assume he intended to build a botnet and do whatever s/he came up with. The…

Possibly if language use fingerprinting ever becomes reliable enough to be able to connect multiple online pseudonyms together. That'd be a fun time

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

#268

Post by Karellen »

marcosdumay wrote: post #261
Karellen wrote: post #248

Earlier quoted context omitted.

> [libc and the kernel] currently have a much better guaranteed quality than systemd, What are you basing that on?

Historical behavior. There doesn't exist anything else this could be based on.

Does systemd have a historical record of its defect rate being significantly greater than that of the kernel/glibc?

I just checked Coverity scans, and the most recent defect densities appear to be:

    kernel : 0.59
    glibc  : 0.54
    systemd: 0.04
which actually looks pretty good for systemd. Is there some other analysis you're basing this off? Or are the current rates atypical, and systemd used to be a lot worse?

https://scan.coverity.com/projects/linux

https://scan.coverity.com/projects/gnu-c-library-glibc

https://scan.coverity.com/projects/systemd

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

#269

Post by humansareok1 »

mikedelfino wrote: post #186
humansareok1 wrote: post #130

This represents a massive failure of the Open Source model and it's worth thinking carefully about as more and more people advocate for fully open source AI models. People could spend a lot of time on token safety features only to have them backdoored by a sneaky PR and it's not clear what level of damage this could cause in the near future.

Isn't it the opposite, though? The whole thing was caught precisely because it was open source. Sure, you can argue that the vulnerability was introduced by a contributor, but what prevents the same thing from happening in a private repository, perpetrated by an actual employee? Especially if you consider that many vulnerabilities can be introduced with code more likely to pass as legitimate mistakes.

But it wasn't caught because it was open source? It was caught basically by chance by an engineer using the distro who admits they only caught it because of a series of coincidences.

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

#270

Post by mnau »

lenerdenator wrote: post #101
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…

Really, it starts before things get bad. This thing where - in the famous XKCD example - a single guy is thanklessly maintaining a project for 20 years in Nebraska needs to stop. Software libraries like these are no longer a one-person job. They can't be for the bus factor alone. Major projects like Linux distros or bigger foundations like Apache or Mozilla need to start harping on people hard to contribute to import…

> bigger foundations like Apache or Mozilla

What bigger foundations? Apache foundation has yearly revenue $2.1 million. Why do you think they reacted as they reacted to log4j? There are no resources.

Open source is running on fumes.

Post reply on HN