2

How did a bug like the recent libssh vulnerability come to exist? Exactly what is the nature and root cause of the bug?

From libssh's website:

libssh versions 0.6 and above have an authentication bypass vulnerability in the server code. By presenting the server an SSH2_MSG_USERAUTH_SUCCESS message in place of the SSH2_MSG_USERAUTH_REQUEST message which the server would expect to initiate authentication, the attacker could successfully authentciate (sic) without any credentials.

To me, this just raises more questions to me: why would the server trust anything from the client? Why does SSH2_MSG_USERAUTH_SUCCESS even exist at all? Is it part of the ssh protocol?

jamesdlin
  • 2,055
  • 1
  • 12
  • 13

1 Answers1

6

The underlying issue that caused this bug and many bugs like it is a false assumption. namely that a certain message (SSH2_MSG_USERAUTH_SUCCESS) would only ever be sent by a server to a client...libssh failed to consider that a malicious client might send this message to a server. Based on this failed assumption the library had a single state machine (shared by client and server implementations) that clicks to on (as in connection accepted) when this message arrives. It is generally false assumptions that create security holes.

DarkMatter
  • 2,681
  • 2
  • 6
  • 23
  • 1
    If that's the case, then I would attribute the failure to the client and server sharing a single state machine implementation. – jamesdlin Oct 17 '18 at 20:37
  • 4
    That's what I said but the question was what is the root cause of the bug (not just the nature of the bug) – DarkMatter Oct 17 '18 at 20:42
  • I mean that to me this seems backwards: I would consider the poor design decision of reusing the client state machine in the server to be the root cause, and that reuse caused what should have been a valid assumption to be false. – jamesdlin Oct 17 '18 at 21:12
  • 2
    @jamesdlin there is nothing inherently wrong with using a single state machine for the connection. However, code which updates or transitions state *must* validate inputs. – David Oct 17 '18 at 21:41
  • @David While there might not be anything inherently wrong with that design, it seems to me like a bad choice that invites trouble. The server shouldn't be executing code meant to be executed only by clients; the server requires a completely different level of trust. – jamesdlin Oct 17 '18 at 22:31
  • And that's actually the crux of my question, which is why a libssh server would even be *capable* of handling a message meant only for a client, and the answer to that is that the server and client share code. – jamesdlin Oct 17 '18 at 22:36
  • @jamesdlin The libssh library is just a library. It does not know if it is being used as a client or a server, so it must support both being a client _and_ a server. – forest Oct 18 '18 at 03:59
  • @forest That's a fair point, but while the same binary needs to support both (which IMO is also a questionable decision), the server and client code paths don't need to be the same, particularly for *authentication* which should be quite different. – jamesdlin Oct 18 '18 at 04:56