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

541–550 of 862 posts

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

#541

Post by kbenson »

someguydave wrote: post #380
wepple wrote: post #99

Earlier quoted context omitted.

I expect a lot of people will be doing a whole lot of thinking along these lines over the next months. Code review? Some kind of behavioral analysis? IMO the call to system() was kind of sloppy, and a binary capabilities scanner could have potentially identified a path to that.

Dynamic linking was a mistake and should be eliminated

That this was dynamically linked is the least interesting thing about it IMO. It was a long term I filtration where they got legitimate commit access to a well used library.

If xz was statically linked in some way, or just used as an executa Le to compress something (like the kernel), the same problems exist and no dynamic linking would need to be involved.

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

#542

Post by hwaccel »

solardev wrote: post #465
cayde wrote: post #401

Earlier quoted context omitted.

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 wan…

> 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'm a little confused with this recommendation

How server is supposed to verify user's password in this case? Store the same hash with exactly the same salt in the database, effectively making the transmitted salted hash a cleartext password?

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

#543

Post by Dalewyn »

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.

It certainly isn't just America, though we're probably certainly the most infamous example.

I was in France for business once in the countryside (southern France), and the host took everyone (me, their employees, etc.) out to lunch. Far as I could tell it was just an everyday thing. Anyway, we drove about an hour to a nearby village and practically partied for a few hours. Wine flowed like a river. Then we drove back and we all got back to our work. So not only were we drunk driving, we were drunk working. Even Americans usually don't drink that hard; the French earned my respect that day, they know how to have a good time.

Also many times in Japan, I would invite a business client/supplier or a friend over for dinner at a sushi bar. It's not unusual for some to drive rather than take the train, and then of course go back home driving after having had lots of beer and sake.

Whether any of us like it or not, drunk driving is an oil that lubricates society.

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

#544

Post by semiquaver »

treasy wrote: post #328
semiquaver wrote: post #304

Earlier quoted context omitted.

I’ll admit to not being an expert in SELinux, but it seems like an impossibly leaky proposition. Root can modify systemd startup files, so just do that in a malicious way and reboot the system. that context won’t be propagated. And if you somehow prohibit root from doing that by SELinux policy then you end up with a system that can’t actually be administered. [edit: sibling sweetjuly said it better than I could. I do…

Selinux domains are uncoupled from Linux users. If sshd does not have Selinux permissions to edit those files it will simply be denied. Even if sshd is run as root

Which amounts to the un-administerable system I mentioned. If it’s not possible to modify systemd config files using ssh, what happens when you need to edit them?

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

#545

Post by 1oooqooq »

delfinom wrote: post #30
TheBlight wrote: post #24

Earlier quoted context omitted.

Whoever this was is going after a government or a crypto exchange. Don't think anything else merits this effort.

Otoh, maybe they just wanted to create a cryptomining farm. Lol. Don't underestimate the drive some people have to make a buck.

people downvoting you already forgot the cia fundraiser in the 80s...

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

#546

Post by kbenson »

anonymous-panda wrote: post #506
imiric wrote: post #478

Earlier quoted context omitted.

> There need to be tighter policies around what dependencies are included, ensuring that they meet some kind of standard. This is why it's a good practice to minimize the amount of dependencies, and add dependencies only when absolutely required. Taking this a step further, doing a cursory review of each dependency, seeing the transitive dependencies it introduces, are also beneficial. Of course, it's impractical to…

That’s not an effective idea for the same reason that lines of code is not a good measure of productivity. It’s an easy measure to automate but it’s purely performative as it doesn’t score the qualitative value of any of the maintenance work. At best it encourages you to use only popular projects which is its own danger (software monoculture is cheaper to attack) without actually resolving the danger - this attack is…

> We need to focus on real ways to improve the supply chain. eg having repeatable idempotent builds with signed chain of trusts that are backed by real identities that can be prosecuted and burned.

So, either no open source development because nobody will vouch to that degree for others, or absolutely no anonymity and you'll have to worry about anything you provide because of you screw up and introduce a RCE all of a sudden you'll have a bunch of people and companies looking to say it was on purpose so they don't have to own up to any of their own poor practices that allowed it to actually be executed on?

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

#547

Post by 1oooqooq »

dmonitor wrote: post #342
dolmen wrote: post #234

Earlier quoted context omitted.

Using an SSH key used with GitHub for other purposes than GitHub is not a good practice (even if it's common). https://github.com/dolmen/github-keygen

I’m confused. I make a unique private key for each machine I use. How is using that machine-specific key on multiple hosts insecure?

edit your .ssh/config.

add one Host entry per domain.

on the end of the file add one catch all host rule with IdentityFile /dev/null

otherwise you're sending default key names to all hosts.

...and you are not sending id_rsa.pub to every single place you add a key, like most guides suggests, right? right?

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

#548

Post by kubb »

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…

What’s the game?

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

#549

Post by [deleted] »

danparsonson wrote: post #536
someplaceguy wrote: post #513

Earlier quoted context omitted.

> if you're using password auth, and you are tricked into connecting to a malicious server, that server now has your plaintext password and can impersonate you to other servers. Why would the password be sent in plaintext instead of, say, sending a hash of the password calculated with a salt that is unique per SSH server? Or something even more cryptographically sound. In fact, passwords in /etc/shadow already do hav…

If the hash permits a login then having a hash is essentially equivalent to having a password. The malicious user wouldn't be able to use it to sudo but they could deploy some other privilege escalation once logged in.

[deleted]

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

#550

Post by numpad0 »

Deathcrow wrote: post #540
ghostpepper wrote: post #189

Earlier quoted context omitted.

> beyond the (presumably failed) login attempt There is some evidence it's scrubbing logs so we might not even have that.

Is there really a failed login attempts? If it never calls the real functions of ssh in case of their own cert+payload why would sshd log anything or even register a login attempt? Or does the backdoor function hook in after sshd already logged stuff?

Depending on log level, isn't there going to be lines up to receiving the payload?
Post reply on HN