Re: When SSH standards noncompliance is a "feature"
"Jeffrey T. Hutzelman" <[email protected]> Thu, 10 Jun 2021 13:14:11 +0000
| Newsgroups | gmane.ietf.secsh |
|---|---|
| Message-ID | <[email protected]> |
Peter, that's a terrible suggestion! Specifically the "and then eaten" part, which may cause the participants to become infected with this idiocy. I think "and then launched into the sun" would be safer and possibly more effective. On a more serious note... One could simply lie about the software version, but omitting it entirely is indeed noncompliant. Of course, lying will thwart the efforts some implementations have gone to over the years to interoperate with even badly broken software. I suppose that's a legitimate tradeoff for a server operator to make. In reality, this is not a vulnerability. The bad people are going to try all the known attacks anyway. About the only thing this does is prevent security scanning software from reporting the apparent presence of a vulnerable version. -- Jeff ________________________________ From: Peter Gutmann <[email protected]> Sent: Thursday, June 10, 2021 01:00 To: [email protected] Subject: When SSH standards noncompliance is a "feature" So RFC 4253 says: When the connection has been established, both sides MUST send an identification string. This identification string MUST be SSH-protoversion-softwareversion SP { comments - optional } CR LF However it seems like some security auditors, or more likely the security audit tool they charge thousands of dollars to run on your behalf on your network, has decided that this is a vulnerability, and as a result truncate the SSH ID after the protocol version. In other words they've come up with the brilliant idea of modifying the SSH handshake to not implement the SSH protocol correctly any more but still expect clients to connect to it... and oddly enough most clients do (Filezilla was the example I was given that found nothing wrong with this invalid SSH ID). My suggestion was that whoever came up with standards noncompliance as a security feature be killed and then eaten to prevent them from coming back again as a zombie. (Actually my first suggestion was going to be that if they're so keen to use standards noncompliance as a security feature then why don't they invent their own incompatible security protocol and then nothing can connect and they'll be perfectly secure, but there's a limit to how sarcastic you can be with clients). Peter.