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

731–740 of 862 posts

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

#731

Post by chii »

dannyw wrote: post #582
sgammon wrote: post #440

There appears to be a string encoded in the binary payload: https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01... Which functions as a killswitch: https://piaille.fr/@zeno/112185928685603910 If that is indeed the case, one mitigation might be ``` echo "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" | sudo tee -a /etc/environment ```

That's so strange. This reeks of nation state actors, wanting ways to protect their own systems.

if you need to test your own malware that you're developing, do you really want to just run it and disrupt your own system?

It's not uncommon to put in a check that allows the malware to run but be a noop.

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

#732

Post by chii »

rubymamis wrote: post #690
nicce wrote: post #689

Earlier quoted context omitted.

> I think one solution could be in licenses that force companies/business of certain sizes to pay maintenance fees. One idea from the top of my head. Yet people have huge opposition for those licenses. The big scream of "not free anymore" starts and the entity gets cancelled.

I think focusing on big organizations (e.g. above certain revenue/profit should help). There must be some sweet spot, after all, the organizations that rely on it should want it to be maintained as well.

tragedy of the commons.

If someone else can pay to maintain it, but you get the benefits, then it's the obvious strategy to use.

And also, there's zero evidence that proprietary software won't have these backdoors. In fact, you can't even check them for it!

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

#733

Post by forty »

tux3 wrote: post #628
forty wrote: post #559

Earlier quoted context omitted.

I have often seen the secret component of an asymmetric key pair referred as secret key as well. See libsodium for example. Maybe it's because curve/ed 25519 secrets are 32 random bytes unlike RSA keys which have specific structure which makes them distinct from generic secrets.

It also allows "pk" and "sk" as overly short variable names, an argument developpers are sometimes tempted by!

Absolutely, it's very convenient when working on a whiteboard :)

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

#734

Post by chii »

rmi_ wrote: post #274
plg94 wrote: post #129

Earlier quoted context omitted.

I don't think we know what exactly this does, yet. I can only answer one of those questions, as far as I understand the "unreplayable" part is refering to this: > Apparently the backdoor reverts back to regular operation if the payload is malformed or *the signature from the attacker's key doesn't verify*. emphasis mine, note the "signature of the attacker's key". So unless that key is leaked, or someone breaks the R…

> So unless that key is leaked But, just for replayability, we could "patch" the exploit with a known key and see what it does, don't we?

> see what it does

it does whatever the decrypted/signed payload tells the backdoor to execute - it's sent along with the key.

The backdoor is just that - a backdoor to let in that payload (which will have come from the attacker in the future when they're ready to use this backdoor).

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

#735

Post by chii »

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…

> then strange behavior and commits that claim to do one thing but actually do something else, are more likely to be spotted earlier than later.

https://en.wikipedia.org/wiki/Underhanded_C_Contest

It's actually an art to writing code like that, but it's not impossible and will dodge cursory inspection. And it's possible to have plausible deniability in the way it is constructed.

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

#736

Post by rubymamis »

chii wrote: post #732
rubymamis wrote: post #690

Earlier quoted context omitted.

I think focusing on big organizations (e.g. above certain revenue/profit should help). There must be some sweet spot, after all, the organizations that rely on it should want it to be maintained as well.

tragedy of the commons. If someone else can pay to maintain it, but you get the benefits, then it's the obvious strategy to use. And also, there's zero evidence that proprietary software won't have these backdoors. In fact, you can't even check them for it!

That's why I think such OSS packages should use licenses that force large companies to pay (moderate) fees for maintenance. I assume such sums of money won't even tickle them.

Imagine 10 large companies, each pay $1000 a month for critical packages they use. For each developer, that's $10,000 they can either use to quit their current job or hire another person to share the burden.

We need to normalize this.

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

#737

Post by djao »

Dalewyn wrote: post #569
kbenson wrote: post #556

Earlier quoted context omitted.

> Even Americans usually don't drink that hard; the French earned my respect that day. Is drinking hard something so deserving of respect? Is working while impaired? To me this reads as "I like to fuck off and be irresponsible and man did these French guys show me how it's done!"

Except they weren't irresponsible. We all drove back just fine, and we all went back to work just as competently as before like nothing happened. It takes skill and maturity to have a good time but not so much that it would impair subsequent duties. The French demonstrated to me they have that down to a much finer degree than most of us have in America, so they have my respect. This isn't to say Americans are immatur…

As someone who knows people who died in a crash with another drunk driver, it is hard for me to accept your view. Certainly, at a bare minimum, the penalties for drunk driving that results in fatality should be much harsher than they are now -- at that point there is hard empirical evidence that you cannot be trusted to have the "skill and maturity" necessary for driving -- but we can't even bring ourselves to do that, not even for repeat offenders.

Eventually I am optimistic that autonomous driving will solve the problem entirely, at least for those who are responsible drivers. In an era of widely available self-driving cars, if you choose to drive drunk, then that is an active choice, and no amount of "social lubrication" can excuse such degenerate behavior.

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

#738

Post by yencabulator »

nurple wrote: post #294
loumf wrote: post #193

Earlier quoted context omitted.

You are looking at a makefile, not C. The C code is in a string that is being passed to a function called `check_c_source_compiles()`, and this dot makes that code not compile when it should have -- which sets a boolean incorrectly, which presumably makes the build do something it should not do.

Interesting that validating the failure reason of an autotools compile check could be a security mitigation...

Unfortunately in the world of autoconf and multiple platforms and compilers, there was no standard way to understand why the compilation failed.

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

#739

Post by djao »

droopyEyelids wrote: post #568
teraflop wrote: post #278

Earlier quoted context omitted.

One of the biggest differences is that 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. If you use a different strong random password for every single server, this attack isn't a problem, but that adds a lot of management hassle compared to using a single private key. (It's also made more dif…

Not a rhetorical question: couldn't the malicious server relay the challenge from a valid server for to you to sign, and impersonate you that way?

If a man in the middle relays a public key challenge, that will indeed result in a valid connection, but the connection will be encrypted such that only the endpoints (or those who possess a private key belonging to one of the endpoints) can read the resulting traffic. So the man in the middle is simply relaying an encrypted conversation and has no visibility into the decrypted contents.

The man in the middle can still perform denial of service, by dropping some or all of the traffic.

The man in the middle could substitute their own public key in place of one of the endpoint's public keys, but if each endpoint knows the other endpoint's key and is expecting that other key, then an unexpected substitute key will raise a red flag.

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

#740

Post by yencabulator »

paulmd wrote: post #585
nurple wrote: post #294

Earlier quoted context omitted.

Interesting that validating the failure reason of an autotools compile check could be a security mitigation...

This is something that should have unit/integration tests inside the tooling itself, yeah. If your assertion is that X function is called / in the environment X then the function should return Y then that should be a test especially when it’s load-bearing for security. And tooling is no exception either. You should have tests that your tooling does the things it says on the tin and that things happen when flags are s…

It's a "does this compile on this platform" test, not a "does this function return what we expect" test.
Post reply on HN