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

XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

bsky.app

Post reply on HN
Print view View original

461–470 of 862 posts

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#461

Post by willbush »

lettergram wrote: post #423
userbinator wrote: post #402

Earlier quoted context omitted.

That level of sophistication is certainly intentional.

That’s not an explanation about exactly how intention was derived. I suppose I’m asking for the chain of events that led to the conclusion. I see lots of technical hot takes for how something could work, with no validation it does, nor intent behind it. I’d like to understand what steps we know were taken and how that presents itself.

I think you're probably missing a lot context about the situation. Here's some useful links https://x0f.org/@FreePietje/112187047353892463 also https://gynvael.coldwind.pl/?lang=en&id=782

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#462

Post by zeven7 »

imiric wrote: post #429
tigerlily wrote: post #370

As a de facto maintainer of an obscure open source game, I see devs come and go. I just merge all the worthwhile contributions. Some collaborators go pretty deep with their features, with a variety of coding styles, in a mishmash of C and C++. I'm not always across the implementation details, but in the back of my mind I'm thinking, man, anyone could just code up some real nasty backdoor and the project would be scre…

The late author of ZeroMQ, Pieter Hintjens, advocated for a practice called Optimistic Merging[1], where contributions would be merged immediately, without reviewing the code or waiting for CI results. So your approach of having lax merging guidelines is not far off. While I can see the merits this has in building a community of contributors who are happy to work on a project, I always felt that it opens the project…

> The problem with xz wasn't a small community; it was no community. A single malicious actor got control of the project, and there was little oversight from anyone else.

So because of this a lot of other highly used software was importing and depending on unreviewed code. It's scary to think how common this is. The attack surface seems unmanageable. There need to be tighter policies around what dependencies are included, ensuring that they meet some kind of standard.

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#463

Post by colejohnson66 »

zeven7 wrote: post #462
imiric wrote: post #429

Earlier quoted context omitted.

The late author of ZeroMQ, Pieter Hintjens, advocated for a practice called Optimistic Merging[1], where contributions would be merged immediately, without reviewing the code or waiting for CI results. So your approach of having lax merging guidelines is not far off. While I can see the merits this has in building a community of contributors who are happy to work on a project, I always felt that it opens the project…

> The problem with xz wasn't a small community; it was no community. A single malicious actor got control of the project, and there was little oversight from anyone else. So because of this a lot of other highly used software was importing and depending on unreviewed code. It's scary to think how common this is. The attack surface seems unmanageable. There need to be tighter policies around what dependencies are incl…

As always, there's a relevant XKCD: #2347.[0] It's frightening how much of modern infrastructure depends on vulnerable systems.

[0]: https://xkcd.com/2347/

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#464

Post by jamwil »

SV_BubbleTime wrote: post #373
tialaramex wrote: post #355

Earlier quoted context omitted.

Private key. In cryptography we distinguish keys which are symmetric (needed by both parties and unavailable to everyone else) as "Secret" keys, with the pair of keys used in public key cryptography identified as the Private key (typically known only to one person/ system/ whatever) and Public key (known to anybody who cares) Thus, in most of today's systems today your password is a secret . You know your password an…

> You know your password and so does the system authenticating you. Nitpick, but no it shouldn’t. The HASH of your password is recorded. You never submit your password, you submit that hash and they compare it. The difference is that there is no two passwords that collide; but there are hashes that may. And that two equal passwords from two equal users are not necessarily accessible to someone with the hash list beca…

More an implementation detail than a conceptual distinction, though.

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#465

Post by solardev »

cayde wrote: post #401
solardev wrote: post #305

Earlier quoted context omitted.

Isn't it pretty standard practice to salt and hash the password client-side before sending it over the wire?

No, usually it's sent in plain text to the server, however encapsulated.

Wow, really? Ten years ago, it was drilled into me to never send a password like that, especially since the server shouldn't have the plain version anyway (so no reason for the client to send it).

https://owasp.org/www-community/OWASP_Application_Security_F... says "Salted hash for transmitting passwords is a good technique. This ensures that the password can not be stolen even if the SSL key is broken."

I didn't want to believe you, but man, I just checked a few websites in the network inspector... and it seems like GMail, Hackernews, Wordpress, Wix, and Live.com all just sent it in plaintext with only SSL encryption :(

That's a bit disappointing. But TIL. Thanks for letting me know!

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#466

Post by eacapeisfutuile »

zeven7 wrote: post #462
imiric wrote: post #429

Earlier quoted context omitted.

The late author of ZeroMQ, Pieter Hintjens, advocated for a practice called Optimistic Merging[1], where contributions would be merged immediately, without reviewing the code or waiting for CI results. So your approach of having lax merging guidelines is not far off. While I can see the merits this has in building a community of contributors who are happy to work on a project, I always felt that it opens the project…

> The problem with xz wasn't a small community; it was no community. A single malicious actor got control of the project, and there was little oversight from anyone else. So because of this a lot of other highly used software was importing and depending on unreviewed code. It's scary to think how common this is. The attack surface seems unmanageable. There need to be tighter policies around what dependencies are incl…

Does that mean we don’t look into changes in dependencies at all when bumping them?

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#467

Post by Animats »

CSMastermind wrote: post #130
moomoo11 wrote: post #96

Earlier quoted context omitted.

Is the person Jia who did this PR a malicious actor?

The person who submitted the PR, JiaT75, is. The person who approved and merged it is not.

Has that person been found yet?

Does this problem require cops, or an airstrike?

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#468

Post by db48x »

onedognight wrote: post #38
jeroenhd wrote: post #12

Earlier quoted context omitted.

> However, since this is an RCE in the context of e.g. an sshd process itself, this means that sshd running as root would allow the payload to itself run as root. With the right sandboxing techniques, SELinux and mitigations could prevent the attacker from doing anything with root permissions. However, applying a sandbox to an SSH daemon effectively is very difficult.

> With the right sandboxing techniques, SELinux and mitigations could prevent the attacker from doing anything with root permissions. Please review this commit[0] where the sandbox detection was “improved”. [0] https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2...

Yes, but don't forget that there are different kinds of sandboxes. SELinux never needs the cooperation of any program running on the system in order to correctly sandbox things. No change to Xz could ever make SELinux less effective.

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#469

Post by benreesman »

tigerlily wrote: post #370

As a de facto maintainer of an obscure open source game, I see devs come and go. I just merge all the worthwhile contributions. Some collaborators go pretty deep with their features, with a variety of coding styles, in a mishmash of C and C++. I'm not always across the implementation details, but in the back of my mind I'm thinking, man, anyone could just code up some real nasty backdoor and the project would be scre…

It never ceases to amaze me how great of lengths companies go to round securing the perimeter of the network but then have engineering staffs that just routinely brew install casks or vi/emacs/vscode/etc extensions.

Rust is arguably the programming language and/or community with the most secure set of defaults that are fairly impossible to get out of, but even at “you can’t play games with pointers” levels of security-first, the most common/endorsed path for installing it (that I do all the time because I’m a complete hypocrite) is:

https://www.rust-lang.org/tools/install

and that’s just one example, “yo dawg curl this shit and pipe it to sh so you can RCE while you bike shed someone’s unsafe block” is just muscle memory for way too many of us at this point.

Re: XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

#470

Post by pierat »

Karrot_Kream wrote: post #455
Dalewyn wrote: post #424

Earlier quoted context omitted.

I think drunk driving being an oil that keeps society lubricated cannot and should not be understated. Yes, drunk driving kills people and that's unacceptable. On the other hand, people going out to eat and drink with family, friends, and co-workers after work helps keep society functioning, and the police respect this reality because they don't arrest clearly-drunk patrons coming out of restaurants to drive back hom…

This is such a deeply American take that I can't help but laugh out loud. It's like going to a developing nation and saying that, while emissions from two stroke scooters kills people there's no alternative to get your life things done.

You can laugh out loud all you want, but there are mandatory parking minimums for bars across the USA.

Yes, bars have parking lots, and a lot of spaces.

The intent is to *drive* there, drink and maybe eat, and leave in some various state of drunkenness. Why else would the spacious parking lots be required?

Post reply on HN