XMPP Service Operators - 2024-03-29

  1. snikket dot deeeeee

    There was just a supply chain attack discovered. As I understand it, it can compromise a servers ssh access. The openwall link has the Infos. @berto@floss.social 🔗 https://floss.social/users/berto/statuses/112179970574359097 - This is big: one of the xz-utils / liblzma *upstream maintainers* added malicious code to the last couple of releases. This is the person who actually publishes and signs the tarballs. If you are using liblzma 5.6.0 or 5.6.1 make sure to update your packages asap and consider reinstalling the OS or recreating the container. https://www.openwall.com/lists/oss-security/2024/03/29/4

  2. moparisthebest

    > openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma. 🤦 it'd be great if Debian would stop patching problems into things...

  3. TheCoffeMaker

    nooooo!, not during holidays 🫠

  4. snikket dot deeeeee

    And several other distributions... I don't see this as a Debian problem. Indeed Debian stable is one od the most protected versions from this. I more afraid how fast these things could spread on arch. Inject something in something that is generally used as root...

  5. moparisthebest

    snikket dot deeeeee: only affects ssh in distros that patch upstream like Debian though right? Same thing that caused the bug where all private keys generated on Debian were compromised

  6. snikket dot deeeeee

    Yes, my statement was more generally for supply chain attacks, not this specific one.

  7. deimosBSD

    there are sane practices like dependency minimization, automated security scanning, etc that help reduce the risks

  8. deimosBSD

    there is also an entire commercial ecosystem to do this

  9. deimosBSD

    the counterpoint being that this libzma issue has been around for a month or two and no one noticed it until one dev was like "why is logging in via ssh so slow?"

  10. snikket dot deeeeee

    Yes, And this is Debian, now in smaller projects, how big a chance is there this would be noticed

  11. diane

    Here's the link for the debian security tracker page on this xz-utils compromise https://security-tracker.debian.org/tracker/CVE-2024-3094

  12. diane

    If you're on testinging/sid you need to update to 5.6.1really5.4.5. the various stable versions look to be fine

  13. moparisthebest

    if you upgraded arch already you can downgrade to https://burtrum.org/archlinux/core/os/x86_64/xz-5.4.6-1-x86_64.pkg.tar.zst (append .sig so you can validate the package) and everything still works

  14. diane

    And yeah we probably need to figure out how to layer more defenses into our build systems

  15. deimosBSD


  16. deimosBSD

    sbom's are real

  17. moparisthebest

    doubt it would have prevented this though

  18. aereaux

    I think the latest -2 version of the Arch package fixes it too (switching to git tags)

  19. deimosBSD

    pretty soon we'll get back to "on trusting trust"

  20. moparisthebest

    possible, that commit was from 21 hours ago

  21. moparisthebest

    until we know everything though I feel safer sticking with 5.4.6

  22. deimosBSD

    also interesting the modified libzma code only targets rsa

  23. deimosBSD

    so...if you don't use rsa in ssh, were you vulnerable?

  24. moparisthebest

    did you find info on what the backdoor code does/did yet ?

  25. deimosBSD

    part of it is listed in the openwall link, the exploit hooked the rsa function

  26. deimosBSD


  27. deimosBSD

    for the reference

  28. mathieui

    moparisthebest, I do feel safer on 5.4.6 but not by much, the guy introducing the backdoor did most releases since around 5.2.2

  29. mathieui

    deimosBSD, SBOMs are useful for impact analysis *when you already have the CVE*, it allows you to quickly pin down the vulnerable parts and patch/upgrade/downgrade accordingly, but it does not help in detecting vulns in the first place

  30. deimosBSD


  31. deimosBSD

    plus it makes corporate insurance companies happy

  32. deimosBSD

    otherwise, completely useless for zero days and undiscovered bugs

  33. mathieui

    deimosBSD, also allows you to get the shiny security certifications

  34. mathieui looks at the dozens of PDFs listing the requirements for the BSZ certification

  35. moparisthebest

    mathieui, I agree but I think it's probably the best I can do at the moment :/

  36. moparisthebest

    uh, re: 5.4.6

  37. mathieui

    moparisthebest, indeed

  38. mathieui

    I also rebuilt 5.4.6 in the minutes after reading the writeup

  39. mathieui

    the guy also pushed for the inclusion in fedora (even taking a while to "help" the fedora maintainer get past the valgrind error), and another suspicious contributor to xz was the one who asked for the update in debian

  40. mathieui

    this is not fun

  41. mathieui

    sometimes I wish software was not a house of cards

  42. deimosBSD

    my next career is going to be a blacksmith

  43. deimosBSD

    hopefully horses make a comeback

  44. moparisthebest

    looks like arch is *probably* ok/unaffected https://www.openwall.com/lists/oss-security/2024/03/29/11

  45. diane

    I think SBOM is mostly for governments & companies to be able to blame someone else if things go wrong. (the useful thing is there's so much love of containers and static linking these days it can be really hard to know if a program includes a vulnerable component)

  46. agris

    Is that software bill of materials?

  47. MattJ


  48. agris

    I saw that new option in the latest version (master origin) of coreboot

  49. agris

    Does liblzma really have a backdoor?

  50. moparisthebest


  51. agris

    That's a pretty universal library. I wouldn't have expected the lzma developers to backdoor it

  52. agris

    Can someone please send details

  53. rewtkid

    Yes. luckily it was not widely deployed and was caught rather quickly. the main maintainer of xz it currently on a internet break.

  54. moparisthebest

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

  55. rewtkid

    it was not the main maintainer, it was some "chinese" (likely a false flag and not chinese) maintainer who was only contributing for 2-2.5 years

  56. agris

    Is this the same library used by nongnu's lzip archival format?

  57. moparisthebest

    He was doing releases for almost 2 years I think, also had a ton of other contributions all over

  58. rewtkid

    some things to take into consideration are, debian stable is not affected since it has older version in its repos. musl and other libc implementations are not effected, only glibc due to glibc IFUNC support.

  59. moparisthebest

    And seemingly not Arch, and possibly no one who doesn't patch openssh to use liblzma

  60. rewtkid


  61. rewtkid

    agris: is you want to read more in depth detauls about it, see here

  62. rewtkid


  63. rewtkid

    sorry for typos, on a new keyboard and not used to it yet. lol

  64. agris

    The exploit checks and only infects debian and rhel based systems

  65. rewtkid

    yep, it is not active on systems that arent deb, rpm, and glibc based

  66. agris

    That doesn't mean your not vulnerable just that other systems were not targeted

  67. grin

    agris, tumbleweed was affected

  68. grin

    so, not only debian and rhel/fedora

  69. agris

    What is that? The green chameleon distro's rolling release?

  70. rewtkid

    isnt opensuse rpm based?

  71. rewtkid

    agris: i guess lol

  72. agris

    That's still rpm and glibc based. Technically rhel based

  73. grin

    it's not rhel based... it's just based on rpms. using an archive format doesn't make you based on another distribution

  74. grin

    and yes, opensuse tumbleweed

  75. agris

    The extent to which they tried to make this unreproducable in a lab environment is impressive. I suspect a nation state threat actor.

  76. rewtkid

    it is, but im not buying that is from china. seems like a false flag to me.

  77. rewtkid

    besides the point, however.

  78. agris

    This is an impressive supply chain attack, relying on downstream patches and interdependency with systemd integration.

  79. agris

    Who do you think dunnit?

  80. rewtkid

    no clue. but false flags are not uncommon with attacks like this

  81. rewtkid

    the maintainer was only contributing for two years, and goes by Jia Tan.

  82. rewtkid

    so tried to make himself out as an asian person

  83. moparisthebest

    Wow this guy is *great* https://github.com/google/oss-fuzz/pull/10667

  84. amarachi

    Long con

  85. moparisthebest

    > In hindsight, this does not "look good to me" :-) 🤣😭🤣