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

151–160 of 862 posts

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

#151

Post by tux3 »

formerly_proven wrote: post #138
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…

I think this would’ve been difficult to catch because the patching of sshd happens during linking, when it’s permissible, and if this is correct then it’s not a master key backdoor, so there is no regular login audit trail. And sshd would of course be allowed to start other processes. A very tight SELinux policy could catch sshd executing something that ain’t a shell but hardening to that degree would be extremely ra…

One idea may be to create a patched version of ld-linux itself with added sanity checks while the process loads.

For something much more heavy-handed, force the pages in sensitive sections to fault, either in the kernel or in a hypervisor. Then look at where the access is coming from in the page fault handler.

I don't think you can reliably differentiate a backdoor executing a command, and a legitimate user logged in with ssh running a command once the backdoor is already installed. But the way backdoors install themselves is where they really break the rules.

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

#152

Post by formerly_proven »

almostnormal wrote: post #126
sneak wrote: post #89

The questions this backdoor raises: - what other ones exist by this same team or similar teams? - how many such teams are operating? - how many such dependencies are vulnerable to such infiltration attacks? what is our industry’s attack surface for such covert operations? I think making a graph of all major network services (apache httpd, postgres, mysql, nginx, openssh, dropbear ssh, haproxy, varnish, caddy, squid,…

Why did they decide to create a backdoor, instead of using a zeroday like everyone else? Why did they implement a fully-featured backdoor and attempted to hide the way it is deployed, instead of deploying something innocent-looking that might as well be a bug if detected? These must have been conscious decisions. The reasons might provide a hint what the goals might have been.

Ed448 is orders of magnitude better NOBUS than hoping that nobody else stumbles over the zero-day you found.

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

#153

Post by Phelinofist »

paolomainardi wrote: post #79

I am wondering if reinstalling the entire Archlinux installation would be a wise choice.

Just to extend the sibling comment with an excerpt of the Arch announce mail regarding the backdoor:

  >From the upstream report [1]:
  
  > openssh does not directly use liblzma. However debian and several other
  distributions patch openssh to support systemd notification, and libsystemd
  does depend on lzma.
  
  Arch does not directly link openssh to liblzma, and thus this attack vector is not possible. You can confirm this by issuing the following command:
   
   ```
   ldd "$(command -v sshd)"
   ```
   
  However, out of an abundance of caution, we advise users to remove the malicious code from their system by upgrading either way. This is because other yet-to-be discovered methods to exploit the backdoor could exist.

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

#154

Post by raggi »

djao wrote: post #140
rdtsc wrote: post #105

Earlier quoted context omitted.

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.

Maybe they didn't have time to test? They could have been scrambling to make it into timed releases such as Ubuntu 24.04 or Fedora 40.

There is one possible time pressure involved, which is that libsystemd dropped the liblzma dependency

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

#156

Post by formerly_proven »

thinkingemote wrote: post #124
nocoiner wrote: post #28

Earlier quoted context omitted.

I felt really bad for the original maintainer getting dog-piled by people who berated him for not doing his (unpaid) job and basically just bring shame and discredit to himself and the community. Definitely cruel. Though… do we know that the maintainer at that point was the same individual as the one who started the project? Goes deep, man.

Its possible the adversary was behind or at least encouraged the dog piling who berated him. Probably a normal basic tactic from a funded evil team playbook. Might be worth reviewing those who berated him to see if they resolve to real people, to see how deep this operation goes.

One of them who left only one comment does, the rest are sock puppets.

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

#157

Post by Ekaros »

almostnormal wrote: post #126
sneak wrote: post #89

The questions this backdoor raises: - what other ones exist by this same team or similar teams? - how many such teams are operating? - how many such dependencies are vulnerable to such infiltration attacks? what is our industry’s attack surface for such covert operations? I think making a graph of all major network services (apache httpd, postgres, mysql, nginx, openssh, dropbear ssh, haproxy, varnish, caddy, squid,…

Why did they decide to create a backdoor, instead of using a zeroday like everyone else? Why did they implement a fully-featured backdoor and attempted to hide the way it is deployed, instead of deploying something innocent-looking that might as well be a bug if detected? These must have been conscious decisions. The reasons might provide a hint what the goals might have been.

If they seemingly almost succeeded how many others have already done similar backdoor? Or was this actually just poking on things seeing if it was possible to inject this sort of behaviour?

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

#158

Post by georgyo »

heresWaldo wrote: post #137
snnn wrote: post #127

Earlier quoted context omitted.

That's the most interesting part. No, we don't know it yet. The backdoor is so sophisticated that none of us can fully understand it. It is not a “usual” security bug.

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…

I'm not saying political forces won't try legislating the problem away, but that won't even help here.

A supply chain attack can happen in hardware or software. Hardware has firmware, which is software.

What makes this XZ attack so scary is that it was directly from a "trusted" source. A similar attack could come from any trusted source.

At least with software it is much easier to patch.

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

#159

Post by formerly_proven »

filleokus wrote: post #109
joshcryer wrote: post #21

Earlier quoted context omitted.

They also used social engineering to disable fuzzing which would have caught the discrepancy: https://github.com/google/oss-fuzz/pull/10667

Would it really have caught it?

No

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

#160

Post by gouggoug »

dolmen wrote: post #132
onedognight wrote: post #38

Earlier quoted context omitted.

> With the right sandboxing techniques, SELinux and mitigations could prevent the attacker from doing anything with root permissions. Please review this commit[0] where the sandbox detection was “improved”. [0] https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2...

I can't blame anyone who has missed that dot dissimulated at the beginning of the line. https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd...

For people like me whose C knowledge is poor, can you explain why this dot is significant? What does it do in actuality?
Post reply on HN