Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #6315 > unrolled thread

xz backdoor prevention and hosts.deny?

Back to article view | Back to linux.debian.security

Contents

  xz backdoor prevention and hosts.deny? Nick Sal <specialroumpa@proton.me> - 2024-03-31 23:50 +0200
    Re: xz backdoor prevention and hosts.deny? Gian Piero Carrubba <gpiero@rm-rf.it> - 2024-04-01 11:50 +0200

#6315 — xz backdoor prevention and hosts.deny?

[Multipart message — attachments visible in raw view] — view raw

Hi,

With respect to debian testing, assume we filter SSH access only to a subnet using the files host.{deny,allow} (see below).
Would this prevent the attack if a malicious payload was not​ sent from the allowed subnet?
Asking to know if an attack was possible like this, for the few days in March the backdoor was undetected on debian testing.

/etc/hosts.deny: sshd: ALL
/etc/hosts.allow: sshd: "a_subnet"

Moreover, would it have helped if additionally allowing only public-key authentication for SSH?

Regards,
Nick

[toc] | [next] | [standalone]

#6316

* [Sun, Mar 31, 2024 at 09:28:46PM +0000] Nick Sal:
>With respect to debian testing, assume we filter SSH access only to a 
>subnet using the files host.{deny,allow} (see below).
>Would this prevent the attack if a malicious payload was not sent from 
>the allowed subnet?

I've not seen any reference to this. One could argue that tcpwrappers' 
check should happen in an early stage, so it could have helped. But 
that's just speculation and I would consider the system vulnerable 
unless someone knowledgeable (I'm not) says otherwise.

>Moreover, would it have helped if additionally allowing only public-key 
>authentication for SSH?

All sources I've read agree that this was not sufficient (actually, the 
malicious code resided in the function verifying the key signatures).

Best,
Gian Piero.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.security

csiph-web