|
i used to statically link ffmpeg because it would randomly demand new versions of poo poo like x264 without actually using any new functionality, but then they started to while also adding new codecs so i stopped. thats my static linking story thanks for reading
|
# ? Mar 29, 2024 01:59 |
|
|
# ? May 15, 2024 02:56 |
|
For some reason kde on wayland crashed and now crashes whenever I try to run it even though I didn't change anything but it still works on x11, and I don't really have time to try to debug this right now
|
# ? Mar 29, 2024 03:24 |
|
fresh_cheese posted:this bullshit is what they claim is “fixed” by containers welcome to the rustpublican party
|
# ? Mar 29, 2024 05:55 |
|
XZ has a nasty backdoor: https://news.ycombinator.com/item?id=39866275 quote:Very annoying - the apparent author of the backdoor was in communication with me over several weeks trying to get xz 5.6.x added to Fedora 40 & 41 because of it's "great new features". We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added). We had to race last night to fix the problem after an inadvertent break of the embargo. https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users quote:Yesterday, Red Hat Information Risk and Security and Red Hat Product Security learned that the latest versions of the “xz” tools and libraries contain malicious code that appears to be intended to allow unauthorized access. Specifically, this code is present in versions 5.6.0 and 5.6.1 of the libraries - at this time, only Fedora 41 and Fedora Rawhide contain these libraries. This vulnerability was assigned CVE-2024-3094.
|
# ? Mar 29, 2024 18:27 |
|
oh, good thing practically nothing uses xz
|
# ? Mar 29, 2024 18:38 |
|
Beeftweeter posted:oh, good thing practically nothing uses xz ZSTD superiority.
|
# ? Mar 29, 2024 18:44 |
|
good thing I have only been using gz for everything for the last 25 or so years
|
# ? Mar 29, 2024 18:51 |
|
FlapYoJacks posted:ZSTD superiority. iirc it has slightly worse compression ratios than xz, but it's definitely faster i play around with compression formats from time to time and there's certainly some interesting ones, but no clear winner imo
|
# ? Mar 29, 2024 18:53 |
|
sb hermit posted:good thing I have only been using gz for everything for the last 25 or so years doesn't matter, it tries to backdoor sshd
|
# ? Mar 29, 2024 18:58 |
|
FlapYoJacks posted:ZSTD superiority. it's called zstd but xz is the one that has an std???? linux is so confusing
|
# ? Mar 29, 2024 19:54 |
|
spankmeister posted:doesn't matter, it tries to backdoor sshd yeah I read it I’m trying to say that maybe systemd should have just stuck with what works
|
# ? Mar 29, 2024 21:16 |
|
sb hermit posted:yeah I read it dehumanize yourself and face to poettering
|
# ? Mar 29, 2024 23:33 |
|
Soricidus posted:… the whole point of giving it a different name is that it guarantees that they cannot possibly break any existing sdl2 software even by accident, why are you so angry about the way they are accomplishing this because that’s the stupidest possible way to accomplish the goal, instead of just evolving a single codebase reasonably
|
# ? Mar 30, 2024 09:20 |
|
spankmeister posted:dehumanize yourself and face to poettering
|
# ? Mar 30, 2024 10:33 |
|
so hang on a sec, if your distro doesn't use systemd then the backdoor doesn't work? or is redhat's description of the sshd backdoor just tailored to fedora + systemd because it's red hat?
|
# ? Mar 30, 2024 15:32 |
|
Beeftweeter posted:so hang on a sec, if your distro doesn't use systemd then the backdoor doesn't work? or is redhat's description of the sshd backdoor just tailored to fedora + systemd because it's red hat? we know how to trigger the backdoor in apt/yum-based linux distros with systemd, so we know those are vulnerable in specific circumstances. we don’t know yet whether other distros might be vulnerable with different trigger conditions. they may well be safe, but it would be foolish to assume that. the only sensible move is to patch everything this dude has ever touched.
|
# ? Mar 30, 2024 18:15 |
|
Beeftweeter posted:so hang on a sec, if your distro doesn't use systemd then the backdoor doesn't work? or is redhat's description of the sshd backdoor just tailored to fedora + systemd because it's red hat? there is a fairly common patch against openssh in the linux world that many distros apply to add systemd notification support ("Type=notify" in the [Service] section of your ssh.service unit). because the openssh developers are BSD partisans and refuse to port their code to other platforms, even in the "portable" version of openssh. e.g. here's a copy of it in SuSE: https://build.opensuse.org/projects/network/packages/openssh/files/openssh-7.7p1-systemd-notify.patch that code adds a runtime dependency to the compiled sshd binary, i.e. an ELF DT_NEEDED tag on the SONAME libsystemd.so.0 libsystemd.so.0 itself has a DT_NEEDED tag on liblzma.so.5 i forget what it's called but the specific way these binaries were compiled or linked together caused all of the shared libraries and symbols to be eagerly loaded and resolved at process startup rather than lazily resolved only when a specific function in a shared library is called. (e: i think it's compiling/linking with the -Wl,z,now flag that does this.) then the malicious liblzma.so.5 DSO used the IFUNC mechanism to run malicious code when the sshd binary starts up. the IFUNC mechanism is typically used to select between alternative implementations of a function, i think they were loving around with different CRC implementations or something. CRC being a pretty good example for this kind of stuff since x86 CPUs with SSE 4.2 have a CRC32C instruction that really speeds things up (iirc it's something like 10X faster than a software CRC32C implementation). to be useful you want to do a CPUID check at process startup and pick the optimal implementation for the running CPU and patch the symbol table or whatever, that way you're not trying to do CPU detection every time the function gets called or indirecting through a function pointer or something like that so in theory if your sshd didn't have that systemd patch the malicious code wouldn't be called, but if you're on a distro that uses systemd your openssh probably did have that patch and libsystemd the library is different from systemd the PID 1 process so in theory you could have been running sysvinit on a systemd-supporting distro that still supports sysvinit but the malicious code would still be injected into the sshd process
|
# ? Mar 30, 2024 18:17 |
|
Soricidus posted:we know how to trigger the backdoor in apt/yum-based linux distros with systemd, so we know those are vulnerable in specific circumstances. right, the question is more "is a system that does not use systemd still vulnerable?" fwiw i cross-posted the question to the security thread and the answer seems unclear right now. of course it would be foolish to assume anything is safe until a thorough audit is complete, but i was curious about e.g. embedded systems that might have busybox compiled with xz support. those generally don't get many updates so a lot of devices would probably be vulnerable, but at the same time almost certainly wouldn't be using systemd (or a standalone sshd even). but since busybox is so modular it'd be highly configuration-dependent anyway, i.e. someone could even use busybox with systemd and a separate sshd (openssh, dropbear, whatever) if they were so inclined but i'm not sure if it even uses xz-utils. i do know the busybox xz applets aren't full-featured, so it might be a minimal or entirely custom implementation same applies to toybox on android i guess. if you could get root through exploiting it somehow that would actually help me out a ton since i have an old huawei with a permanently locked bootloader lol
|
# ? Mar 30, 2024 18:32 |
|
also there is code in the unreleased main branch of systemd that switches to dlopen()'ing the compression libraries only when needed that apparently would have neutralized this particular attack chain (the Type=notify systemd notification code in libsystemd doesn't depend on the compression functionality, i think that's in there due to a journal thing) https://github.com/systemd/systemd/pull/31550 if the postgresql guy hadn't noticed the anomalous CPU usage on his benchmark box and the xz backdoor wasn't caught, whether your distro actually executed the backdoored code might have depended on whether your distro had upgraded to systemd ≥ 256 or not
|
# ? Mar 30, 2024 18:33 |
|
Beeftweeter posted:fwiw i cross-posted the question to the security thread and the answer seems unclear right now. of course it would be foolish to assume anything is safe until a thorough audit is complete, but i was curious about e.g. embedded systems that might have busybox compiled with xz support. those generally don't get many updates so a lot of devices would probably be vulnerable, but at the same time almost certainly wouldn't be using systemd (or a standalone sshd even). but since busybox is so modular it'd be highly configuration-dependent anyway, i.e. someone could even use busybox with systemd and a separate sshd (openssh, dropbear, whatever) if they were so inclined the currently known information about the backdoored xz releases is that it was specifically targeting amd64, GNU, linux, and when running under a dpkg/rpm package build https://www.openwall.com/lists/oss-security/2024/03/29/4 posted:The attached de-obfuscated script is invoked first after configure, where it
|
# ? Mar 30, 2024 18:35 |
|
shackleford posted:there is a fairly common patch against openssh in the linux world that many distros apply to add systemd notification support ("Type=notify" in the [Service] section of your ssh.service unit). because the openssh developers are BSD partisans and refuse to port their code to other platforms, even in the "portable" version of openssh. ah that's a pretty thorough answer lol, thanks shackleford posted:the currently known information about the backdoored xz releases is that it was specifically targeting amd64, GNU, linux, and when running under a dpkg/rpm package build yeah i gathered from your other post that it didn't seem to impact other architectures. which thankfully limits its potential impact quite a bit i would think, there's probably more non-x86 devices running linux now than x86
|
# ? Mar 30, 2024 18:39 |
|
i would like to use this opportunity to again whine about how low-level and monolithic the design that made that happen is (i.e. wanting to surface a notification from openssh leading to a bunch of poo poo, almost none performance-critical or low-level in nature, getting loaded up together), but i do also realize that at the point where you're packaging up and shipping the attackers malicious code the defense-in-depth does get pretty hard to do.
|
# ? Mar 30, 2024 19:06 |
|
are you advocating that sshd would be better as a collection of microservices?
|
# ? Mar 31, 2024 03:04 |
|
he's saying that sshd should be a statically linked unikernel
|
# ? Mar 31, 2024 03:15 |
|
i think that perhaps if you want a critical security component like sshd to actually be secure, it should never be linked against arbitrary libraries it doesn't actually use? that's not an argument for microservices it just makes sense
|
# ? Mar 31, 2024 03:22 |
|
SSHD should be added TO the kernel.
|
# ? Mar 31, 2024 04:16 |
|
it would have prevented this backdoor given that the kernel implementation of xz wasn't compromised
|
# ? Mar 31, 2024 05:37 |
|
FlapYoJacks posted:SSHD should be added TO the kernel. you know, i'm thinking it really should
|
# ? Mar 31, 2024 06:21 |
|
bring back khttpd
|
# ? Mar 31, 2024 08:45 |
|
ak ok i took that the wrong way then yes static linking ssh , scp, sshd makes sense to me but then what about pam? getty? sssd? how deep is the rabbit hole?
|
# ? Mar 31, 2024 12:22 |
|
hey buddy here's a quarter buy yourself a terabyte of disk space
|
# ? Mar 31, 2024 12:28 |
|
yea disk is cheap and it isnt even disk anymore
|
# ? Mar 31, 2024 12:36 |
|
mostly i think there is some thinking one can do here about how to structure these pieces, thinking which probably can go beyond whether we link statically or dynamically. there could be sensible ways of further segregating crypto and auth stuff even further from the rest of the system. but no real clear ideas, mostly just a real annoying path this backdoor took.
|
# ? Mar 31, 2024 12:58 |
|
why not just stop development on these things unless it’s critically important like unless you need to forward port yet another piece of code to be compliant with compiler changes or to take advantage of new hardware, just leave it the hell alone but I’m sure the next evolution of all this poo poo is to dump the work on the GPU which will lead to yet more insane exploits because of the increased attack surface
|
# ? Mar 31, 2024 13:41 |
|
to be serious, though, hopefully any test blobs of any appreciable size will come with tools to show how the blobs were created in the first place or maybe even dynamically generated on the fly
|
# ? Mar 31, 2024 13:44 |
|
fresh_cheese posted:yea disk is cheap and it isnt even disk anymore it's not just disk, but memory too. the kernel can keep a single copy of each library in memory, shared between all processes using it.
|
# ? Mar 31, 2024 13:55 |
|
wow that'll save a whole 4 megs
|
# ? Mar 31, 2024 14:12 |
|
fresh_cheese posted:ak ok i took that the wrong way then None of these should be dynamically linked. They should offer their services through domain sockets or some other IPC mechanism. Dynamic linking is sometimes necessary for performance reasons, but PAM poo poo and DNS lookups is not that critical. Sharing address spaces sucks.
|
# ? Mar 31, 2024 14:40 |
|
if we are not going to fix “rando email address takes maintainership of foundation library because they were there on the day it came up” then we have to figure out how to compartmentalize dependancies so some stupid “left pad” maintainership change does not affect the entire ecosystem. im starting to think the altruistic open source movement based on assuming the best about all participants was not a great plan. many eyes do not make all bugs shallow, it turns out.
|
# ? Mar 31, 2024 14:45 |
|
|
# ? May 15, 2024 02:56 |
|
It is cool & wise to think about how to avoid problems like this, but it is equally lame & foolish to ignore that naive trust in altruistic open source developers has historically gone pretty well most of the time. Thisisfine.jpg, but the house isn't on fire, there's just some mold and maybe a candle next to some drapes.
|
# ? Mar 31, 2024 14:54 |