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

[backport 1.0.2] Fix for BN_FLG_CONSTTIME leakage in BN_CTX #8295

Closed
wants to merge 2 commits into from

Conversation

romen
Copy link
Member

@romen romen commented Feb 20, 2019

This is a backport of #8253 to 1.0.2-stable:

  • editing of crypto/bn/bn_ctx.c during cherry-picking was trivial (but for the copyright year/boilerplate);
  • test/bntest.c required major changes to integrate in the older testing framework;
  • I did not modify any of the license notices, not even the copyright years, as I noticed none of them had been touched in a long time, even if there were more recent modifications.

Checklist

  • tests are added or updated
  • update copyright years

This commit adds a simple unit test to make sure that the constant-time
flag does not "leak" among BN_CTX frames:

- test_ctx_consttime_flag() initializes (and later frees before
  returning) a BN_CTX object, then it calls in sequence
  test_ctx_set_ct_flag() and test_ctx_check_ct_flag() using the same
  BN_CTX object.
- test_ctx_set_ct_flag() starts a frame in the given BN_CTX and sets the
  BN_FLG_CONSTTIME flag on some of the BIGNUMs obtained from the frame
  before ending it.
- test_ctx_check_ct_flag() then starts a new frame and gets a number of
  BIGNUMs from it. In absence of leaks, none of the BIGNUMs in the new
  frame should have BN_FLG_CONSTTIME set.

In actual BN_CTX usage inside libcrypto the leak could happen at any
depth level in the BN_CTX stack, with varying results depending on the
patterns of sibling trees of nested function calls sharing the same
BN_CTX object, and the effect of unintended BN_FLG_CONSTTIME on the
called BN_* functions.

This simple unit test abstracts away this complexity and verifies that
the leak does not happen between two sibling functions sharing the same
BN_CTX object at the same level of nesting.

(manually cherry picked from commit fe16ae5)
@romen romen added the branch: 1.0.2 Merge to OpenSSL_1_0_2-stable branch label Feb 20, 2019
@romen romen self-assigned this Feb 20, 2019
@romen
Copy link
Member Author

romen commented Feb 20, 2019

@mattcaswell, please, on top of the review, could you also advise regarding the copyright year issue?

@mattcaswell mattcaswell added the approval: done This pull request has the required number of approvals label Feb 20, 2019
@@ -330,6 +335,15 @@ int main(int argc, char *argv[])
goto err;
(void)BIO_flush(out);
#endif

/* silently flush any pre-existing error on the stack */
ERR_clear_error();
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mattcaswell (cfr. https://github.com/openssl/openssl/pull/8294/files#r258680809)

Here i do ERR_clear_error() to prevent previously uncleared errors to confuse the user in case test_ctx_consttime_flag() fails.

I decided to do so given that if this point of main is reached none of the errors in the queue was being printed anyway before this commit.

levitte pushed a commit that referenced this pull request Feb 21, 2019
This commit adds a simple unit test to make sure that the constant-time
flag does not "leak" among BN_CTX frames:

- test_ctx_consttime_flag() initializes (and later frees before
  returning) a BN_CTX object, then it calls in sequence
  test_ctx_set_ct_flag() and test_ctx_check_ct_flag() using the same
  BN_CTX object.
- test_ctx_set_ct_flag() starts a frame in the given BN_CTX and sets the
  BN_FLG_CONSTTIME flag on some of the BIGNUMs obtained from the frame
  before ending it.
- test_ctx_check_ct_flag() then starts a new frame and gets a number of
  BIGNUMs from it. In absence of leaks, none of the BIGNUMs in the new
  frame should have BN_FLG_CONSTTIME set.

In actual BN_CTX usage inside libcrypto the leak could happen at any
depth level in the BN_CTX stack, with varying results depending on the
patterns of sibling trees of nested function calls sharing the same
BN_CTX object, and the effect of unintended BN_FLG_CONSTTIME on the
called BN_* functions.

This simple unit test abstracts away this complexity and verifies that
the leak does not happen between two sibling functions sharing the same
BN_CTX object at the same level of nesting.

(manually cherry picked from commit fe16ae5)

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from #8295)
levitte pushed a commit that referenced this pull request Feb 21, 2019
(cherry picked from commit c8147d3)

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from #8295)
@romen
Copy link
Member Author

romen commented Feb 21, 2019

Merged to 1_0_2-stable:

@romen romen closed this Feb 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approval: done This pull request has the required number of approvals branch: 1.0.2 Merge to OpenSSL_1_0_2-stable branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants