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: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8220)
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: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8186)
Some signature algorithms require special treatment for digesting, such
as SM2. This patch adds the ability of handling raw input data in
apps/pkeyutl other than accepting only pre-hashed input data.
Beside, SM2 requries an ID string when signing or verifying a piece of data,
this patch also adds the ability for apps/pkeyutil to specify that ID
string.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8186)
These are a couple of utility functions, to make import and export of
BIGNUMs to byte strings in platform native for (little-endian or
big-endian) easier.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8346)
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: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8343)
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 <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8334)
(cherry picked from commit f408e2a352)
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: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8326)
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 <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8301)
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)
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: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8305)
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: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8213)
Call close(cfd) before setting cfd = -1.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8213)
This fixes commit c703a80, which had a mistake in cipher_ctrl function.
Move the /dev/crypto session cleanup code to its own function.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8213)
The devcrypto MODULES line was missing the "engine" attribute.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8213)
The aes128_cbc_hmac_sha1 cipher in the dasync engine is broken. Probably
by commit e38c2e8535 which removed use of the "enc" variable...but not
completely.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/8291)
The option is a flag for Options, not a standalone setting.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8292)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8281)
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.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8253)
Because test order can be randomized, running foo_init() as a separate
test is unsafe practice. Instead, we make it possible to call it
multiple times, and call it at the start of each separate test.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8288)
E.g. on MIPS64 it gives >20% improvement...
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8261)
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8175)
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 <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8282)
A randomised order causes failure due to unintentional dependencies between
two of the test cases.
[extended tests]
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/8279)
While we're at it, we also check for names that contain white-space,
as they are invalid.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8269)
Cygwin binaries should not enforce text mode these days, just
use text mode if the underlying mount point requests it
CLA: trivial
Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8248)
The NAME section format is comma separated names to the left of the
left of the dash, free form on the right. If we don't follow that
form, programs like apropos(1) and whatis(1) can't do their job
properly.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8267)
- Add a bit more text about that is expected of the user or
OSSL_METHOD_STOREs.
- Clarify what a method and what a numeric identity are.
- Change all mentions of 'implementation' and 'result' to 'method'.
To clarify further: OpenSSL has used the term 'method' for structures
that mainly contains function pointers. Those are the methods that
are expected to be stored away in OSSL_METHOD_STOREs. In the end,
however, it's the caller's responsibility to define exactly what they
want to store, as long as its 'methods' are associated with a numeric
identity and properties.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8265)
Properties are a sequence of comma separated name=value pairs. A name
without a corresponding value is assumed to be a Boolean and have the
true value 'yes'. Values are either strings or numbers. Strings can be
quoted either _"_ or _'_ or unquoted (with restrictions). There are no
escape characters inside strings. Number are either decimal digits or
'0x' followed by hexidecimal digits. Numbers are represented internally
as signed sixty four bit values.
Queries on properties are a sequence comma separated conditional tests.
These take the form of name=value (equality test), name!=value (inequality
test) or name (Boolean test for truth). Queries can be parsed, compared
against a definition or merged pairwise.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8224)
