Live data from Hacker News

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

arstechnica.com

241–250 of 336 posts

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

#241
post #78

Earlier quoted context omitted.

> Re the falsifying working hours, wouldn’t these boffins be able to automate Git commits at certain times or even pass instructions to another team who is working the late night shift to post these changes etc. Is it possible? Definitely. But that's extremely rare, especially if you want to keep a relatively natural pattern for the commits and replies. You'd basically have to have a team of devs working at really od…

> Is it possible? Definitely. But that's extremely rare, especially if you want to keep a relatively natural pattern for the commits and replies. What sort of nonsense is this? Have you ever actually known any software developers? A huge number of them keep odd hours, moreso in the infosec sphere. They wouldn't need to automate anything, just start working hours that match the timezone that they're faking... If it re…

I agree. I don’t follow the time zone of the country I live in as I work remote. Haven’t seen the sun in a while. Probably not healthy.

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

#242
post #11

I’m guessing the original maintainer of xz handed responsibilities to Jia Tan without ever seeing him/her or at least sharing a phone call. Is that common to only communicate only through email/github? I guess some maintainers of open source projects will be more cautious after this story.

Our goodwill is being used against us. Suppose you have a chat with them and see that they're Chinese. What are your next actions? If you exclude them then that's racist right? I don't have answers

Adding on to that, it might be difficult to differentiate between people from China vs Taiwan/Singapore/etc and since people are generally anonymous online, they can use any name they want

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

#243
post #135

Earlier quoted context omitted.

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.

>I’m not in OSS but I hire technical people remotely, [...] interviews on Zoom. Different situations with different incentives and psychology: - potential to receive money : job candidates are willing to get on Zoom calls or meet in person because they want a paycheck. - no money involved & volunteer for free : potential open source contributors are not interested in getting on Zoom calls for $0 pay.

Also, while I'm not a lawyer, and in general the bar is very high to criminally prosecute an employee for doing "a bad job," I wouldn't be surprised if there are major jurisdictions where intentionally backdooring your employer's code could land you in prison.

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

#244

Earlier quoted context omitted.

So all of Fabrice Bellard's projects ( https://bellard.org/ ) should not exist?

if these projects have any value, someone will clone them to a public repository.

While introducing minor changes to the build system scripts, you mean?

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

#245
post #202

Earlier quoted context omitted.

I think the message would more likely be "don't use open source and pay for closed source" than "give money to open source and cross your fingers that it does something".

I mean Okta has shown us that paying for closed source does not imply higher quality or more secure software.

Also F5 or Citrix: some of their core security products had 90s-style C exploits and other signs of development practices well behind the times - roughly at the level of going to surgery and seeing your surgeon not washing their hands in the bathroom.

https://www.cisa.gov/guidance-addressing-citrix-netscaler-ad...

https://www.mandiant.com/resources/blog/session-hijacking-ci...

https://www.fortinet.com/blog/threat-research/defending-agai...

https://www.cisa.gov/news-events/cybersecurity-advisories/aa...

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

#246
post #92

Earlier quoted context omitted.

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 (assum…

> 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)

This is true even when they are no longer in that country. Some governments are known to threaten the family of expatriates. "Do this for us or mom and dad are going to spend the rest of their soon to be short lives doing hard labor" is a pretty tough threat to ignore.

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

#247

Earlier quoted context omitted.

It does not. OpenSSH pulled in libsystemd to provide startup notification. Libsystemd pulled in liblzma. No code from liblzma normally ends up in OpenSSH. But because it is built as a dependency for libsystemd, it's build scripts are ran in the same environment as libsystemd, and OpenSSH. The attack payload was hidden as an obfuscated binary blob in the liblzma tests directory, masqueraded as a compression test case.…

> pulled in libsystemd to provide startup notification This seems sort of fine (although...why can't said notification be done by writing simple text to a pipe/file/socket?), but the library shouldn't be some kitchen-sink thing that links to the universe of attack surface.

Even more, why can't information like this be passed up the call chain as integer return codes? That scheme has been a perfectly functional for decades, all the way back to at least BSD's rc scripts, maybe before.

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

#248

Earlier quoted context omitted.

> 1a. As a consequence of (1) autogenerated artifacts should always be committed. Why don't object files and binaries count as autogenerated artifacts? Should we commit those to the repo too? Where is the line between an artifact that should be committed, and one that shouldn't be? > 4. Libsystemd is a problem for the ecosystem. libc will dynamically load libnss-* on a lot of platforms, some of which can link to a bu…

> 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?

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

#250
post #164

Earlier quoted context omitted.

> pulled in libsystemd to provide startup notification This seems sort of fine (although...why can't said notification be done by writing simple text to a pipe/file/socket?), but the library shouldn't be some kitchen-sink thing that links to the universe of attack surface.

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.

Post reply on HN