[HN Gopher] FAQ on the xz-utils backdoor
       ___________________________________________________________________
        
       FAQ on the xz-utils backdoor
        
       Author : jethro_tell
       Score  : 60 points
       Date   : 2024-03-29 21:11 UTC (1 hours ago)
        
 (HTM) web link (gist.github.com)
 (TXT) w3m dump (gist.github.com)
        
       | TillE wrote:
       | > The release tarballs upstream publishes don't have the same
       | code that GitHub has. This is common in C projects so that
       | downstream consumers don't need to remember how to run autotools
       | and autoconf.
       | 
       | This doesn't seem really vital to the attack, but it's a silly
       | outdated convention. Nobody is manually downloading and compiling
       | tarballs these days, and those who do can figure out how to use
       | autotools.
        
         | IshKebab wrote:
         | Yeah terrible idea. Either you should commit the output of
         | autoconf (and enforce keeping it up to date via CI), or much
         | much better - stop using autoconf! It belongs in the 90s!
        
           | knorker wrote:
           | It's another case of that "yes, it sucks. But the
           | alternatives just plain don't work, or work in WAY fewer
           | circumstances".
           | 
           | If I have a strange architecture or install, autoconf is
           | often the only one that works.
        
         | jiripospisil wrote:
         | Reminds of the note at the bottom of Fish releases. It's there
         | because the build system cannot determine the current version
         | for some reason. Hopefully that will go away now that they have
         | switched to a different language / build system. The custom
         | tarball is used by Arch Linux at the very least.
         | 
         | https://github.com/fish-shell/fish-shell/releases/tag/3.7.1
         | 
         | https://github.com/fish-shell/fish-shell/issues/7772#issueco...
         | 
         | https://gitlab.archlinux.org/archlinux/packaging/packages/fi...
        
       | pdw wrote:
       | Flagged: How is this "via a project dev"? Which project? The guy
       | doesn't seem to have anything to do with the discovery of this
       | backdoor, and he just summarizes Andres Freund's announcement.
        
         | bhaney wrote:
         | The author of this is a gentoo maintainer who focuses on
         | security work. Most distros have a couple of point people
         | handling this issue for them at this point, and they are all
         | likely pretty well informed.
         | 
         | If you want clarification on something, you can just ask
         | instead of announcing that you've flagged it.
        
       | choeger wrote:
       | So the attacker put the payload into the tests folder of the
       | compression library and injected it upon build via some arcane
       | build script? Kudos. That's quite a smart way to hide your
       | backdoor.
       | 
       | Nevertheless, they got caught. So big respect for the analysis.
       | Amazing work.
       | 
       | That being said, what does this attack tell you about the future
       | of software security? Free software could easily be compromised
       | by having a highly paid team create such a payload and then
       | convince some maintainer, one way or another, to deploy it.
       | 
       | How do we back off from that cliff?
        
         | cassianoleal wrote:
         | Security is hard.
         | 
         | In this case, it seems like there's a lot that could be done to
         | reduce the chance of being exploited.
         | 
         | Why are obscure binaries in the repository at all in the first
         | place, even if in the test dir? Surely those binaries can be
         | generated as a setup step prior to the tests actually running.
         | 
         | Furthermore, why are there scripts present in the release
         | package that have not been added to the source code?
         | 
         | Also, if I understood it correctly, the compromised binaries
         | are also present in the release tarball. Why are they part of
         | the release if they are supposedly test fixtures rather than
         | part of the application code?
        
         | jethro_tell wrote:
         | To be fair, so could closed source code.
         | 
         | The difference in this case is that a guy was running perf
         | tests against postgres and noticed his ssh was slow, so he dove
         | into that and found the backdoor a couple days after it was
         | pushed.
         | 
         | If you had to submit 'my ssh daemon is slow' to a third party
         | it would get put on the pile with the rest of them
        
       | pseudo0 wrote:
       | Main discussion thread here:
       | https://news.ycombinator.com/item?id=39865810
       | 
       | Backdoor in upstream xz/liblzma leading to SSH server compromise
       | (openwall.com) 1848 points by rkta 5 hours ago | 654 comments
        
       ___________________________________________________________________
       (page generated 2024-03-29 23:02 UTC)