Re: Symantec writeup very poor @Gorbachov
And that is the point of my OP. The writeup is so vague that we're all guessing.
I admit that the client side attack I sketched out requires access as a user on the client system, but that is a lot easier to get than breaking privileged access. All the usual vectors of Java, side-jacking and social manipulation etc could end up with a process owned by the user in question, which would have whatever access the user has on the client system (but no special privilege). This would mean that it could execute a series of shell commands as the user, run an SSH client program itself, read the user's public key and any private keys stored on the client system, and if the keys are passphrase-less keys, use them to gain access to other systems.
Here is a scenario, possibly far-fetched, and I've not worked it all through, but it could set LD_LIBRARY_PATH somewhere like .bashrc so that a local directory appears before some of the system library directories. It then looks at the Linux distro, and fetches a specific hacked SSL or other (including libc, I suppose) library for that distro off of the internet, and puts it in the directory.
Following this, every legitimate program including SSH client sessions that the user starts could be running with malicious code from the bogus library. If it replaced the right routines, you could have a key-logger, and this key-logger will be able to capture the passphrases as they are typed, giving access to all of the user's private SSH keys. It could also capture any passwords that are typed for remote systems.
OK. No breach of privilege required so far. Everything has been done as the user in question.
So, the user is an admin, who foolishly has the private key of a remote account that has some privilege in their keystore. The malicious code then has access to the remote system with privileged to attack that system.
Or, say, the admin has sensibly used a non-privileged account to access the far system, but then uses sudo to issue commands on that system via a compromised SSH session. Compromised client can then capture the password that the user uses with sudo, and again has access to the remote system with privileged to attack that system (unless sudo is really locked down hard).
In both cases, it could inject commands, or even start it's own SSH client session using the captured credentials.
How safe do you feel?
Please note that this attack could be used on almost any OS that allows dynamic binding of libraries at runtime, and provides an over-ride of the default system paths to the libraries. I've sketched it out as a Linux/UNIX attack as that is what I know best, but I seriously suspect that similar attacks are possible on other OSs.
Eternal vigilance is called for, especially for admins, regardless of the platform they are using.