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

241–250 of 862 posts

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

#241

Post by WesolyKubeczek »

tomoyoirl wrote: post #112
sneak wrote: post #92

Earlier quoted context omitted.

Nah, the CIA assassinates people in MLAT zones all the time. The laws that apply to you and I don’t apply to the privileged operators of the state’s prerogatives. We don’t even know that this specific backdoor wasn’t the NSA or CIA. Assuming it was a foreign intelligence service because the fake name was asian-sounding is a bit silly. The people who wrote this code might be sitting in Virginia or Maryland already.

> Virginia or Maryland Eastern Europe, suggest the timestamp / holiday analysts. https://rheaeve.substack.com/p/xz-backdoor-times-damned-time...

Note that while “Eastern Europe” has firm connotations with countries of which some are known for having corrupt autocracies, booming shady businesses, and organized crime and cybercrime gangs in varying proportions, the time zone mentioned also covers Finland, from which the other author is supposed to be.

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

#242

Post by bcrescimanno »

jijijijij wrote: post #186
noncoml wrote: post #14

Unpopular opinion, but I cannot but admire the whole operation. Condemn it of course, but still admire it. It was a piece of art! From conception to execution, masterful! We got extremely lucky that it was caught so early.

> "After all, He-Who-Must-Not-Be-Merged did great things - terrible, yes, but great." I think the most ingenious part was picking the right project to infiltrate. Reading "Hans'" IFUNC pull request discussion is heart-wrenching in hindsight, but it really shows why this project was chosen. I would love to know how many people where behind "Jia" and "Hans" analyzing and strategizing communication and code contribution…

> Compared to the overall effort invested, that's careless, badly planned or underfunded.

Not at all. It's a pattern that's very easy to spot while the eyes of the world are looking for it. When it was needed, it worked exactly as it needed to work. Had the backdoor not been discovered, no one would have noticed--just like no one did notice for the past couple of years.

Had anyone noticed at the time, it would have been very easy to just back off and try a different tactic a few months down the line. Once something worked, it would be quick to fade into forgotten history--unlikely to be noticed until, like now, the plan was already discovered.

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

#243

Post by heresWaldo »

berkes wrote: post #163
heresWaldo wrote: post #137

Earlier quoted context omitted.

Yeah these types of security issues will be used by politicians to force hardware makers to lockdown hardware, embed software in chips. The go fast startups habit of “import the world to make my company products” is a huge security issue IT workers ignore. The only solution politics and big tech will chase is obsolete said job market by pulling more of the stack into locked down hardware, with updates only allowed to…

Why would "embed software in chips" be a solution? If anything, I'd expect it to be an even bigger risk, because when (not if) a security issue is found in the hardware, you now have no way to fix it, other than throwing out this server/fridge/toothbrush or whatever is running it.

A flashable secure enclave segment in the hardware stack is an option to patch around embedded bugs.

I haven’t worked in hardware design since the era of Nortel, and it was way different back then but the general physics are the same; if, else, while, and math operations in the hardware are not hard.

In fact your hardware is a general while loop; while has power, iterate around refreshing these memory states with these computed values, even in the absence of user input (which at the root is turning it on).

Programmers have grown accustomed to being necessary to running ignorant business machines but that’s never been a real requirement. Just a socialized one. And such memes are dying off.

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

#244

Post by quotemstr »

kbolino wrote: post #208
admax88qqq wrote: post #161

Earlier quoted context omitted.

How can sshd spawn interactive sessions for other users if it's sandboxed?

SELinux does not rely on the usual UID/GID to determine what a process can do. System services, even when running as "root", are running as confined users in SELinux. Confined root cannot do anything which SELinux policy does not allow it to do. This means you can let sshd create new sessions for non-root users while still blocking it from doing the other things which unconfined root would be able to do. This is stil…

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

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

#246

Post by danparsonson »

tialaramex wrote: post #17
jtchang wrote: post #6

So this basically means to scan for this exploit remotely we'd need the private key of the attacker which we don't have. Only other option is to run detection scripts locally. Yikes.

One completely awful thing some scanners might choose to do is if you're offering RSA auth (which most SSH servers are and indeed the SecSH RFC says this is Mandatory To Implement) then you're "potentially vulnerable" which would encourage people to do password auth instead. Unless we find that this problem has somehow infested a lot of real world systems that seems to me even worse than the time similar "experts" de…

Have to admit I've never understood why password auth is considered so much worse than using a cert - surely a decent password (long, random, etc) is for all practical purposes unguessable, and so you're either using a private RSA key that no-one can guess, or a password that no-one can guess, and then what's the difference? With the added inconvenience of having to pass around a certificate if you want to login to the same account from from multiple sources.

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

#247

Post by mik1998 »

dolmen wrote: post #218
mik1998 wrote: post #113

Earlier quoted context omitted.

I did my own research. If you look at the git repository commit log and some mailing list messages, you will see that the author ("Jia Tan", fake name) speaks impeccable English (already lessens the chance of being a Chinese operative), however he commits in the +0800 time zone (Beijing). He works during Chinese holidays and doesn't work during Western holidays. However, the times don't make sense: It looks like he w…

Another analysis locates Jia in Eastern Europe: https://rheaeve.substack.com/p/xz-backdoor-times-damned-time... But I would like to see analysis of timestamp of GitHub events (like PRs and comments timestamps) which are harder to fake.

It's a nice analysis but he misses the fact that the Eastern Europe timezone doesn't match office hours, in particular it'd mean he worked around evenings primarily (see this graph https://files.catbox.moe/4itspl.png)

I had noticed UTC+0300 commits in the repository under his name but I believed they might have been simply committed by the main Finnish maintainer who is in the UTC+0300 timezone.

> But I would like to see analysis of timestamp of GitHub events (like PRs and comments timestamps) which are harder to fake.

I doubt the git commit timestamps are faked, since actually faking them is somewhat difficult to do consistently (you would time travel frequently). I don't think there is some kind of github API for this, however from what I've seen they seem to match up with the same work timespan you see in the commit timestamps.

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

#248

Post by whartung »

pbhjpbhj wrote: post #185
semiquaver wrote: post #108

Earlier quoted context omitted.

CFAA covers this. Its a crime to > knowingly [cause] the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer; Where one of the definitions of “protected computer” is one that is used in interstate commerce, which covers effectively all of them.

It seems like the backdoor creates the potential to "cause damage" but doesn't [provably?] cause damage per se ? The author of the backdoor doesn't themselves "[cause] the transmission of a program ...". Others do the transmission. Seems weak, unless you know of some precedent case(s)?

The back door is damage. The resulting sshd is like a door with a broken lock. This patch breaks the lock. Transmitting the patch caused intentional damage.

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

#249

Post by kbolino »

quotemstr wrote: post #244
kbolino wrote: post #208

Earlier quoted context omitted.

SELinux does not rely on the usual UID/GID to determine what a process can do. System services, even when running as "root", are running as confined users in SELinux. Confined root cannot do anything which SELinux policy does not allow it to do. This means you can let sshd create new sessions for non-root users while still blocking it from doing the other things which unconfined root would be able to do. This is stil…

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 circumstances. In many cloud environments, nuking the VM instance and starting over is probably easier than fiddling with SELinux.

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

#250

Post by londons_explore »

quatrefoil wrote: post #135
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…

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.

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 system(), fork() or mmap() looking for anything unusual.

Even then, they might detect the attack, yet have no chance at actually finding how the malicious code loaded itself.

Post reply on HN