Skip to content

[CVE-2018-1000805] Server-side auth vulnerability #1283

Closed
@bitprophet

Description

@bitprophet

Background

Security vulnerability on Paramiko's server side (NOT client side), as reported by Daniel Hoffman of usd AG.

I was emailed by the above on 2018.08.31 and (due to being on vacation at the time) was able to review the initial information on today's date (2018.09.06). Daniel submitted the following:

  • sample vanilla-enough server-side code loop (using standard/public API members with no additions besides logging and specification of expected auth mechanisms)
  • sample client-side code which exploits the vulnerability in the server (TK)
  • detailed explanation of why the exploit works, with references to parts of Paramiko's server-side code
  • recommended fix

At time of writing, I have done a cursory read of the code snippets & explanation, and confirmed that the sample code does appear to exhibit the described exploit.

Actual, post-fix description

The crux of it is as follows:

  • The exploit is that malicious clients can trick the Paramiko server into thinking the client is authenticated, without providing any authentication. Yup. That's bad. Real bad.
  • The flaw is in the Transport class, which is (regrettably IMHO; it's not my design) used unadulterated for both client and server use cases. No subclassing or anything; only a few very minor branch points.
  • It, and its symbiont class AuthHandler, both maintain a few "handler tables" for dispatching on message types within the main event loop; e.g. see MSG_USERAUTH_REQUEST, dispatch to an auth request handler method.
  • Smart users will already have put the previous facts together to figure out that...the exploit is the client sending MSG_USERAUTH_SUCCESS to the server. This is normally a server-to-client only message!
    • The Paramiko server then handles this message using a handler (within AuthHandler) intended for use by client use cases, because there is no differentiation in play.
    • And because the code is so strongly shared, this ends up flipping a flag saying "the other end is authenticated", which the server code continues to reference to determine if the client passed auth.
  • Thus, a malicious client can simply send that bogus message to set itself as authenticated for the rest of the session. Open, sesame.
  • The fix has been to separate the handler tables into specific client vs server components (given that, at least for the AuthHandler where this all takes place, there are no bidirectionally useful message types) and serve up only one or the other during dispatch, never both.
    • This was done in a backwards compatible manner, replacing static dicts with a dict-returning @property.
  • Due to expediency, I have not yet expanded this fix to the other couple of tables involved, but my guess is that the AuthHandler's table was the one that needed it most; past the auth step, any incorrect messages should just result in errors from the server and not exploitable server state.
  • The fix has been backported to Paramiko 2.0 and up.

TODO

  • take up Daniel on his offer to create a CVE; less work for me, but also, a security company has more experience with that process than I do, namely "any at all"
  • double check the details of the vulnerability so that I understand it more deeply
  • consider whether the suggested fix is valid (it has to do with Paramiko's reuse of code across client/server use cases)
  • confirm exploit & fix are both valid to 1.17.x/1.18.x (at present I am still considering 1.17.x to be pseudo-LTS and getting bugfixes, though this will soon cease) and up - nope, 2.0 and up, sorry folks. it's gotta happen sometime
  • test, patch, confirm
  • changelog entry
    • NOTE: may want to wait for CVE filing if not done yet, so at least this one commit has the CVE number in it? also consider a rebase to add it to the main patch commit/s
  • merge up to all branches
  • push & release at once so fix is live
  • update this ticket with my notes/real description
  • send a security notice out via Tidelift as well as Twitter

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions