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

851–860 of 862 posts

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

#851

Post by tempay »

brokenmachine wrote: post #848
tempay wrote: post #771

Earlier quoted context omitted.

It’s more analogous to getting hired at the lock company and sabotaging the locks you assemble to be trivially pickible if you know the right trick. The University of Minnesota case is an interesting one to compare to. I could imagine them being criminally liable but being given a lenient punishment. I wonder if the law will end up being amended to better cover this, if it isn’t already explicitly illegal.

What happened at the University of Minnesota?

They intentionally tried to contribute security bugs into the linux kernel as a research project: https://lwn.net/Articles/854645/

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

#852

Post by zygentoma »

solardev wrote: post #305
dboreham wrote: post #285

Earlier quoted context omitted.

It depends what happens to the password. Typically it's sent as a bearer credential. But there are auth schemes (not widely used these days) where the password isn't sent over the wire.

Isn't it pretty standard practice to salt and hash the password client-side before sending it over the wire?

No. Everything you do on the client side you can also keep not doing at all.

You can imagine the salted and hashed password in your scheme to be "the password". Because the server will still know it, and could use it to log in somewhere else (it just has to skip the salt-and-hash step).

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

#853

Post by kosh2 »

golergka wrote: post #368
quatrefoil wrote: post #135

Earlier quoted context omitted.

If the exploit wasn't baing used, the odds would would be pretty low. They picked the right place to bury it (i.e., effectively outside the codebase, where no auditor ever looks). That said, if you're not using it, it defeats the purpose. And the more you're using it, the higher the likelihood you will be detected down the line. Compare to Solarwinds.

> That said, if you're not using it, it defeats the purpose. Not always. Weapons of war are most useful when you don't have to actually use them, because others know that you have it. This exploit could be used sparingly to boost a reputation of a state-level actor. Of course, other parties wouldn't know about this particular exploit, but they would see your cyber capabilities in the rare occasions where you decided…

> because others know that you have it.

Except that cyber weapons like these are

1. One time use 2. Expire upon detection (mostly)

I think this is simply just a tool for offensive action only.

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

#854

Post by Bulat_Ziganshin »

ghostpepper wrote: post #184
joeyh wrote: post #104

Earlier quoted context omitted.

Since a liblzma backdoor could be used to modify compiler packages that are installed on some distributions, it gets right back to a trusting trust attack. Although initial detection via eg strace would be possible, if the backdoor was later removed or went quiescentit would be full trusting trust territory.

How would this be possible? This backdoor works because lzma is loaded into sshd (by a roundabout method involving systemd). I don't think gcc or clang links lzma.

the installation process itself executes xz scripts which can make any (?) modifications to the system

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

#855

Post by 91bananas »

yborg wrote: post #786
rigid wrote: post #641

Earlier quoted context omitted.

I bet in the majority of cases, there's no need to pressure for merging. In a big company it's much easier to slip it in. Code seemingly less relevant for security is often not reviewed by a lot of people. Also, often people don't really care and just sign it off without a closer look. And when it's merged, no one will ever look at it again, other than with FOSS.

An insider could just be tasked to look for exploitable vulnerabilities in existing code and compile this information for outside entities without ever having to risk inserting a purpose-made backdoor. Considering the security state of most large codebases, there would be a bottomless well of them.

Who wants this job, that is capable of actually doing it properly?

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

#857

Post by [deleted] »

xlii wrote: post #586
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. T…

[deleted]

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

#858

Post by imrehg »

danparsonson wrote: post #538
imrehg wrote: post #341

Earlier quoted context omitted.

On that last point, I wouldn't pass around the certificate to log in from multiple sources, rather each source would have its own certificate. That is easy & cheap to do (especially with ed25519 certs).

Ah right, that's useful, thanks. Presumably if you need to login from an untrusted source (e.g. in an emergency), then you're out of luck in that case? Do you maybe keep an emergency access cert stashed somewhere?

That's a very good question. Likely depends on the circumstances. I don't quite know any ways of using untrusted sources safely. Maybe something where you can use temporary credentials (say 2FA), or the the likes of using AWS's EC2 Instance Connect, but there's always a problem of _something_ has to be on an untrusted location, I guess?

Having some emergency access certs in a password manager might be a good backup (and rotating it after using it on an untrusted source?).

The best way is, however, removing the need in emergencies to access a machine (e.g. more of the "cattle vs pets" way of thinking). But that's hard for sure.

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

#859

Post by danparsonson »

imrehg wrote: post #858
danparsonson wrote: post #538

Earlier quoted context omitted.

Ah right, that's useful, thanks. Presumably if you need to login from an untrusted source (e.g. in an emergency), then you're out of luck in that case? Do you maybe keep an emergency access cert stashed somewhere?

That's a very good question. Likely depends on the circumstances. I don't quite know any ways of using untrusted sources safely. Maybe something where you can use temporary credentials (say 2FA), or the the likes of using AWS's EC2 Instance Connect, but there's always a problem of _something_ has to be on an untrusted location, I guess? Having some emergency access certs in a password manager might be a good backup (…

> ...rotating it after using it on an untrusted source?...

> ...the "cattle vs pets" way of thinking...

Good points both... To the former, of course you're right that once used, an emergency cert should be replaced, which could be onerous either from the point of view of having double the number of certs to manage (rather than one master key), or else having to rotate the master key on all servers. To the latter, I'm definitely thinking about pets, so I hadn't considered just throwing away the VM and starting again; that neatly sidesteps the issue.

Thanks!

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

#860

Post by account42 »

alrs wrote: post #528
CanaryLayout wrote: post #456

Earlier quoted context omitted.

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

Who cares about scans? Who cares if a scan comes in 4 or 6?

I imagine it stops some non-targeted attempts that simply probe the entire v4 range, which is not feasible with v6. But yeah, not really buying you much, especially if there is any publicly listed service on that IP.
Post reply on HN