[pjmlp]

By finally acknowledging that loading plugins via shared objects is a bad idea, and it was only valuable in the days of resource constrained computers.

Any application that wants to use plugins and is security sensitive, should adopt OS IPC, and load them as separate processes.

[brasic]

Process separation was already in place. The PKCS#11 library is loaded by a long lived helper process, not ssh-agent itself.

  > (Note to the curious readers: for security reasons, and as explained in
  > the "Background" section below, ssh-agent does not actually load such a
  > shared library in its own address space (where private keys are stored),
  > but in a separate, dedicated process, ssh-pkcs11-helper.)

That didn’t help because the long lived nature of the helper process exposed it to the shared lib side effects such that they could be chained into a gadget. If I understand correctly, the long life is important for interacting with many smart cards and HSMs because of their APIs.

If you are suggesting that there should be an IPC API for this process and vendors ship a full program that speaks it, that seems reasonable at a glance, but not really something the OpenSSH project can dictate.

[pjmlp]

Indeed, my suggestion is zero dynamic libraries in security critical code/applications.

If security is a goal, loading in-process foreign code is already a lost battle.

Plugins as dynamic libraries made sense when we were fighting for each MB, not when people have hardware where they go to the extreme of running containers for every application they can think of.

Bonus, processes aren't as heavy as containers.

[eptcyka]

Would IPC help if a remote attacker was still allowed to execute arbitrary plugins?

[pjmlp]

It would help against attacks that depend on corrupting process address space, like this one.

Additionally, one could use OS security features to reduce API surface for each plugin, depending on what they are actually supposed to be doing, e.g. no need for file system access if they only do in-memory data processing.

As for "would it help in 100% of the attacks?", no.

Even if there were no plugins support, there is still the possibility to exploit logical errors anyway.

What matters is having a balance between reducing attack surface, and application features, and it than regard process sandboxing is much safer than loading foreign code in-process.