back to article SSH shaken, not stirred by Terrapin vulnerability

A vulnerability in the SSH protocol can be exploited by a well-placed adversary to weaken the security of people's connections, if conditions are right. In a successful man-in-the-middle attack, the adversary may be able to force SSH clients to use weaker authentication methods and disable some defense mechanisms. It is hard …

  1. Ozzard
    FAIL

    Protocol bugs: always the hardest to fix

    Lovely attack - props to the folks discovering it. Looks like I have a busy Christmas patching a very large number of systems.

    1. This post has been deleted by its author

      1. FIA Silver badge

        Re: Protocol bugs: always the hardest to fix

        I don't understand what that means?

        How is a defined protocol not deterministic? What makes you think you can less vaguely define your 'API' better than someone else can define a 'Protocol'?

        (I'll be honest, not really sure what you're saying).

        What has asynchronicity and streaming got to do with it?

        1. RedGreen925

          Re: Protocol bugs: always the hardest to fix

          "What has asynchronicity and streaming got to do with it?"

          I think you miss the sarcasm in the posting using some made up gobbly gook to deride the goobly gook used in the article.

  2. Anonymous Coward
    Anonymous Coward

    Hmm...

    It's usually standard practice to hash all negotiation headers and verify both sides agree on the result before allowing connection (mostly included in the generation of the shared secret). Seems odd to base it only on the number of packets sent/received. Ah well... patch away!

    1. Skrillor

      Re: Hmm...

      Actually, SSH does this, but only partially. To ensure the authenticity of the handshake, both peers compute a so-called exchange hash over all cryptographically relevant parameters. The server signs the exchange hash to prove his possession of the host key. However, one key observation that we made that eventually led to the attack is that the exchange hash is not a complete transcript hash but a selective hash. It does not include messages like the ignore message, which we used to offset sequence numbers during handshake.

      1. Wzrd1 Silver badge

        Re: Hmm...

        And annoyingly, OpenWRT shows this vulnerability. Ubuntu 22.04 doesn't have it.

  3. albegadeep

    Why is 'ignore' a thing?

    Why would you send a message with the intent of the other end ignoring it? Some kind of keepalive?

    Seems like one mitigation (which would require a protocol change) would be to not count ignore messages as counted messages (if they get lost, who cares?).

    1. Skrillor

      Re: Why is 'ignore' a thing?

      According to the specification, IGNORE is intended to harden SSH against traffic analysis. Also, not counting IGNORE messages is no good solution either. Theoretically, a secure channel should guarantee the integrity, authenticity, and confidentiality of the messages passed through. Not counting IGNORE would allow attackers to mess with the secure channel badly, allowing arbitrary removal and addition of these messages. Also, there are more than ignore messages that can be used for our attack ;) Basically, any ignored message not causing a response is suitable - other options are SSH_MSG_DEBUG or SSH_MSG_UNIMPLEMENTED.

      1. yetanotheraoc Silver badge

        Re: Why is 'ignore' a thing?

        So you're saying we can't ignore the IGNORE.

      2. albegadeep

        Re: Why is 'ignore' a thing?

        Ah, understood. Thanks for the explanation.

  4. MONK_DUCK

    Can this be fix though

    Trying to figure out if the fix can actually work fully, the article mentions the server and client both must both be patched. Could not a MITM simulate an unpatched client or server.

    Guess I'll have to read the paper itself.

    1. diodesign (Written by Reg staff) Silver badge

      It can, if both sides pay attention

      The KEX protocol will be on automatically, as I understand it, and thus thwart an MITM attacker when both client and server are using it. See the OpenSSH release notes linked to and also the PROTOCOL file.

      I guess it will be up to the client and server to complain to the user that one end isn't using KEX when it's expected or desired.

      C.

  5. bazza Silver badge

    Proof

    The ARS article on this topic reminds us that, back in 2016, proofs that this kind of thing couldn't happen in SSH were published (and presumably, widely lauded).

    Ooops.

  6. Claptrap314 Silver badge

    I am so confused...

    Why, oh why are the messages being sent not numbered? Even if there is not an upper bound on the total number of messages, a one-byte prefix would require that some multiple of 256 messages be dropped in order for this attack to be effective.

    Alternatively, why, oh is the signature not over all of the effective message contents?

    I've never looked at the ssh protocol, but this just doesn't add up.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like