Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 30 Mar 2024 19:35:28 +0000
From: Thomas Ward <teward@...mas-ward.net>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
CC: Andres Freund <andres@...razel.de>
Subject: RE: backdoor in upstream xz/liblzma leading to ssh
 server compromise

As a security guy, I have to ask, do we know all the currently known variants?  It's my understanding it's 5.6.0 and 5.6.1 affected by this, are there alternative infect vectors?  (I ask because I'm spinning this up in my research lab and want to get a better idea of the number of known variants impacted.)



Sent from my Galaxy



-------- Original message --------
From: Christoph Anton Mitterer <calestyo@...entia.org>
Date: 3/30/24 15:23 (GMT-05:00)
To: oss-security@...ts.openwall.com
Cc: Andres Freund <andres@...razel.de>
Subject: Re: [oss-security] backdoor in upstream xz/liblzma leading to ssh server compromise

Hey there.

First, thanks for finding and analysing this.


As far as I understand, many servers (that don't run
unstable/testing/etc. distributions) are likely safe (simply, because
they haven't seen the compromised versions yet).

But I wouldn't be too surprised if especially many developers run e.g.
on Debian unstable/testing or Fedora rawhide... and perhaps even many
end-users.
Thus, the systems from which the above save servers are
accessed/controlled might still get compromised or even worse: build
systems, repos, etc..


So next question would be:
In those systems (like Debian unstable) where the compromised code was
present, could it (in any of its versions) have actually caused
damage/further compromise?
Especially, is one e.g. safe when sshd was not running - or at least
not reachable from a public network?


>From what I understood from the currently published analysis, here in
the thread respectively from
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 it
is thought that:

- It *may* only get activated when the argv[0] is /usr/sbin/sshd

and would then:

- probably "only(?) fiddle around with the authentication (presumably)
  to grant access to the attacker.



I know that analysis is still ongoing, but IMO the following questions
would be relevant for people to decide whether their system is further
compromised or whether things are "good" again (with no chance of any
further comprise having been able to take place), by downgrading:

1) Was the malware respectively its payload code able to download
   further evil code (like other rootkits or so)?

2) On affected systems, if:
   - sshd was NOT used (but e.g. ssh (client), was)
   and/or
   - if it was used, it wasn't accessible from the internet (e.g.
     because a firewall/NAT/etc. was in between)

   ... can one say with sufficient confidence, that no further
   compromise respectively evil code execution could have happened?

   In the sense of, the evil code was then present/loaded, but it's
   assured that effectively it didn't do anything bad then.

   If so, I guess that would help at least some people to assess
   whether their laptops/workstations are safe (when they didn't use
   sshd or that wasn't accessible from the outside).

3) Is it known already whether any other attack vectors (not using
   sshd) where part of the code - or can that be ruled out?


And all these questions, of course, for every version of the maleware
that circulated.


Also, is there some central place (here?) where such answers would be
given, once people have examined the malware payload in depth?


Thanks,
Chris.

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.