Skip to content
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

pkey: __eq__() should not use hash() #106

Merged
merged 2 commits into from
Nov 29, 2021
Merged

pkey: __eq__() should not use hash() #106

merged 2 commits into from
Nov 29, 2021

Conversation

ploxiln
Copy link
Owner

@ploxiln ploxiln commented Nov 29, 2021

... because hash() is too weak and not intended for this.
Also simplify __cmp__() (which did work fine).

This fixes a security flaw. If you are using Paramiko with Python 2, or a Python 3 which is running with PYTHONHASHSEED=0, it is possible for an attacker to craft a new keypair from an exfiltrated public key, which Paramiko would consider equal to the original key.

This could enable attacks such as:

  • Paramiko server processes would incorrectly authenticate the attacker (using their generated private key) as if they were the victim.
  • Paramiko client processes would incorrectly validate a connected server (when host key verification is enabled) while subjected to a man-in-the-middle attack. This impacts more users than the server-side version, but also carries higher requirements for the attacker, namely successful DNS poisoning or other MITM techniques.

Reported by @jun66j5 in paramiko#908
Vulnerability description by Jeff Forcier jeff@bitprophet.org
see also https://www.paramiko.org/changelog.html#2.8.1

ploxiln and others added 2 commits November 29, 2021 00:29
... because `hash()` is too weak and not intended for this.
Also simplify `__cmp__()` (which did work fine).

This fixes a security flaw. If you are using Paramiko with Python 2,
or a Python 3 which is running with PYTHONHASHSEED=0, it is possible
for an attacker to craft a new keypair from an exfiltrated public key,
which Paramiko would consider equal to the original key.

This could enable attacks such as:
 * Paramiko server processes would incorrectly authenticate the attacker
   (using their generated private key) as if they were the victim.
 * Paramiko client processes would incorrectly validate a connected
   server (when host key verification is enabled) while subjected to a
   man-in-the-middle attack. This impacts more users than the server-side
   version, but also carries higher requirements for the attacker, namely
   successful DNS poisoning or other MITM techniques.

Reported by @jun66j5 in paramiko#908
Vulnerability description by Jeff Forcier <jeff@bitprophet.org>
@ploxiln ploxiln merged commit 6d7cbb4 into master Nov 29, 2021
@ploxiln ploxiln deleted the key_eq_fix branch December 12, 2021 02:37
ploxiln added a commit that referenced this pull request Jan 4, 2022
bug introduced by #106 (79da092)
and fixed for python3 in #114 (30a09ce)
ploxiln added a commit that referenced this pull request Jan 4, 2022
bug introduced by #106 (79da092)
and fixed for python3 in #114 (30a09ce)
ploxiln added a commit that referenced this pull request Jan 6, 2022
bug introduced by #106 79da092
and fixed for python3 in #114 30a09ce
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants