-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
Memory leak in DiffieHellman.set{Privat,Public}Key() and some suggestions #8377
Labels
Comments
/cc @nodejs/crypto |
@nodejs/crypto Should this stay open? |
I added a commit to #14122 that fixes the memory leak (thanks for the bug report!) As to the other suggestions, I don't have strong opinions except for the usual backwards compatibility concerns. Any API change or deprecation is going to be a drawn out process. |
bnoordhuis
added a commit
to bnoordhuis/io.js
that referenced
this issue
Jul 17, 2017
Fix a memory leak in dh.setPublicKey() and dh.setPrivateKey() where the old keys weren't freed. Fixes: nodejs#8377
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
In https://github.com/nodejs/node/blob/master/src/node_crypto.cc#L4757 (void DiffieHellman::SetPublicKey):
but
...->pub_key
might already point to allocated memory, which is never freed.man OpenSSL says:
So it should be enough to pass diffieHellman->dh->pub_key as third parameter, instead of 0.
DiffieHellman::SetPrivateKey, a few lines later, has the same issue.
Alternatively, we could forbid calling set{Public,Private}Key after a key exists, because the DH api does not seem to encourage reuse of DiffieHellman classes:
generateKeys()
always returns the same key after the first call. According to OpenSSL documentation, this is caused bydh->priv_key
being non-null.Changing
generateKeys()
to return a new key on every call would be breaking API change; OTOHsetPrivateKey()
can (currently) not be used to resetdh->priv_key
to null (while freeing possibly allocated memory).All in all this suggests that the user should create a new DiffieHellman class for each key exchange, but the nodejs binding again thwarts such efforts:
Therefore I'd also suggest to add another "overload" to
createDiffieHellman
which takes an existingDiffieHellman
class and creates a new one with the same Prime and Generator, with empty keys, but without calling (slow)DH_check
(the parameters have already been checked earlier!) by just copying the.verifyError
result.A side note: Given the trivial conversion (via
.getPrime
, as shown above) of aDiffieHellmanGroup
class to aDiffieHellman
class and the same C++ class under the hood, the non-existence of.set{Public,Private}Key
on theDiffieHellmanGroup
class obtained by.getDiffieHellman
is completely arbitrary and unnecessary.BTW, why not add some way to directly use PEM-encoded
----BEGIN DH PARAMETERS-----
...END
parameters viaPEM_read_bio_DHparams
and a memory BIO, e.g. by overloadinggetDiffieHellman()
? E.g. RSA already reads keys in PEM format (via OpenSSL), and the natural format of new DiffieHellman Paramaters generated by (time-consuming!)openssl dhparams [bits]
is PEM, which currently has be converted manually to a format readable by nodejs...The text was updated successfully, but these errors were encountered: