- Feb 28, 2019
-
-
Richard Levitte authored
This ensures that we don't mistakenly use C++ keywords anywhere public. Related to #8313 (cherry picked from commit 9f27d4bf32c0465270e1922365b21825a0f7a42a) Reviewed-by:
Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8359)
-
Richard Levitte authored
This makes `--strict-warnings` into a compiler pseudo-option, i.e. it gets treated the same way as any other compiler option given on the configuration command line, but is retroactively replaced by actual compiler warning options, depending on what compiler is used. This makes it easier to see in what order options are given to the compiler from the configuration command line, i.e. this: ./config -Wall --strict-warnings would give the compiler flags in the same order as they're given, i.e.: -Wall -Werror -Wno-whatever ... instead of what we got previously: -Werror -Wno-whatever ... -Wall (cherry picked from commit fcee53948b7f9a5951d42f4ee321e706ea6b4b84) Reviewed-by:
-
- Feb 27, 2019
-
-
Shane Lontis authored
Reviewed-by:
Richard Levitte <levitte@openssl.org> Reviewed-by:
Matt Caswell <matt@openssl.org> Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Since the padlock code is an engine, the assembler is for a module, not a library link to when building a program... there's a distinction. Fixes #2311 Reviewed-by:
-
Paul Yang authored
Currently SM2 shares the ameth with EC, so the current default digest algorithm returned is SHA256. This fixes the default digest algorithm of SM2 to SM3, which is the only valid digest algorithm for SM2 signature. Reviewed-by:
-
- Feb 26, 2019
-
-
Richard Levitte authored
Github PR #8246 provides a better solution to the problem. This reverts commit f11ffa505f8a9345145a26a05bf77b012b6941bd. [extended tests] Reviewed-by:
Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/8247) (cherry picked from commit 4089b4340701e3c13e07169e67a7d14519c98658)
-
Billy Brumley authored
(cherry picked from commit 1a31d801 ) Reviewed-by:
-
Nicola Tuveri authored
(cherry picked from commit b3883f77 ) Reviewed-by:
Paul Yang <yang.yang@baishancloud.com> Reviewed-by:
-
Matt Caswell authored
Reviewed-by: -
Matt Caswell authored
Reviewed-by: -
Matt Caswell authored
Follow on from CVE-2019-1559 Reviewed-by: -
Matt Caswell authored
Reviewed-by:
-
Eneas U de Queiroz authored
This restores the behavior of previous versions of the /dev/crypto engine, in alignment with the default implementation. Reported-by:
Gerard Looije <lglooije@hotmail.com> Signed-off-by:
Eneas U de Queiroz <cote2004-github@yahoo.com> Reviewed-by:
-
Eneas U de Queiroz authored
cipher_init may be called on an already initialized context, without a necessary cleanup. This separates cleanup from initialization, closing an eventual open session before creating a new one. Move the /dev/crypto session cleanup code to its own function. Signed-off-by:
-
Matt Caswell authored
Reviewed-by:
-
Richard Levitte authored
There is too high a risk that perl and OpenSSL are linked with different C RTLs, and thereby get different messages for even the most mundane error numbers. Reviewed-by:
-
Richard Levitte authored
test/shlibloadtest.c needs added code for VMS shared libraries Reviewed-by:
-
- Feb 25, 2019
-
-
Richard Levitte authored
The real cause for this change is that test/ec_internal_test.c includes ec_lcl.h, and including curve448/curve448_lcl.h from there doesn't work so well with compilers who always do inclusions relative to the C file being compiled. Reviewed-by:
-
Matt Caswell authored
Thanks to David Benjamin who reported this, performed the analysis and suggested the patch. I have incorporated some of his analysis in the comments below. This issue can cause an out-of-bounds read. It is believed that this was not reachable until the recent "fixed top" changes. Analysis has so far only identified one code path that can encounter this - although it is possible that others may be found. The one code path only impacts 1.0.2 in certain builds. The fuzzer found a path in RSA where iqmp is too large. If the input is all zeros, the RSA CRT logic will multiply a padded zero by iqmp. Two mitigating factors: - Private keys which trip this are invalid (iqmp is not reduced mod p). Only systems which take untrusted private keys care. - In OpenSSL 1.1.x, there is a check which rejects the oversize iqmp, so the bug is only reproducible in 1.0.2 so far. Fortunately, the bug appears to be relatively harmless. The consequences of bn_cmp_word's misbehavior are: - OpenSSL may crash if the buffers are page-aligned and the previous page is non-existent. - OpenSSL will incorrectly treat two BN_ULONG buffers as not equal when they are equal. - Side channel concerns. The first is indeed a concern and is a DoS bug. The second is fine in this context. bn_cmp_word and bn_cmp_part_words are used to compute abs(a0 - a1) in Karatsuba. If a0 = a1, it does not matter whether we use a0 - a1 or a1 - a0. The third would be worth thinking about, but it is overshadowed by the entire Karatsuba implementation not being constant time. Due to the difficulty of tripping this and the low impact no CVE is felt necessary for this issue. Reviewed-by:
Viktor Dukhovni <viktor@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8326) (cherry picked from commit 576129cd)
-
- Feb 22, 2019
-
-
Richard Levitte authored
Ty Baen-Price explains: > Problem and Resolution: > The following lines of code make use of the Microsoft API ExitProcess: > > ``` > Apps\Speed.c line 335: ExitProcess(ret); > Ms\uplink.c line 22: ExitProcess(1); > ``` > > These function calls are made after fatal errors are detected and > program termination is desired. ExitProcess(), however causes > _orderly_ shutdown of a process and all its threads, i.e. it unloads > all dlls and runs all destructors. See MSDN for details of exactly > what happens > (https://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx ). > The MSDN page states that ExitProcess should never be called unless > it is _known to be safe_ to call it. These calls should simply be > replaced with calls to TerminateProcess(), which is what should be > called for _disorderly_ shutdown. > > An example of usage: > > ``` > TerminateProcess(GetCurrentProcess(), exitcode); > ``` > > Effect of Problem: > Because of a compilation error (wrong c++ runtime), my program > executed the uplink.c ExitProcess() call. This caused the single > OpenSSL thread to start executing the destructors of all my dlls, > and their objects. Unfortunately, about 30 other threads were > happily using those objects at that time, eventually causing a > 0xC0000005 ACCESS_VIOLATION. Obviously an ACCESS_VIOLATION is the > best case scenario, as I'm sure you can imagine at the consequences > of undiscovered memory corruption, even in a terminating process. And on the subject of `TerminateProcess()` being asynchronous: > That is technically true, but I think it's probably synchronous > "enough" for your purposes, since a call to TerminateProcess > suspends execution of all threads in the target process. This means > it's really only asynchronous if you're calling TerminateProcess one > some _other_ process. If you're calling TerminateProcess on your own > process, you'll never return from the TerminateProcess call. Fixes #2489 Was originally RT-4526 Reviewed-by:
-
Matt Caswell authored
Prior to this commit we were keeping a count of how many KeyUpdates we have processed and failing if we had had too many. This simplistic approach is not sufficient for long running connections. Since many KeyUpdates would not be a particular good DoS route anyway, the simplest solution is to simply remove the key update count. Fixes #8068 Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/8299) (cherry picked from commit 3409a5ff)
-
Dr. Matthias St. Pierre authored
Fixes #7950 It was reported that there might be a null pointer dereference in the implementation of the dasync_aes_128_cbc_hmac_sha1() cipher, because EVP_aes_128_cbc_hmac_sha1() can return a null pointer if AES-NI is not available. It took some analysis to find out that this is not an issue in practice, and these comments explain the reason to comfort further NPD hunters. Detected by GitHub user @wurongxin1987 using the Sourcebrella Pinpoint static analyzer. Reviewed-by:
-
Paul Yang authored
Reviewed-by:
-
- Feb 21, 2019
-
-
Matt Caswell authored
The aes128_cbc_hmac_sha1 cipher in the dasync engine is broken. Probably by commit e38c2e85 which removed use of the "enc" variable...but not completely. Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/8291) (cherry picked from commit 695dd3a3)
-
Hubert Kario authored
The option is a flag for Options, not a standalone setting. Reviewed-by:
-
- Feb 20, 2019
-
-
Nicola Tuveri authored
(cherry picked from commit c8147d37 ) Reviewed-by:
-
Nicola Tuveri authored
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. The process is run twice, once with a "normal" BN_CTX_new() object, then with a BN_CTX_secure_new() one. - 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. (cherry picked from commit fe16ae5f ) Reviewed-by:
-
Billy Brumley authored
(cherry picked from commit 8f58ede0 ) Reviewed-by:
-
Billy Brumley authored
This commit adds a dedicated function in `EC_METHOD` to access a modular field inversion implementation suitable for the specifics of the implemented curve, featuring SCA countermeasures. The new pointer is defined as: `int (*field_inv)(const EC_GROUP*, BIGNUM *r, const BIGNUM *a, BN_CTX*)` and computes the multiplicative inverse of `a` in the underlying field, storing the result in `r`. Three implementations are included, each including specific SCA countermeasures: - `ec_GFp_simple_field_inv()`, featuring SCA hardening through blinding. - `ec_GFp_mont_field_inv()`, featuring SCA hardening through Fermat's Little Theorem (FLT) inversion. - `ec_GF2m_simple_field_inv()`, that uses `BN_GF2m_mod_inv()` which already features SCA hardening through blinding. From a security point of view, this also helps addressing a leakage previously affecting conversions from projective to affine coordinates. This commit also adds a new error reason code (i.e., `EC_R_CANNOT_INVERT`) to improve consistency between the three implementations as all of them could fail for the same reason but through different code paths resulting in inconsistent error stack states. Co-authored-by:
-
- Feb 19, 2019
-
-
Ionut Mihalcea authored
Reviewed-by:
Ben Kaduk <kaduk@mit.edu> Reviewed-by:
-
Matthias Kraft authored
The AIX binder needs to be instructed that the output will have no entry point (see AIX' ld manual: -e in the Flags section; autoexp and noentry in the Binder section). Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
In TLSv1.3 it is illegal to interleave handshake records with non handshake records. Fixes #8189 Reviewed-by:
-
- Feb 18, 2019
-
-
Corinna Vinschen authored
Cygwin binaries should not enforce text mode these days, just use text mode if the underlying mount point requests it Signed-off-by:
Corinna Vinschen <vinschen@redhat.com> Reviewed-by:
-
- Feb 17, 2019
-
-
Vedran Miletić authored
CLA: trivial Reviewed-by:
-
Jan Macku authored
CLA: trivial Reviewed-by:
-
David Benjamin authored
Reviewed-by:
-
David Benjamin authored
The add/double shortcut in ecp_nistz256-x86_64.pl left one instruction point that did not unwind, and the "slow" path in AES_cbc_encrypt was not annotated correctly. For the latter, add .cfi_{remember,restore}_state support to perlasm. Next, fill in a bunch of functions that are missing no-op .cfi_startproc and .cfi_endproc blocks. libunwind cannot unwind those stack frames otherwise. Finally, work around a bug in libunwind by not encoding rflags. (rflags isn't a callee-saved register, so there's not much need to annotate it anyway.) These were found as part of ABI testing work in BoringSSL. Reviewed-by:
-
