|
Message-ID: <MN0PR19MB594880C384348BC52E3167E39B392@MN0PR19MB5948.namprd19.prod.outlook.com> 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.