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

Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

github.com

Post reply on HN
Print view View original

421–430 of 500 posts

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#421

Post by iliane5 »

anarazel wrote: post #145
est31 wrote: post #59

Earlier quoted context omitted.

I doubt that if Google detected it with some internal tool, they'd reach out to Microsoft to hide their contribution. It was reported by an MS engineer who happens to be involved in another OSS project. MS is doing business with the US intelligence community, for example there is the Skype story: First, rumors that NSA offers a lot of money for people who can break Skype's E2E encryption, then MS buys Skype, then MS…

> It was reported by an MS engineer who happens to be involved in another OSS project. I view it as being OSS or postgresql dev that happens to work at microsoft. I've been doing the former for much longer (starting somewhere between 2005 and 2008, depending on how you count) than the latter (2019-12).

Just wanted to say thank you for your work and attention to detail, it's immensely valuable and we're all very grateful for it.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#422

Post by denton-scratch »

db48x wrote: post #370
gghffguhvc wrote: post #48

Is there anything actually illegal here? Like is it a plausible “business” model for talented and morally compromised developers to do this and then sell the private key to state actors without actually breaking in themselves or allowing anyone else to break in. Edit: MIT license provides a pretty broad disclaimer to say it isn’t fit for any purpose implied or otherwise.

I’m no lawyer, but it is at minimum tortuous interference.

Indeed. I think a lawyer would have written "tortious", there being no pain involved.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#423

Post by wholinator2 »

CommitSyn wrote: post #367
pxx wrote: post #353

Earlier quoted context omitted.

That's (a) not exploitable without the existence of a much higher-severity exploit -- sure you can clear the screen, but that's low impact (b) possible to trigger on other extant paths; see https://github.com/libarchive/libarchive/issues/2107 so it seems nothing new was introduced (c) kind of contrived to get to execute; you have to somehow fail to extract the archive but on the happy path you'll see a bunch of weird…

Is it possible it was part of a planned or current exploit chain, some other way it could have been utilized?

Yes, i think one thing we should learn from this is that suspicious code is suspicious code, and anyone asserting that some suspicious code cannot be exploited is suspicious themselves. I don't think we should inquisition half the industry, but i do think people should be a lot more careful about saying that one small exploitable thing definitely cannot be part of a larger exploit.

It's obvious, basically no one knows what's going on in the _vast_ majority of code running out systems these days. And even if you know 99% the attackers only need to be right once

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#424

Post by lyu07282 »

stingraycharles wrote: post #38
Alifatisk wrote: post #18

Earlier quoted context omitted.

For real, it's almost like a state-sponsored exploit. It's crafted and executed incredibly well, the performance issue feels like pure luck it got found.

I like the theory that actually, it wasn’t luck but was picked up on by detection tools of a large entity (Google / Microsoft / NSA / whatever), and they’re just presenting the story like this to keep their detection methods a secret. It’s what I would do.

While we are speculating, there was this case of university students trying to introduce malicious commits in the kernel in order to test open source to such attack vectors. Perhaps this was similar "research" by some students.

https://www.cnx-software.com/2021/04/22/phd-students-willful...

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#425

Post by bheadmaster »

misswaterfairy wrote: post #285
rst wrote: post #3

Earlier quoted context omitted.

Well, it's a POC against a re-keyed version of the exploit; a POC against the original version would require the attacker's private key, which is undisclosed.

Could the provided honeypot print out keys used in successful and unsuccessful attempts?

I don't think any (sane) client would sent its private key on login. Private key only serves as a "solver" of a puzzle created using the public key.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#426

Post by throw156754228 »

andybak wrote: post #418
throw156754228 wrote: post #416

Earlier quoted context omitted.

They removed the repo so only the attackers had access to the code and know how.

No. They obviously didn't do that so you're just being sarcastic but not actually making any point of your own in addition to that.

Intended levity, gee you sound miserable. Try some exercise in the mornings?

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#427

Post by londons_explore »

parl_match wrote: post #371
juitpykyk wrote: post #295

Earlier quoted context omitted.

You're talking as if securing a backdoor with public cryptography is some unimaginable feat of technology. It's literally a couple hours work.

Inserting a change like this as a one off would cause lots of scrutiny, which would probably get it detected. Instead, the bad actor spent years contributing to the project before dropping this. So, while writing the exploit might be a couple of hours work, actually pulling it off is quite a bit more difficult.

Plenty of open source maintainers spend only a few hours a month on their projects.

For many projects, that is enough to become the main contributor.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#428

Post by acdha »

acid__ wrote: post #341
acdha wrote: post #121

Earlier quoted context omitted.

Thanks! That’s a little disappointing since I would have thought that the way it hooked those functions could’ve been caught by a generic heuristic but perhaps that’s more common than I thought.

My experience from working in the security space is that all the tech is pretty un-sexy (with very good sales pitches), and none of it will save you from a nation-state attacker.

Same. I was hoping to be wrong in my cynicism but…

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#429

Post by NarcissistDev »

withinboredom wrote: post #412
ToneWashed wrote: post #410

Earlier quoted context omitted.

> It’s got me suspicious of build-time dependency we have in an open source tool, where the dependency goes out of its way to prefer xz and we even discovered that it installs xz on the host machine if it isn’t already installed — as a convenience. Kinda weird because it didn’t do that for any other dependencies. Have you considered reaching out to the maintainers of that project and (politely) asking them to explain…

> Have you considered reaching out to the maintainers of that project and (politely) asking them to explain? That's kind of a catch-22, right? They'd explain with a seemingly good answer if they did it for actual reasons. They'll still explain with a seemingly good answer if they did it for nefarious reasons. I don't have a good answer to this except to monitor this dependency and its changes.

They’d definitely have a great answer up their sleeves.

The crazy thing is the devs responsible for the XZ backdoor are among us and will likely be here on HN, downvoting comments which are getting close to the truth and upvoting each other.

The bad people are definitely here.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#430

Post by NarcissistDev »

j16sdiz wrote: post #405
bilekas wrote: post #385

Earlier quoted context omitted.

It is an obvious place for sure, but it also would have been picked up if the builds where a bit more transperant. That batch build script should have been questioned before approval.

By whom? The attacker have assumed the maintainer role. Nobody is reviewing.

There’s a severe and dangerous lack of paranoia in this dev space.

If I was letting someone maintain my codebase, I would 1 Billion percent be reviewing everything… if there was a binary added, I’d be building it myself and comparing the checksums.

Trust absolutely no-one. If you can give a close friend or a loved one a loan of money and it is so easy for them to never pay you back, it should be a reminder that devs you’ve never met are even more likely to scam you.

Post reply on HN