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

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

#581

Post by kortilla » Sun, Mar 31, 2024, 7:28 AM UTC

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?

No, these schemes use the pub/private keys to setup symmetric crypto, so just passing it along does you no good because what follows is a bunch of stuff encrypted by a session key only the endpoints know.

If I am a server and have your public key in an authorized_keys file, I can just encrypt a random session key using that and only you will be able to decrypt it to finish setting up the session.

This is why passwords and asymmetric crypto are worlds apart in security guarantees.

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

#582

Post by dannyw » Sun, Mar 31, 2024, 7:31 AM UTC

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.

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

#583

Post by kortilla » Sun, Mar 31, 2024, 7:32 AM UTC

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…

It doesn’t actually do anything because if SSL is compromised then all of the junk you think you are telling the client to do to the password is via JavaScript that is also compromised.

If you’re worried about passive listeners with ssl private keys, perfect forward secrecy at the crypto layer solved that a long time ago.

For browsers at least, sending passwords plainly over a tls session is as good as it gets.

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

#584

Post by willtemperley » Sun, Mar 31, 2024, 7:33 AM UTC

adtac wrote: post #561

willtemperley wrote: post #430

Another good reason to use a firewall with an IP address allowlist for SSH.

And now for my next trick: smuggling a backdoor into iptables.

Ha yes. I rely on cloud-provided security groups for that. So I blindly have to believe my provider is immune to supply chain attacks.

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

#585

Post by paulmd » Sun, Mar 31, 2024, 7:33 AM UTC

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

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 set and things don’t happen when they’re not set, and that the tooling sets the flags in the way you expect.

These aren’t even controversial statements in the JVM world etc. Just C tooling is largely still living in the 70s apart from abortive attempts to build the jenga tower even taller like autotools/autoconf/cmake/etc (incomprehensible, may god have mercy on your build). At least hand written make files are comprehensible tbh.

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

#586

Post by xlii » Sun, Mar 31, 2024, 7:36 AM UTC

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…

Working for about a year in an environment that was exposed to high volume of malevolent IT actors (and some pretty scary ones) I’d say: discovery chances very always pretty high.

Keeping veil of secrecy requires unimaginable amount of energy. Same goes with truth consistency. One little slip and everything goes to nothing. Sometimes single sentence can start a chain of reaction and uncover meticulous crafted plan.

That’s how crime if fought every day. Whereas police work has limited resources, software is analyzed daily by hobbyists as a hobby, professionals who still do it for a hobby, and professionals for professional reasons.

Discovery was bound to happen eventually.

XZ attack was very well executed. It’s a master piece. I wouldn’t be surprised if some state agencies would be involved. But it also was incredibly lucky. I know for sure for myself, but also many of my colleagues would go into long journey if found any of issues that are flagged right now.

One takeaway is that chance of finding such issue would be impossible if xz/liblzma wouldn’t be open source (and yes I am also aware it enabled it in the first place) but imagine this existing in Windows or MacOS.

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

#587

Post by dvdkon » Sun, Mar 31, 2024, 7:37 AM UTC

CanaryLayout wrote: post #456

kbolino wrote: post #249

Earlier quoted context omitted.

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

How about making ssh as secure as (or more secure than) the VPN you'd put it behind? Considering the amount of vulnerabilities in corporate VPNs, I'd even put my money on OpenSSH today.

It's not like this is SSH's fault anyway, a supply chain attack could just as well backdoor some Fortinet appliance.

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

#588

Post by dannyw » Sun, Mar 31, 2024, 7:41 AM UTC

BuildTheRobots wrote: post #316

Tuna-Fish wrote: post #72

Earlier quoted context omitted.

If the payload didn't have a random .5 second hang during SSH login, it would probably not have been found for a long time. The next time, the attackers probably manage to build a payload that doesn't cause weird latency spikes on operations that people wait on. (For some reason this brings to mind how Kim Dotcom figured out he was the target of an illegal wiretap... because he suddenly had a much higher ping in MW3.…

I'm a little out of touch, but for over a decade I'd say half the boxes I touched either didn't have enough entropy or were trying to do rDNS for (internal) ranges to servers that didn't host it and is nearly always hand waved away by the team running it as NFN. That is to say, a half-second pause during the ssh login is absolutely the _least_ suspicious place place for it to happen and I'm somewhat amazed anyone tho…

What led to continuous investigation wasn't just the 500ms pause, but large spikes in CPU activity when sshd was invoked, even without a login attempt.

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

#589

Post by juliusdavies » Sun, Mar 31, 2024, 7:42 AM UTC

Lucky the XZ license switched from "Public Domain" to 0BSD in February (just before these 5.6.0 and 5.6.1 releases)!

0BSD has no clauses, but it does have this:

> IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

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

#590

Post by anonymous-panda » Sun, Mar 31, 2024, 7:43 AM UTC

kbenson wrote: post #546

anonymous-panda wrote: post #506

Earlier quoted context omitted.

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…

You don’t need vouching for anyone. mDL is going to be a mechanism to have a government authority vouch your identity. Of course a state actor like this can forge the identity, but that forgery at least will give a starting point for the investigation to try to figure out who this individual is. There’s other technical questions about how you verify that the identity really is tied in some real way to the user at the other end (eg not a stolen identity) but there are things coming down that will help with that (ie authenticated chains of trust for hw that can attest the identity was signed on the given key in person and you require that attestation).

As for people accusing you of an intentional RCE, that may be a hypothetical scenario but I doubt it’s very real. Most people have a very long history of good contributions and therefore have built up a reputation that would be compared against the reality on the ground. No one is accusing Lasse Collin of participating in this even though arguably it could have been him all along for what anyone knows.

It doesn’t need to be perfect but directionally it probably helps more than it hurts.

All that being said, this clearly seems like a state actor which changes the calculus for any attempts like this since the funding and power is completely different than what most people have access to and likely we don’t have any really good countermeasures here beyond making it harder for obfuscated code to make it into repositories.