jonfive Posted March 29, 2024 Posted March 29, 2024 Someone passed this around a discord that i'm in and figured i'd share here given Debian usage. It was posted today Date: Fri, 29 Mar 2024 08:51:26 -0700 https://www.openwall.com/lists/oss-security/2024/03/29/4 Excerpt: == Compromised Repository == The files containing the bulk of the exploit are in an obfuscated form in tests/files/bad-3-corrupt_lzma2.xz tests/files/good-large_compressed.lzma committed upstream. They were initially added in https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0 Note that the files were not even used for any "tests" in 5.6.0. Subsequently the injected code (more about that below) caused valgrind errors and crashes in some configurations, due the stack layout differing from what the backdoor was expecting. These issues were attempted to be worked around in 5.6.1: https://github.com/tukaani-project/xz/commit/e5faaebbcf02ea880cfc56edc702d4f7298788ad https://github.com/tukaani-project/xz/commit/72d2933bfae514e0dbb123488e9f1eb7cf64175f https://github.com/tukaani-project/xz/commit/82ecc538193b380a21622aea02b0ba078e7ade92 For which the exploit code was then adjusted: https://github.com/tukaani-project/xz/commit/6e636819e8f070330d835fce46289a3ff72a7b89 Given the activity over several weeks, the committer is either directly involved or there was some quite severe compromise of their system. Unfortunately the latter looks like the less likely explanation, given they communicated on various lists about the "fixes" mentioned above. Florian Weimer first extracted the injected code in isolation, also attached, liblzma_la-crc64-fast.o, I had only looked at the whole binary. Thanks! Quote
RedCat-51 Posted March 30, 2024 Posted March 30, 2024 It looks like Unraid 6.12.8 itself is not impacted. I checked the version on mine and version 5.4.1 was returned which is not one of the version listed as impacted (5.6.0 and up) https://nvd.nist.gov/vuln/detail/CVE-2024-3094 https://access.redhat.com/security/cve/cve-2024-3094 You should check any containers you have running. xz --version will return the current version 1 Quote
YoHoNoMo Posted March 30, 2024 Posted March 30, 2024 9 hours ago, RedCat-51 said: xz --version Unraid 6.12.9 is also unaffected with version 5.4.1. Popular docker containers with 5.6(.1) I found: - binhex/arch-prowlarr - binhex/arch-sabnzbd - binhex/arch-sonarr It seems binhex/arch-radarr is unaffected with version 5.4.5. 1 Quote
ich777 Posted March 30, 2024 Posted March 30, 2024 I think you all should mention @binhex here and not just only write which containers are affected. 1 1 Quote
NLynzaad Posted March 31, 2024 Posted March 31, 2024 just a quick script you can run in your terminal to output containerIds and corresponding xz version. anything below 5.6.0 should be fine: for containerId in $(docker ps -q); do echo $containerId && docker exec -it $containerId sh -c 'xz --version'; done 1 3 Quote
Antibios Posted April 1, 2024 Posted April 1, 2024 (edited) Ran that script and found all my binhex containers on 5.6.1 binhex-jellyfin binhex-delugevpn binhex-sonarr binhex-radarr binhex-hexchat Edited April 1, 2024 by Antibios 1 Quote
ChatNoir Posted April 1, 2024 Posted April 1, 2024 There has been a bunch of binhex containers updated. Have you checked before or after the updates ? Quote
Kilrah Posted April 1, 2024 Posted April 1, 2024 (edited) The binhex containers I have and were updated yesterday switched TO the vulnerable version, they were OK on 5.4.1 before that... Edited April 1, 2024 by Kilrah 1 Quote
YoHoNoMo Posted April 1, 2024 Posted April 1, 2024 21 minutes ago, ChatNoir said: There has been a bunch of binhex containers updated. Have you checked before or after the updates ? I checked again today after updating my binhex containers. On 3/30/2024 at 12:45 PM, YoHoNoMo said: Unraid 6.12.9 is also unaffected with version 5.4.1. Popular docker containers with 5.6(.1) I found: - binhex/arch-prowlarr - binhex/arch-sabnzbd - binhex/arch-sonarr It seems binhex/arch-radarr is unaffected with version 5.4.5. Latest updates changed binhex/arch-radarr to version 5.6.1. It is now affected as well. Quote
MikeAH Posted April 1, 2024 Posted April 1, 2024 (edited) 2 hours ago, YoHoNoMo said: I checked again today after updating my binhex containers. Latest updates changed binhex/arch-radarr to version 5.6.1. It is now affected as well. Curious if anyone has established which versions of various Binhex containers don't have the affected xz packages. In the meantime I plan to rollback to older versions of docker containers until xz has moved beyond this version or been removed from the affected packages. Edit: I added a few of the binhex docker containers I found that shouldn't be vulnerable with this version of xz. Hope this helps! sabnzbd 4.2.2-1-01 privoxyvpn 3.0.34-1-08 prowlarr 1.13.3.4273-1-01 plexpass 1.40.1.8227-1-01 Edited April 1, 2024 by MikeAH Added Binhex versions I found without 5.6.* Quote
Antibios Posted April 1, 2024 Posted April 1, 2024 4 hours ago, ChatNoir said: There has been a bunch of binhex containers updated. Have you checked before or after the updates ? Mine were updated this morning and checked after Quote
shanelord Posted April 2, 2024 Posted April 2, 2024 binhex is working on it - https://github.com/binhex/arch-base/issues/7#issuecomment-2028383549 1 Quote
zoggy Posted April 2, 2024 Posted April 2, 2024 there is also this scanner: https://xz.fail/ info: https://www.bleepingcomputer.com/news/security/new-xz-backdoor-scanner-detects-implant-in-any-linux-binary/ for those that dont want to rely on running xz to check versions. ldd /path/to/xz then drop the liblzma.so* file into the scanner Quote
dopeytree Posted April 2, 2024 Posted April 2, 2024 (edited) Can a moderator ajust the title on this to have proper spacing in the title. Reason is if you do a search for XZ in the forum nothing pops up. Presume the / is messing up searching? Edited April 2, 2024 by dopeytree Quote
Kilrah Posted April 2, 2024 Posted April 2, 2024 (edited) 13 minutes ago, dopeytree said: Presume the / is messing up searching? It does not find it within the thread even if there are plenty of standalone occurrences of it either. Many search systems ignore search terms shorter than 3-4 chars. Edited April 2, 2024 by Kilrah Quote
dopeytree Posted April 2, 2024 Posted April 2, 2024 (edited) Quote xz --version Also doesn't bring it up. Hope one day we can implement some better searching in this forum. The https://docs.unraid.net uses https://www.algolia.com/ which is ace. Edited April 2, 2024 by dopeytree Quote
DerfMcDoogal Posted April 2, 2024 Posted April 2, 2024 Didn't find xz at all in any of my containers from linuxserver.io, plexinc Quote
iXNyNe Posted April 3, 2024 Posted April 3, 2024 4 hours ago, DerfMcDoogal said: Didn't find xz at all in any of my containers from linuxserver.io, plexinc https://info.linuxserver.io/issues/2024-03-29-cve-2024-3094/ Tldr: lsio images are mostly unaffected. Updating to the latest images is recommended as a precaution. Quote
thatsthefrickenlightning Posted April 3, 2024 Posted April 3, 2024 On 4/2/2024 at 5:12 AM, shanelord said: binhex is working on it - https://github.com/binhex/arch-base/issues/7#issuecomment-2028383549 Thanks for taking the time to let us know. Would it be wise to stop binhex containers in the meantime? Quote
shanelord Posted April 3, 2024 Posted April 3, 2024 Yeah. I went the extra step and converted to direct repository or linuxserver dockers. I don’t recommend it if you don’t know how this all works (I don’t want to have to support people that lose their app configs) but if you do know how, take a look:https://github.com/shanelord01/unraid_templatesNeed to stop the current containers, copy the contents of the applicable appdata/binhex-xxxx folder to an appdata/xxxx folder, note down all of the settings from the binhex-xxxx docker (then remove the docker app) and start the new one (using the user template) with the same settings.Sent from my iPhone using Tapatalk Quote
Kilrah Posted April 3, 2024 Posted April 3, 2024 (edited) 1 hour ago, thatsthefrickenlightning said: Thanks for taking the time to let us know. Would it be wise to stop binhex containers in the meantime? This vulnerability is only "triggered" when connecting to an ssh server running on a system with the vulnerable lib. Most containers do not have an ssh server, and only in extremely rare cases you would know about (e.g. a git server container) would that ssh server actually be exposed for someone to connect to. So no. Edited April 3, 2024 by Kilrah 1 3 Quote
shanelord Posted April 3, 2024 Posted April 3, 2024 binhex has updated most (and soon all) images according to this post: https://github.com/binhex/arch-base/issues/7#issuecomment-2035236451Looks like as others have stated and binhex has clarified - risk was low anyway. Sent from my iPhone using Tapatalk Quote
zoggy Posted April 3, 2024 Posted April 3, 2024 https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/ pretty cool infographic that shows the timeline and all the stuff involved. can see theres a few safeguards to prevent it from being detected/running.. but also prob a bit of other unknown things we yet to discover. included link to article which covers a bit more info for those that are curious Quote
clusterbox Posted April 4, 2024 Posted April 4, 2024 On 4/2/2024 at 12:58 PM, zoggy said: there is also this scanner: https://xz.fail/ info: https://www.bleepingcomputer.com/news/security/new-xz-backdoor-scanner-detects-implant-in-any-linux-binary/ for those that dont want to rely on running xz to check versions. ldd /path/to/xz then drop the liblzma.so* file into the scanner What exactly am I suppose to drop in the scanner? I don't see a *.elf file? Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.