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

Fix rsaz 512 overflow bug [1.0.2] #10576

Conversation

@bernd-edlinger
Copy link
Member

@bernd-edlinger bernd-edlinger commented Dec 4, 2019

Fix for CVE-2019-1551, 1.0.2 branch, (white space only merge conflicts in the assembler part)

Checklist
  • documentation is added or updated
  • tests are added or updated
dot-asm and others added 2 commits Dec 4, 2019
There is an overflow bug in the x64_64 Montgomery squaring procedure used in
exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis
suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a
result of this defect would be very difficult to perform and are not believed
likely. Attacks against DH512 are considered just feasible. However, for an
attack the target would have to re-use the DH512 private key, which is not
recommended anyway. Also applications directly using the low level API
BN_mod_exp may be affected if they use BN_FLG_CONSTTIME.

CVE-2019-1551
We have always a carry in %rcx or %rbx in range 0..2
from the previous stage, that is added to the result
of the 64-bit square, but the low nibble of any square
can only be 0, 1, 4, 9.

Therefore one "adcq $0, %rdx" can be removed.
Likewise in the ADX code we can remove one
"adcx %rbp, $out" since %rbp is always 0, and carry is
also zero, therefore that is a no-op.
@paulidale paulidale dismissed their stale review Dec 4, 2019

Expecting CI failurs.

@paulidale
Copy link
Contributor

@paulidale paulidale commented Dec 4, 2019

Adding cross references.
Master fix in: #10574
1.1.1 fix in: #10575

openssl-machine pushed a commit that referenced this pull request Dec 6, 2019
There is an overflow bug in the x64_64 Montgomery squaring procedure used in
exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis
suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a
result of this defect would be very difficult to perform and are not believed
likely. Attacks against DH512 are considered just feasible. However, for an
attack the target would have to re-use the DH512 private key, which is not
recommended anyway. Also applications directly using the low level API
BN_mod_exp may be affected if they use BN_FLG_CONSTTIME.

CVE-2019-1551

Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from #10576)
openssl-machine pushed a commit that referenced this pull request Dec 6, 2019
We have always a carry in %rcx or %rbx in range 0..2
from the previous stage, that is added to the result
of the 64-bit square, but the low nibble of any square
can only be 0, 1, 4, 9.

Therefore one "adcq $0, %rdx" can be removed.
Likewise in the ADX code we can remove one
"adcx %rbp, $out" since %rbp is always 0, and carry is
also zero, therefore that is a no-op.

Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from #10576)
openssl-machine pushed a commit that referenced this pull request Dec 6, 2019
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from #10576)
@bernd-edlinger
Copy link
Member Author

@bernd-edlinger bernd-edlinger commented Dec 6, 2019

Merged to 1.0.2, thanks!

tetatetit added a commit to tetatetit/openssl that referenced this pull request Dec 20, 2019
There is an overflow bug in the x64_64 Montgomery squaring procedure used in
exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis
suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a
result of this defect would be very difficult to perform and are not believed
likely. Attacks against DH512 are considered just feasible. However, for an
attack the target would have to re-use the DH512 private key, which is not
recommended anyway. Also applications directly using the low level API
BN_mod_exp may be affected if they use BN_FLG_CONSTTIME.

CVE-2019-1551

Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from openssl#10576)
tetatetit added a commit to tetatetit/openssl that referenced this pull request Dec 20, 2019
We have always a carry in %rcx or %rbx in range 0..2
from the previous stage, that is added to the result
of the 64-bit square, but the low nibble of any square
can only be 0, 1, 4, 9.

Therefore one "adcq $0, %rdx" can be removed.
Likewise in the ADX code we can remove one
"adcx %rbp, $out" since %rbp is always 0, and carry is
also zero, therefore that is a no-op.

Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from openssl#10576)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants