3 ms·

Wouldn't dlopen make you more vulnerable to runtime library attacks? Instead of having dependencies defined at the build/start up time, they will be loaded at r

Wouldn't dlopen make you more vulnerable to runtime library attacks? Instead of having dependencies defined at the build/start up time, they will be loaded at runtime on demand. So the dependency library could be changed at any time and you wouldn't have any idea what code you are loading at this time? So upgrading XZ could even attack already running sshd too? I would be more inclined to have static linked libraries instead of having lazy loading of them for preventing this kind of attacks..

rcxdude 2y ago
This seems a bit nitpicky: you just move the threshold for where you might load a backdoored library from first exec to first use which dlopens that library (which might even just be at exec anyway, I haven't checked the source to see how systemd handles it). I think the focus on the specific means that the xz backdoor used to get into sshd is misdirected: it's code that is run in all kinds of priviledged contexts and has thousands of different ways to turn that into RCE. If sshd didn't load it directly the developers of the backdoor would have simply taken a different route.
wakawaka28 2y ago
Loading at runtime is a feature. You're supposed to lock down the environment for execution so the right libraries get used. The trouble with statically linking is that you have to relink everything to update. You also can't easily audit which versions are in a binary. It seems appropriate for some small userspace programs but not for complex software like services with many dependencies.
jcranmer 2y ago
> So upgrading XZ could even attack already running sshd too? With the specifics of how the xz injection attack worked, actually it wouldn't. libsystemd would have been loaded to implement the service-started notification, and then there is no reason to use anything further and therefore nothing to trigger the loading of the xz library. Which is kind of the point of this change: the goal is to load libraries on-demand instead of eagerly, so if there is nothing demanding the library load, the library is never loaded.
- cryptonector 2y ago
  Lazy loading would have achieved the same thing with less codebase churn. However, the `dlopen()` thing means that the dependencies are then optional as far as the packaging system go, and therefore you can run with fewer dependencies installed. Also, lazy loading can be turned off with an environment variable -- we would need a way to indicate that a dependency is optional in order to have something like always-lazy loading for it. There's also "filters" and "auxiliary filters", which can be used to make dependencies optional without having to go to `dlopen()`. However, IIRC filter functionality is very bare-bones or non-workin in the Linux link-editors and ld.so.
iforgotpassword 2y ago
> So upgrading XZ could even attack already running sshd too? Doesn't that work both ways, without dlopen updating to the patched version would still leave your sshd running with the old backdoored one.
im3w1l 2y ago
I think this isn't motivated by security at all. That it messed up the backdoor was a complete coincidence.
- Denvercoder9 2y ago
  That's correct, as evidenced by the fact that the systemd change to dlopen() liblzma was proposed and merged before the backdoor was discovered.

rcxdude 2y ago

This seems a bit nitpicky: you just move the threshold for where you might load a backdoored library from first exec to first use which dlopens that library (which might even just be at exec anyway, I haven't checked the source to see how systemd handles it). I think the focus on the specific means that the xz backdoor used to get into sshd is misdirected: it's code that is run in all kinds of priviledged contexts and has thousands of different ways to turn that into RCE. If sshd didn't load it directly the developers of the backdoor would have simply taken a different route.

wakawaka28 2y ago

Loading at runtime is a feature. You're supposed to lock down the environment for execution so the right libraries get used. The trouble with statically linking is that you have to relink everything to update. You also can't easily audit which versions are in a binary. It seems appropriate for some small userspace programs but not for complex software like services with many dependencies.

jcranmer 2y ago

> So upgrading XZ could even attack already running sshd too? With the specifics of how the xz injection attack worked, actually it wouldn't. libsystemd would have been loaded to implement the service-started notification, and then there is no reason to use anything further and therefore nothing to trigger the loading of the xz library. Which is kind of the point of this change: the goal is to load libraries on-demand instead of eagerly, so if there is nothing demanding the library load, the library is never loaded.

cryptonector 2y ago
Lazy loading would have achieved the same thing with less codebase churn. However, the `dlopen()` thing means that the dependencies are then optional as far as the packaging system go, and therefore you can run with fewer dependencies installed. Also, lazy loading can be turned off with an environment variable -- we would need a way to indicate that a dependency is optional in order to have something like always-lazy loading for it. There's also "filters" and "auxiliary filters", which can be used to make dependencies optional without having to go to `dlopen()`. However, IIRC filter functionality is very bare-bones or non-workin in the Linux link-editors and ld.so.

iforgotpassword 2y ago

> So upgrading XZ could even attack already running sshd too? Doesn't that work both ways, without dlopen updating to the patched version would still leave your sshd running with the old backdoored one.

im3w1l 2y ago

I think this isn't motivated by security at all. That it messed up the backdoor was a complete coincidence.

Denvercoder9 2y ago
That's correct, as evidenced by the fact that the systemd change to dlopen() liblzma was proposed and merged before the backdoor was discovered.