Ldd /usr/sbin/sshd – Alpine vs. Ubuntu for exploitability of CVE-2024-3094

https://mergebase.com/blog/cve-2024-3094-exploitability/

by juliusdavies • 2 years ago

10 7 2 years ago

olix0r2• 2 years ago

Which feels safer to you?

“Feels” being the operative word… alpine is statically linking all of the same libraries, you’re just not able to see them via LDD.

juliusdavies• 2 years ago

I asked Ariadne Conill from the Alpine project about this. She says they don't static link.

Here's a copy/paste of her response from LinkedIn (https://www.linkedin.com/feed/update/urn:li:activity:7180667...)

Alpine is dynamically linked, we just do not link SSH against libsystemd. In general, I think systemd needs to split up the various components in libsystemd into separate libraries, as there is no reason sd_notify() would ever require liblzma.
Anyone who is claiming that Alpine is secure because it's staticly linked have clearly never actually looked at a running Alpine system. I blame the initial Rust PR for musl support for starting this whole "musl = static linking" meme.

olix0r2• 2 years ago

Ah hah! Indeed I’m most familiar with musl in a static linking context.

Thanks for the clarification

francescovv• 2 years ago

[Alpine] just do not link SSH against libsystemd

Arch doesn't either.

In fact, official releases of openssh-portable don't. One has to patch it for that. Debian and Fedora (as well as their downstreams) do apply such a patch [1]. Most other distros don't.

[1] https://sources.debian.org/src/openssh/1%3A9.7p1-2/debian/pa...

tetha• 2 years ago

Alpine is dynamically linked, we just do not link SSH against libsystemd. In general, I think systemd needs to split up the various components in libsystemd into separate libraries, as there is no reason sd_notify() would ever require liblzma.

Funny, I was thinking about this just now. I get that the average library size on npm and such is on the wrong end of the spectrum, but libsystemd seems to swing far into the other end of the spectrum. Functions ranging from pretty much C-Code based on the stdlib with a few handlers, like sd_notify, hardware state detection and handling to systemd-journald file vacuuming all in that one library? Phew.

(And no, this is no discussion about systemd, that's just a thought about library design)

kevincox• 2 years ago

A good time for a reminder that you shouldn't `ldd` untrusted executables. It basically works by executing them with some special flags that the linker picks up which causes it to print the report. If the binary is nefarious it can hijack this and run whatever it wants.

https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/ldd.bas...

selfisekai• 2 years ago

as an Alpine contributor: while in this case it's true (sshd linking to libsystemd in Ubuntu is a result of a patch applied by Debian), `ldd` is not a good indicator for this. it does not say whether these dependencies are not there or get vendored and statically linked instead.

in other packages, we've sometimes specifically put work into making the ldd output longer, because a dependency not being statically compiled into the binaries means that we can effectively ship updates to it. as of now, running ldd on our binary of chromium returns 141 lines of output, or 157 for electron. when CVE-2023-4863 happened, we just quickly shipped a fix to libwebp, and that was the fix for our chromium and electron packages as well. a typical electron app you download (outside alpine repos) ships its own copy of electron with all these dependencies inside. ldd on that binary will output just 2 lines. it doesn't mean that it doesn't use all these dependencies, it means a much longer dependency chain in which your Electron chat app's developer might not realize they're vulnerable for 3 days until someone tells them, or "beta test" the update for half a month (both real examples from real chat apps)

Ldd /usr/sbin/sshd – Alpine vs. Ubuntu for exploitability of CVE-2024-3094

Related Stories