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

451–460 of 862 posts

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

#451

Post by tw04 »

fredamaral wrote: post #447
tw04 wrote: post #446

Earlier quoted context omitted.

What exactly is a CLA going to do to a CCP operative (as appears to be the case with xz)? Do you think the party is going to extradite one of their state sponsored hacking groups because they got caught trying to implement a backdoor? Or do you think they don’t have the resources to fake an identity?

case closed. you are right... could of course make the things a bit more difficult for someone not backed by a state sponsor. but if that's the case, you are right.

Sadly the only way to even have a chance of fighting this is to insist on new contributors being vetted in person, and even that won’t be fool-proof.

It’s also not scalable and likely won’t ever happen, but it’s the only solution I can come up with.

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

#452

Post by imiric »

p-e-w wrote: post #392
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…

> 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 screwed That's true of course, but it's not a problem specific to software. In fact, I'm not even sure it's a "problem" in a meaningful sense at all. When you're taking a walk on a forest road, any car that comes your way could just run you over. Chances are the driver would never get caught. Th…

> When you're taking a walk on a forest road, any car that comes your way could just run you over. Chances are the driver would never get caught. There is nothing you can do to protect yourself against it.

Sure you can. You can be more vigilant and careful when walking near traffic. So maybe don't have headphones on, and engage all your senses on the immediate threats around you. This won't guarantee that a car won't run you over, but it reduces the chances considerably to where you can possibly avoid it.

The same can be said about the xz situation. All the linters, CI checks and code reviews couldn't guarantee that this wouldn't happen, but they sure would lower the chances that it does. Having a defeatist attitude that nothing could be done to prevent it, and that therefore all these development practices are useless, is not helpful for when this happens again.

The major problem with the xz case was the fact it had 2 maintainers, one who was mostly absent, and the other who gradually gained control over the project and introduced the malicious code. No automated checks could've helped in this case, when there were no code reviews, and no oversight over what gets merged at all. But had there been some oversight and thorough review from at least one other developer, then the chances of this happening would be lower.

It's important to talk about probabilities here instead of absolute prevention, since it's possible that even in the strictest of environments, with many active contributors, malicious code could still theoretically be merged in. But without any of it, this approaches 100% (minus the probability of someone acting maliciously to begin with, having their account taken over, etc.).

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

#453

Post by 4death4 »

martinohansen wrote: post #207

Imagine a future where state actors have hundreds of AI agents fixing bugs, gaining reputation while they slowly introduce backdoors. I really hope open source models succeed.

Imagine a world where a single OSS maintainer can do the work of 100 of today’s engineers thanks to AI. In the world you describe, it seems likely that contributors would decrease as individual productivity increases.

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

#454

Post by Aloisius »

mik1998 wrote: post #233
dolmen wrote: post #182

Earlier quoted context omitted.

Do you have some scripts publicly available to reproduce your research?

I used the git repo at https://git.phial.org/d6/xz-analysis-mirror/commits/branch/m... and simply did git log --format=%cd --author="Jia Tan" and then processed it a bit with gnuplot. Should not be difficult to reproduce this graph, but I am not too much of a gnuplot wizard so I first preprocessed this into some different files in a REPL. Don't have the full code of what I did but it should not be difficult to reprod…

You should include git log --committer=Jia too as they committed what appears to be their other fake account's changes as well.

Also there are separate author times vs. commit times.

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

#455

Post by Karrot_Kream »

Dalewyn wrote: post #424
consumer451 wrote: post #419

Earlier quoted context omitted.

But there have to be specific trade-offs, in each case. I am reminded of the words of "a wise man." https://news.ycombinator.com/item?id=39874049 Captain's Log: This entire branch of comments responding to OP is not helping advance humanity in any significant way. I would appreciate my statement of protest being noted by the alien archeologists who find these bits in the wreckage of my species.

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.

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

#456

Post by CanaryLayout »

kbolino wrote: post #249
quotemstr wrote: post #244

Earlier quoted context omitted.

Doesn't matter. A malicious sshd able to run commands arbitrary users can just run malicious commands as those users. We'd need something more like a cryptographically attested setreuid() and execve() combination that would run only commands signed with the private key of the intended user. You'd want to use a shared clock or something to protect against replay attacks

Yes, this won't directly protect against an attacker whose goal is to create a botnet, mine some crypto on your dime, etc. However, it will protect against corruption of the O/S itself and, in tandem with other controls, can limit the abilities an attacker has, and ensure things like auditing are still enforced (which can be tied to monitoring, and also used for forensics). Whether it's worth it or not depends on cir…

even easier is to STOP HOSTING SSHD ON IPV4 ON CLEARNET

at minimum, ipv6 only if you absolutely must do it (it absolutely cuts the scans way down)

better is to only host it on vpn

even better is to only activate it with a portknocker, over vpn

even better-better is to set up a private ipv6 peer-to-peer cloud and socat/relay to the private ipv6 network (yggdrasil comes to mind, but there's other solutions to darknet)

your sshd you need for server maintenance/scp/git/rsync should never be hosted on ipv4 clearnet where a chinese bot will find it 3 secs after the route is established after boot.

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

#458

Post by taberiand »

mendyberger wrote: post #435
p-e-w wrote: post #392

Earlier quoted context omitted.

> 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 screwed That's true of course, but it's not a problem specific to software. In fact, I'm not even sure it's a "problem" in a meaningful sense at all. When you're taking a walk on a forest road, any car that comes your way could just run you over. Chances are the driver would never get caught. Th…

Difference is that software backdoors can effect billions of people. That driver on the road can't effect too many without being caught. In this case, had they been a bit more careful with performance, they could have effected millions of machines without being caught. There aren't many cases where a lone wolf can do so much damage outside of software.

A few more issues like this in crucial software and we might actually see the big companies stepping up to fund that kind of care and attention.

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

#459

Post by nrdvana »

saltcured wrote: post #180
semiquaver wrote: post #100

Earlier quoted context omitted.

Could you explain how SELinux could ever sandbox against RCE in sshd? Its purpose is to grant login shells to arbitrary users, after all.

You could refactor sshd so most network payload processing is delegated to sandboxed sub-processes. Then an RCE there has less capabilities to exploit directly. But, I think you would have to assume an RCE can cause the sub-process to produce wrong answers. So if the answers are authorization decisions, you can transitively turn those wrong answers into RCE in the normal login or remote command execution context. But…

That just raises the hurdle for the attacker. The attacker in this case has full control to replace any function within ssh with their own version, and the master process of sshd will always need the ability to fork and still be root on the child process before dropping privileges. I don't see any way around that. They only needed to override one function this time, but if you raise the bar they would just override more functions and still succeed.
Post reply on HN