[phire]

This is barking up the wrong tree.

Using IFUNC to patch sshd was kind of elegant, it achieved rootkit like behaviour with a pre-existing mechanism. And sure, it might be possible for a secure daemon like sshd to drop enough privileges that it could protect itself from a malicious dynamically linked library.

But IFUNC was not required, neither was systemd. The game was lost as soon as the attacker had arbitrary code installed in a semi-common library. It doesn't have to get linked directly with sshd, it only needed to be linked into any program running as root, at least one time.

Most programs make zero effort to sandbox themselves, and as soon as one of those links with the malicious library, it could do anything. Like indirectly targeting sshd by patching its binary on disk (optionally hiding it with a rootkit), or using debug APIs to patch sshd in memory.

IFUNC, systemd, and the patched openssh are all irrelevant to the issue, that was simply the route this attacker took to leverage their foothold in libxz. There are thousands of potential routes the attacker could have taken, and we simply can't defend from all of them.

[AshamedCaptain]

> Most programs make zero effort to sandbox themselves, and as soon as one of those links with the malicious library, it could do anything. Like indirectly targeting sshd by patching its binary on disk (optionally hiding it with a rootkit), or using debug APIs to patch sshd in memory.

I do not understand how you even expected sshd to sandbox itself. Its entire purposes is to (a) daemonize , (b) allow incoming connections in and then (c) forward (possibly-root) shell statements. All 3 things are 100% required for sshd and would have already allowed an attack like this. Any talk about sandboxing here (or dropping privileges) is wishful thinking.

[zaphar]

I recently tried to make something properly sandboxed and, my goodness, we have basically crafted an ecosystem where everything needs access to everything. No wonder docker, despite all it's faults, is how everyone does it. You need an entire linux distro completely accessible in your sandbox.

[PaulHoule]

POSIX is a millstone around the neck of the software industry.

If you wanted to do something really new in operating systems, you might think "POSIX is insecure" or "POSIX is bloated", etc. If you have a fundamentally different API though you have to write a whole new userspace. You're going to put in a POSIX personality so you can run bash and vim and nethack but once you do that you have the insecurity, bloat, etc.

[jnwatson]

POSIX is backwards in so many ways. It freezes in time the OS innovations of the 70s.

[robertdfrench]

I have a conspiracy theory, unsupported by facts, that Richard Stallman secretly invented POSIX as a way to get the proprietary UNIX vendors to waste time on something whose only value was to make it easier for folks to port their apps to GNUUUUUUUU/Linux.

[teddyh]

Stallman only invented the name “POSIX”, not the standard itself.

[robertdfrench]

that's what Big POSIX wants you to think pal

[xorcist]

It was not essential to the exploit, but that does not mean it was irrelevant. More commonly used libraries are watched harder. The exploit was made much, much, worse by its indirect use by way of systemd. Approximately nobody wanted that feature and it still went in. That's something we need to be able to discuss.

[AshamedCaptain]

But the fact that it was done indirectly from systemd has nothing to do with IFUNC.

[robertdfrench]

> The game was lost as soon as the attacker had arbitrary code installed in a semi-common library.

That is not quite true! You still have to get the code to be executed. I can call dlopen on a malicious library, load it into my address space, and still not necessarily invoke any dangerous functions. What ifunc did in this case is allow the attacker to manipulate symbols so that calls to real, well-behaved xz routines were instead redirected to the attack payload.

[belorn]

There is always selinux if we want to add protection against arbitrary code running as root. Just because something operate as root does not mean it must have privileged access to everything.

[PaulHoule]

Ouch! SELinux sorta works for the software which is packed in with the operating system which you may or may not care about. If you want to get that software to do something different or have software that you really care about (like the application server that your web site runs on) controlled by SELinux it is difficult enough that the usual answer is "disable SELinux" or "don't apply it"

[cenamus]

Did anyone look into whether OpenBSD has privilege separated sshd enough for that exploit to not be possible?

[kristjank]

OpenBSD exposes pledge() and unveil(), which allow programs to only access things they declare they need. So, even if the running SSH process gets exploited, it can't do anything the user it's running as can't do. sshd afaik runs as a root process which after authentication forks into another process, running as the target user.