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

471–480 of 862 posts

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

#471

Post by ivlad »

amscanne wrote: post #312
londons_explore wrote: post #250

Earlier quoted context omitted.

I suspect I could have used this exact attack against 10,000 random SSH servers spread all over the world, and not be detected. Most people don't log TCP connections, and those that do don't go through their logs looking for odd certificates in ssh connections. And no common logging at the ssh/pam level would have picked this up. Your only chance is some sysadmin who has put 'tripwires' on certain syscalls like syste…

There is no ‘system()’ syscall, and fork/exec would be extremely common for opensshd — it’s what it does to spawn new shells which go on to do anything. I’m not arguing with the point, but this is a great place to hide — very difficult to have meaningful detection rules even for a sophisticated sysadmin.

This would be execve() that did not go through PAM dance and end up being privileged process.

I _think_ it’ll look very different in ps —-forest output.

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

#472

Post by OsrsNeedsf2P »

Randalthorro wrote: post #383
matrix_overload wrote: post #306

Earlier quoted context omitted.

Not necessarily. A frustrated developer posts about it, it catches attention of someone who knows how to use Ghidra et al, and it gets dug out quite fast. Except, with closed-source software maintained by a for-profit company, suck cockup would mean a huge reputational hit, with billions of dollars of lost market cap. So, there are very high incentives for companies to vet their devs, have proper code reviews, etc. B…

Absolutely not. Getting a job at any critical infrastructure software dev company is easier than contributing to the Linux kernel.

Can confirm. I may work at Meta, but I was nearly banned from contributing to an open source project because my commits kept introducing bugs.

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

#473

Post by cayde »

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…

If you want to hop into a rabbit hole, try taking look in Steam's login send the user and pass))

If TLS break then all is untrusted anyway! If you read hash as MITM you can replay it as pass equivalent and log in with hash, do not need knowledge of the original pass. You can just inject the script to exfilatrate original pass before hashing. CSP is broken, since you can edit header to give your own script a inline nonce. I think everything is reliant on TLS in end.

I think 10yr ago before TLS was 99%+ standard on all sites many people would come up with schemes, forums would md5 pass client side and send md5, all sorts were common. But now trust is in TLS.

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

#474

Post by p-e-w »

imiric wrote: post #452
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…

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

It's not defeatist to admit and accept that some things are ultimately out of our control. And more importantly, that any attempt to increase control over them comes with downsides.

An open source project that imposes all kinds of restrictions and complex bureaucratic checks before anything can get merged, is a project I wouldn't want to participate in. I imagine many others might feel the same. So perhaps the loss from such measures would be greater than the gain. Without people willing to contribute their time, open source cannot function.

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

#476

Post by godelski »

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…

Honestly this is why I think we should pay people for open source projects. It is a tragedy of the commons issues. All of us benefit a lot from these free software, and done for free. Pay doesn't exactly fix the problems directly, but they do decrease the risk. Pay means people can work on these full time instead of on the side. Pay means it is harder to bribe someone. Pay also makes the people contributing feel better and more like their work is meaningful. Importantly, pay signals to these people that we care about them. I think the big tech should pay. We know the truth is that they'll pass on the costs to us anyways. I'd also be happy to pay taxes but that's probably harder. I'm not sure what the best solution is and this is clearly only a part of a much larger problem, but I think it is very important that we actually talk about how much value OSS has. If we're going to talk about how money represents value of work, we can't just ignore how much value is generated from OSS and only talk about what's popular and well know. There are tons of critical infrastructure in every system you could think of (traditional engineering, politics, anything) that is unknown. We shouldn't just pay things that are popular. We should definitely pay things that are important. Maybe the conversation can be different when AI takes all the jobs (lol)

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

#477

Post by josephg »

rdtsc wrote: post #105
sega_sai wrote: post #95

One have question on this is, if the backdoor would not been discovered due to performance issue (which was as I understood it purely an oversight/fixable deficiency in the code), what are the chances of discovering this backdoor later, or are there tools that would have picked it up? Those questions are IMO relevant to understand if this kind of backdoor is the first one of the kind, or the first one that was uncove…

At least for some comic relief I'd like to imagine Jia's boss slapping him and saying something like "you idiot, we worked on this for so many years and you couldn't have checked for any perf issues?" But seriously, we could have found ourselves with this in all stable repos: RHEL, Debian, Ubuntu, IoT devices 5 years from now and it would have been a much larger shit show.

This was the backdoor we found. We found the backdoor with performance issues.

Whats more likely - that this is the only backdoor like this in linux, or that there are more out there and this is the one we happened to find?

I really hope someone is out there testing for all of this stuff in linux:

- Look for system() calls in compiled binaries and check all of them

- Look for uses of IFUNC - specifically when a library uses IFUNC to replace other functions in the resulting executable

- Make a list of all the binaries / libraries which don't landlock. Grep the sourcecode of all those projects and make sure none of them expect to be using landlock.

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

#478

Post by imiric »

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…

> 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 do this for the entire dependency tree, and at some point we have to trust that the projects we depend on follow this same methodology, but having a lax attitude about dependency management is part of the problem that caused the xz situation.

One thing that I think would improve this are "maintenance scores". A service that would scan projects on GitHub and elsewhere, and assign a score to each project that indicates how well maintained it is. It would take into account the number of contributors in the past N months, development activity, community size and interaction, etc. Projects could showcase this in a badge in their READMEs, and it could be integrated in package managers and IDEs that could warn users if adding a dependency that has a low maintenance score. Hopefully this would disuade people to use poorly maintained projects, and encourage them to use better maintained ones, or avoid the dependency altogether. It would also encourage maintainers to improve their score, and there would be higher visibility of projects that are struggling, but have a high user base, as potentially more vulnerable to this type of attack. And then we can work towards figuring out how to provide the help and resources they need to improve.

Does such a service/concept exist already? I think GitHub should introduce something like this, since they have all the data to power it.

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

#480

Post by godelski »

benreesman wrote: post #469
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 securit…

> yo dawg curl this shit and pipe it to sh so you can RCE while you bike shed someone’s unsafe block

Ahhh this takes me back to... a month ago...[0]

At least rust wraps function in main so you won't run a partial command, but still doesn't there aren't other dangers. I'm more surprised by how adamant people are about that there's no problem. You can see elsewhere in the thread that piping man still could (who knows!) pose a risk. Extra especially when you consider how trivial the fix is, especially when people are just copy pasting the command anyways...

It never ceases to amaze me how resistant people are to very easily solvable problems.

[0] https://news.ycombinator.com/item?id=39556047

Post reply on HN