crypto: clear error stack in ECDH::BufferToPoint #13275

rfk · 2017-05-29T04:26:21Z

The ECDH::BufferToPoint function was not clearing the error stack on failure, and the leftover error state could cause subsequent (unrelated) signing operations to fail. This updates the function to use existing error-clearing helpers and seems to resolve the problem for me.

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
commit message follows commit guidelines

Affected core subsystem(s)

crypto

Trott · 2017-05-29T04:40:13Z

test/parallel/test-crypto-dh.js

+      'pQhByd5eyj3lgZ7m7jbchtdgyOF8Io/1ng==\n' +
+      '-----END EC PRIVATE KEY-----';
+    assert.ok(crypto.createSign('SHA256').sign(ecPrivateKey),
+              'signing should not throw');


Maybe better to use this instead?:

assert.doesNotThrow(() => { crypto.createSign('SHA256').sign(ecPrivateKey); });

thanks, will update

(Although I guess that doesn't check that you get a truthy return value. Could be added as an assertion to the function if it's important.)

Trott · 2017-05-29T04:45:41Z

/cc @nodejs/crypto

indutny

LGTM

bnoordhuis · 2017-05-29T08:30:21Z

src/node_crypto.cc

@@ -5109,6 +5109,8 @@ EC_POINT* ECDH::BufferToPoint(char* data, size_t len) {
    return nullptr;
  }

+  MarkPopErrorOnReturn mark_pop_error_on_return;


It's not wrong but I'd put this in ECDH::ComputeSecret() and ECDH::SetPublicKey(), the binding functions that call ECDH::BufferToPoint().

Maybe we should simply make it a rule that binding functions must restore the error stack.

bnoordhuis · 2017-05-29T08:33:21Z

test/parallel/test-crypto-dh.js

+  curve.generateKeys();
+  try {
+    curve.computeSecret(invalidKey);
+    assert(false, 'key generation should have failed');


This throws an exception so you still end up in the catch block. The pattern tests usually use is this:

let gotError = false; try { // ... } catch (e) { gotError = true; // ... } assert(gotError);

or use https://nodejs.org/api/assert.html#assert_assert_throws_block_error_message

The problem with assert.throws() in this case is that the test case is actually in the catch block. The pattern @bnoordhuis lays out will work as will the way it is currently done in this PR.

But the test case doesn't have to be in the catch block, or am I just missing something?

assert.throws(() => curve.computeSecret(invalidKey)); const ecPrivateKey = ...; assert.doesNotThrow(() => crypto.createSign('SHA256').sign(ecPrivateKey));

I like this last one, thanks for the suggestion.

@sam-github Ah, yes, you are right.

Functions that call `ECDH::BufferToPoint` were not clearing the error stack on failure, so an invalid key could leave leftover error state and cause subsequent (unrelated) signing operations to fail.

rfk · 2017-05-29T21:57:19Z

Thanks all, rebased to latest master and updated based on @bnoordhuis @sam-github feedback.

Trott · 2017-05-29T22:05:24Z

CI: https://ci.nodejs.org/job/node-test-pull-request/8367/

vladikoff · 2017-05-29T22:30:42Z

Will it be possible to uplift this patch to node 4 and 6?

sam-github · 2017-05-29T23:02:19Z

As a bug fix, it will land on 6.x after being released in 7.x for a while (usually a couple weeks, just to make sure there are no unexpected side effects).

4.x at this point requires an explicit request, we don't release unless we have to. It looks like not clearing the error stack can have wide-reaching consequences, but we prefer to not re-release 4.x unless necessary.

@vladikoff @rfk Do you have a need for this on 4.x? Some description of impact will make it much easier to make the case for it in 4.x

/cc @nodejs/lts

rfk · 2017-05-29T23:18:49Z

This bug affects our app because we happen to do both RSA signing and ECDH with user-submitted keys, so we recently deployed a workaround to production to guard against this being used as a DoS vector (i.e. deliberately submitting invalid ECDH keys to DoS the RSA signing functionality):

https://github.com/mozilla/fxa-auth-server/pull/1918/files#diff-539df6289b63785f3c1f4660c1db4107R174

I think this workaround means we can live without it on 4.x if we have to, although I'm not 100% confident, and I can't comment on how likely other apps are to be affected in a similar way. Having the fix on 4.x would obviously be preferable to this workaround from our point of view, but I understand that's not a trivial ask :-)

sam-github · 2017-05-30T04:43:45Z

I think that's bad enough it is worth proposing for 4.x LTS

indutny · 2017-05-30T04:46:18Z

@sam-github I agree.

jasnell · 2017-05-30T23:04:23Z

I agree that this is worth backporting to 4.x

gibfahn · 2017-05-30T23:07:57Z

+1 to backporting to v4.x.

The next question is how urgently it should happen I guess.

sam-github · 2017-05-31T00:11:37Z

Is this the first thing that might conceivably be targettable at 4.x? Maybe the thing to do is open an issue in nodejs/LTS to update 4.x, and link any candidates. I haven't heard of any others, but I'm not the best source of news on that front.

MylesBorins · 2017-05-31T06:51:09Z

there is a single commit sitting on v4.x-staging and one or two other random small ones that would be good to include. For the most part I believe we have been on top of backporting anything that would be good to have in a maintenance release... we could theoretically re audit against v6.x to double check

edit: worth mentioning there was a v4.x release last month... but if this warrants a new release it makes sense

sam-github · 2017-05-31T14:38:56Z

Landed in f666533

Functions that call `ECDH::BufferToPoint` were not clearing the error stack on failure, so an invalid key could leave leftover error state and cause subsequent (unrelated) signing operations to fail. PR-URL: #13275 Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

sam-github · 2017-05-31T14:44:33Z

It doesn't cherry-pick clean to 4.x or to 6.x, @rfk would you have the time to backport to 6.x? The process is to open a PR targeting v6.x-staging, title would be (backport 6.x) crypto: clear error stack in ECDH::BufferToPoint.

sam-github · 2017-05-31T14:55:01Z

@nodejs/lts 4.8.3 was May 2nd, maybe we could do a 4.8.4 on July 2nd (aprox), to give time for any more patches to come in? 2 months seems a reasonable maintenance cadence.

gibfahn · 2017-05-31T15:23:38Z

Backporting guide is here: https://github.com/nodejs/node/blob/master/doc/guides/backporting-to-release-lines.md

rfk · 2017-05-31T20:20:25Z

It doesn't cherry-pick clean to 4.x or to 6.x, @rfk would you have the time to backport to 6.x?

Sure, I'll try to take a look later today.

sam-github · 2017-06-02T21:01:31Z

@rfk Thank you.

Functions that call `ECDH::BufferToPoint` were not clearing the error stack on failure, so an invalid key could leave leftover error state and cause subsequent (unrelated) signing operations to fail. PR-URL: #13275 Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

Functions that call `ECDH::BufferToPoint` were not clearing the error stack on failure, so an invalid key could leave leftover error state and cause subsequent (unrelated) signing operations to fail. PR-URL: nodejs#13275 Backport-PR-URL: nodejs#13397 Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

Functions that call `ECDH::BufferToPoint` were not clearing the error stack on failure, so an invalid key could leave leftover error state and cause subsequent (unrelated) signing operations to fail. PR-URL: #13275 Backport-PR-URL: #13397 Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

Functions that call `ECDH::BufferToPoint` were not clearing the error stack on failure, so an invalid key could leave leftover error state and cause subsequent (unrelated) signing operations to fail. PR-URL: #13275 Backport-PR-URL: #13399 Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

Functions that call `ECDH::BufferToPoint` were not clearing the error stack on failure, so an invalid key could leave leftover error state and cause subsequent (unrelated) signing operations to fail. PR-URL: #13275 Backport-PR-URL: #13397 Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

Functions that call `ECDH::BufferToPoint` were not clearing the error stack on failure, so an invalid key could leave leftover error state and cause subsequent (unrelated) signing operations to fail. PR-URL: #13275 Backport-PR-URL: #13399 Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. crypto Issues and PRs related to the crypto subsystem. labels May 29, 2017

Trott reviewed May 29, 2017

View reviewed changes

rfk mentioned this pull request May 29, 2017

Backport ECDH key validation from private repo mozilla/fxa-auth-server#1918

Merged

indutny approved these changes May 29, 2017

View reviewed changes

bnoordhuis requested changes May 29, 2017

View reviewed changes

crypto: clear err stack after ECDH::BufferToPoint

4794219

Functions that call `ECDH::BufferToPoint` were not clearing the error stack on failure, so an invalid key could leave leftover error state and cause subsequent (unrelated) signing operations to fail.

sam-github approved these changes May 29, 2017

View reviewed changes

sam-github added lts-watch-v4.x labels May 30, 2017

bnoordhuis approved these changes May 30, 2017

View reviewed changes

jasnell approved these changes May 30, 2017

View reviewed changes

sam-github closed this May 31, 2017

This was referenced Jun 2, 2017

(backport 6.x) crypto: clear err stack after ECDH::BufferToPoint #13397

Closed

(backport 4.x) crypto: clear err stack after ECDH::BufferToPoint #13399

Closed

jasnell mentioned this pull request Jun 5, 2017

8.1.0 Proposal #13483

Closed

gibfahn mentioned this pull request Jun 15, 2017

Auditing for 6.11.1 nodejs/Release#230

Closed

3 tasks

MylesBorins mentioned this pull request Jul 18, 2017

v6.11.2 proposal #14356

Merged

MylesBorins mentioned this pull request Sep 20, 2017

v4.8.5 proposal #15507

Closed

MylesBorins mentioned this pull request Oct 25, 2017

v4.8.6 proposal #16500

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

crypto: clear error stack in ECDH::BufferToPoint #13275

crypto: clear error stack in ECDH::BufferToPoint #13275

rfk commented May 29, 2017

Trott May 29, 2017 •

edited

Loading

rfk May 29, 2017

Trott May 29, 2017

Trott commented May 29, 2017

indutny left a comment

bnoordhuis May 29, 2017

bnoordhuis May 29, 2017

sam-github May 29, 2017

Trott May 29, 2017

sam-github May 29, 2017 •

edited by gibfahn

Loading

rfk May 29, 2017

Trott May 29, 2017

rfk commented May 29, 2017

Trott commented May 29, 2017

vladikoff commented May 29, 2017

sam-github commented May 29, 2017

rfk commented May 29, 2017

sam-github commented May 30, 2017

indutny commented May 30, 2017

jasnell commented May 30, 2017

gibfahn commented May 30, 2017

sam-github commented May 31, 2017

MylesBorins commented May 31, 2017 •

edited

Loading

sam-github commented May 31, 2017

sam-github commented May 31, 2017

sam-github commented May 31, 2017

gibfahn commented May 31, 2017 •

edited

Loading

rfk commented May 31, 2017

sam-github commented Jun 2, 2017

crypto: clear error stack in ECDH::BufferToPoint #13275

crypto: clear error stack in ECDH::BufferToPoint #13275

Conversation

rfk commented May 29, 2017

Checklist

Affected core subsystem(s)

Trott May 29, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Trott commented May 29, 2017

indutny left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sam-github May 29, 2017 • edited by gibfahn Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rfk commented May 29, 2017

Trott commented May 29, 2017

vladikoff commented May 29, 2017

sam-github commented May 29, 2017

rfk commented May 29, 2017

sam-github commented May 30, 2017

indutny commented May 30, 2017

jasnell commented May 30, 2017

gibfahn commented May 30, 2017

sam-github commented May 31, 2017

MylesBorins commented May 31, 2017 • edited Loading

sam-github commented May 31, 2017

sam-github commented May 31, 2017

sam-github commented May 31, 2017

gibfahn commented May 31, 2017 • edited Loading

rfk commented May 31, 2017

sam-github commented Jun 2, 2017

Trott May 29, 2017 •

edited

Loading

sam-github May 29, 2017 •

edited by gibfahn

Loading

MylesBorins commented May 31, 2017 •

edited

Loading

gibfahn commented May 31, 2017 •

edited

Loading