Overview

It’s been an absolutely manic week in the Linux security community as the news
and reaction to the recent announcement of a backdoor in the xz-utils project
was announced late last week, so we dive deep into this issue and discuss how it
impacts Ubuntu and give some insights for what this means for the open source
and Linux communities in the future.

This week in Ubuntu Security Updates

20 unique CVEs addressed

[USN-6718-2] curl vulnerability

• 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM)
  
  
  
  • CVE-2024-2398
  
  
  
  

[USN-6719-1] util-linux vulnerability

• 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10)
  
  
  
  • CVE-2024-28085
  
  
  
  

[USN-6686-5] Linux kernel (Intel IoTG) vulnerabilities

• 9 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
  
  
  
  • CVE-2024-0607
  
  
  • CVE-2024-0340
  
  
  • CVE-2023-6121
  
  
  • CVE-2023-51782
  
  
  • CVE-2023-51779
  
  
  • CVE-2023-46862
  
  
  • CVE-2023-46343
  
  
  • CVE-2023-4134
  
  
  • CVE-2023-22995
  
  
  
  

[USN-6715-1] unixODBC vulnerability

• 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10)
  
  
  
  • CVE-2024-1013
  
  
  
  

[USN-6704-4] Linux kernel (Intel IoTG) vulnerabilities

• 5 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
  
  
  
  • CVE-2024-24855
  
  
  • CVE-2024-1086
  
  
  • CVE-2024-1085
  
  
  • CVE-2023-32247
  
  
  • CVE-2023-23000
  
  
  
  

[USN-6707-4] Linux kernel (Azure) vulnerabilities

• 4 CVEs addressed in Jammy (22.04 LTS)
  
  
  
  • CVE-2024-26599
  
  
  • CVE-2024-26597
  
  
  • CVE-2024-1086
  
  
  • CVE-2024-1085
  
  
  
  

[USN-6720-1] Cacti vulnerability

• 1 CVEs addressed in Jammy (22.04 LTS)
  
  
  
  • CVE-2023-39361
  
  
  
  

Goings on in Ubuntu Security Community

xz-utils backdoor and Ubuntu

• https://www.openwall.com/lists/oss-security/2024/03/29/4


• Late last week, 28th / 29th March backdoor in liblzma from xz-utils was
  disclosed to the open source community via oss-security mailing list - this
  was in the recent 5.6.0/5.6.1 releases from late Feb/early March this year


• initially the impact was not entirely clear - assumed initially that it may
  impact only xz-utils and so only in handling of xz compressed data / files -
  but even with that assumption that perhaps it could then infect anything that
  got compressed/decompressed


• within a few hours though became clear that the primary target was not
  xz-utils/liblzma itself but openssh - and the affect was to provide a backdoor
  into openssh that would allow the attacker to get remote access to any machine
  running ssh server with this backdoor liblzma installed


• To paint a picture - this was all unfolding on late Thursday / Friday of the
  Easter break, so lots of folks were either EOD or on leave etc - and trying to
  grapple with a threat that we knew could possibly impact the impedending 24.04
  LTS release

• Good news:


• TL;DR for Ubuntu, this version was only ever in the -proposed pocket for the
  currently in-development 24.04 release - not in any other Ubuntu versions -
  and was removed as soon as we became aware, so unless you are running the
  devel release AND you had manually opted to install this version from the
  -proposed pocket, you would not be affected - very lucky


• https://discourse.ubuntu.com/t/xz-liblzma-security-update/43714


• What do we know about this? A lot - there has been significant investigation
  (and speculation) since it was announced, both at the social side of things
  and the technical aspects of the backdoor itself


• For the purpose of the podcast, we won’t go too deep into either but will try
  and cover the salient details


• Regarding the inclusion of the backdoor itself - looks to have been a very
  long and patient campaign by the attacker, who slowly gained the trust of the
  upstream project over the last 2 years and likely pressured the maintainer via
  sock-puppet accounts to then get themselves added as an additional maintainer


• Since then they seemed to be quite a good maintainer themselves - diligently
  adding new features and bug fixes etc over the past 2 years, but then suddenly
  introduced the backdoor into the most recent 2 releases


• The method of introducing the backdoor was also interesting, in that it
  required 2 parts - the binary containing the backdoor and the code to get this
  compiled into the liblzma library at build time
  
  
  
  • The binary was committed into the upstream git repo disguised as an xz
    archive itself used as part of the test suite
  
  
  • The code to inject this into the build was NOT part of the git repo, but
    instead was just in the tarball prepared by the maintainer for the official
    release
  
  
  • And it used many levels of obfuscation to hide this backdoor within that
    fake test xz archive
  
  
  
  


• So the attacker was not just patient but also very technically skilled - and
  not just multiple levels of obfuscation in the build process but the backdoor
  code itself contained many elements to try and make it harder to recognise and
  reverse engineer, presumably to allow it to hide in plain sight
  
  
  
  • although as we will see, this runtime obfuscation within the backdoor binary
    was what gave it away eventually
  
  
  
  


• It’s often said that one of the advantages of Open Source is the huge
  community, which is summarised as Linus’ Law - with enough eyeballs all bugs
  are shallow - but sadly this wasn’t proven out in this case


• Backdoor was not
  found by anyone doing review of the changes upstream or by the various distros
  like Debian / Fedora / OpenSUSE / Arch or even Ubuntu when incorporating this
  new version into their repos - but instead was found by Andres Freund, one of
  the maintainers of PostgreSQL, when they were looking to benchmark some new
  changes scheduled for the next PostgreSQL release


• Luckily decided to use Debian unstable for this, and Debian had incorporated
  this new version into unstable a few weeks ago, and wanted to get the
  performance noise floor of the system as low as possible before doing
  benchmarking of PostgreSQL - noticed large transient CPU spikes in sshd and
  then eventually weird memory errors in sshd due to bugs in the initial version
  of the backdoor


• After a lot of painstaking work was able to determine that liblzma was the
  culprit and appeared to contain some very strange code to hook into the
  authentication process of sshd when it was launched via systemd


• Was able to trace that back to the aforementioned manually prepared tarballs
  of xz-utils on Github


• The CPU spikes Andres observed were due to the use of things like a trie to
  lookup symbol names at runtime, rather than directly