New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CVE-2018-1000805] Server-side auth vulnerability #1283
Comments
The reporter initiated the CVE generation process, but it's been a few days with no movement on the part of the CVE creating authority & they've got a visible backlog as well. I'm probably going to release this patch, update this ticket with the details, and then just update the changelog & ticket once the CVE is actually assigned, for documentation reasons. Doesn't seem worthwhile to delay patch release just so we can bake it in, if it's going to take this long. We'll see, maybe I'll get lucky and the time it takes me to do the rest of my release cycle will give them enough of a window 😝 |
Kicking around the idea of using this as the place to say "1.x is dead". If not now, when? I just put in the work in #1291 to make it even easier to forward port 2.0.x up to master, but extending that to 1.17/1.18 is an even bigger kettle of fish, and the problems with 1.18 adding features not present in 2.0/2.1 (preventing a straight merge-up) will never go away. A counterpoint would be "but...it's a CVE level security issue!". However, see above: what about the next one? The one after that? It's clear that people are recently digging into the 15 year old, barely ever really worked on server functionality; there will be other important bugs for the, I want to say, 0.1% of the userbase that uses this in server mode. Do I backport all of them? Support windows are always a function of maintainer time/effort, and I'm very short on that these days. Paramiko 2.0 came out in April 2016 and did not change anything but an install requirement. Users still on 1.17.x really need to get moving :) |
Unrelated: still no movement on the CVE-tracking spreadsheet I was linked to. I didn't actually get all the way to merging this today (though I did make progress) so we'll see if it pops up before I finish/merge... |
Took longer to identify a good way to really test this, than anticipated, thanks to the codebase being emphatically not designed with testing in mind 😭 On the plus side I identified a strongly related pseudo-bug which has been fixed (doubt it affects anyone who isn't running Paramiko on both ends of a conversation, but...). Two threads yelling " |
Updated desc with details. waiting for Travis to be all green before I release...though they seem to be having a bad day. EDIT: Enough matrix cells are passing that I think I am just gonna release now, actually. |
2.0.9 et al are on PyPI 🎉 |
Considering that it's the second important security problem in a short time frame and that the exploit seems relatively easy to find, can't we anticiptate many other problems of this kind to pop up? Considering that the server feature of paramiko is probably seldom used, couldn't we entertain the idea of stripping paramiko of its server functionality to avoid all this pain? |
Or, maybe, disable it unless an environment variable of the |
The server-side vulnerability in Paramiko 2.1.5 does not affect us (we're only using Paramiko in client mode), but it doesn't hurt to require a version where the vulnerability is fixed. References: https://nvd.nist.gov/vuln/detail/CVE-2018-1000805 paramiko/paramiko#1283
The server-side vulnerability in Paramiko 2.1.5 does not affect us (we're only using Paramiko in client mode), but it doesn't hurt to require a version where the vulnerability is fixed. References: https://nvd.nist.gov/vuln/detail/CVE-2018-1000805 paramiko/paramiko#1283
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:
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:
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.AuthHandler
, both maintain a few "handler tables" for dispatching on message types within the main event loop; e.g. seeMSG_USERAUTH_REQUEST
, dispatch to an auth request handler method.MSG_USERAUTH_SUCCESS
to the server. This is normally a server-to-client only message!AuthHandler
) intended for use by client use cases, because there is no differentiation in play.@property
.TODO
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 sometimeThe text was updated successfully, but these errors were encountered: