oss-sec mailing list archives
Re: backdoor in upstream xz/liblzma leading to ssh server compromise
From: Jacob Bachmeyer <jcb62281 () gmail com>
Date: Tue, 16 Apr 2024 21:25:53 -0500
Solar Designer wrote:
[...] xz backdoor analysis ==================== More findings were made about the backdoor's functionality, notably as published on April 6 by blasty, who discovered that besides triggering system() the backdoor also allows interactive sessions: https://twitter.com/bl4sty/status/1776691497506623562[...]
There is almost certainly more yet to be uncovered: Andres Freund's original report included timing for SSH client connections requesting a nonexistent account using publickey auth. The backdoored SSH server was found to require significantly longer to reject those requests than the untampered sshd. I do not believe that the currently known backdoor hooks are reachable by that means, so why did Andres Freund see that particular slowdown? (Not the backdoor initialization making sshd take longer to start up---a running sshd taking longer to reject a session for a nonexistent account, unless Andres Freund forgot to tell us that he was running sshd from inetd and thereby including sshd startup latency in his measurements.)
[...] OpenJS Foundation "Failed Credible Takeover Attempt" ==================================================== On April 15, the OpenJS and OpenSSF foundations released the following: https://openjsf.org/blog/openssf-openjs-alert-social-engineering-takeovers https://openssf.org/blog/2024/04/15/open-source-security-openssf-and-openjs-foundations-issue-alert-for-social-engineering-takeovers-of-open-source-projects/ I'll quote an excerpt:The OpenJS Foundation Cross Project Council received a suspicious series of emails with similar messages, bearing different names and overlapping GitHub-associated emails. These emails implored OpenJS to take action to update one of its popular JavaScript projects to "address any critical vulnerabilities," yet cited no specifics. The email author(s) wanted OpenJS to designate them as a new maintainer of the project despite having little prior involvement. This approach bears strong resemblance to the manner in which "Jia Tan" positioned themselves in the XZ/liblzma backdoor. [...]
Concerning, yes, but not quite the "Jia Tan" /modus operandi/---"Jia" seems to have been contributing patches for some time (with sockpuppets pushing their acceptance as needed) before making a move to be appointed co-maintainer of xz. This looks to me like the common cybercrooks have seen the technique, decided that it sounds like a great idea, and are now trying to use it, but do not have the patience that the "Jia Tan" gang had. In other words, now the "Nigerian Princes" want to help you maintain your project, just give them write access to the source repository up front. :-P
I also want to call out a critical detail: claims of vulnerabilities with no specifics that would aid in actually fixing them. This should be a general red flag: *anyone* who makes such claims is probably up to no good.
Lastly, thank you for making the summary. -- Jacob
Current thread:
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Jakub Wilk (Apr 01)
- <Possible follow-ups>
- Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise Jakub Wilk (Apr 12)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Solar Designer (Apr 16)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Jacob Bachmeyer (Apr 17)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Loganaden Velvindron (Apr 17)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Matt Johnston (Apr 17)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Jacob Bachmeyer (Apr 19)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Jacob Bachmeyer (Apr 17)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Jakub Wilk (Apr 17)