- Mar 01, 2019
-
-
Bernd Edlinger authored
Use select to wait for /dev/random in readable state, but do not actually read anything from /dev/random, use /dev/urandom first. Use linux define __NR_getrandom instead of the glibc define SYS_getrandom, in case the kernel headers are more current than the glibc headers. Fixes #8215 Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/8251)
-
Matt Caswell authored
Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8372)
-
- Feb 28, 2019
-
-
Paul Yang authored
This patch checks if the EXAMPLES section in a pod file is placed before the RETURN VALUES section. Reviewed-by:
-
Paul Yang authored
Reviewed-by:
-
Richard Levitte authored
So say the docs Fixes #8055 Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8368)
-
Richard Levitte authored
Found a few more cases. Reviewed-by:
Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8366)
-
- Feb 27, 2019
-
-
Richard Levitte authored
CFLAGS, CXXFLAGS, CPPFLAGS, LDFLAGS, and LDLIBS Reviewed-by:
-
Richard Levitte authored
For C, -ansi is equivalent to -std=c90 For C++, -ansi is equivalent to -std=c++98 We also place -ansi in CPPFLAGS instead of the usual command line config, to avoid getting it when linking (clang complains) Reviewed-by:
-
Richard Levitte authored
Some of the devteam flags are not for C++ Reviewed-by:
-
Richard Levitte authored
This ensures that we don't mistakenly use C++ keywords anywhere public. Related to #8313 Reviewed-by:
-
Richard Levitte authored
The names in the NAME section may describe headers, which contain a slash for OpenSSL headers. We deal with that by converting slashes to dashes for the file names. Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Simo Sorce authored
SSH's KDF is defined in RFC 4253 in Section 7.2 Signed-off-by:
Simo Sorce <simo@redhat.com> 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:
-
Richard Levitte authored
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:
-
Paul Yang authored
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:
-
- Feb 26, 2019
-
-
Richard Levitte authored
Github PR #8246 provides a better solution to the problem. This reverts commit f11ffa50 . [extended tests] Reviewed-by:
Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/8247)
-
Richard Levitte authored
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:
-
Billy Brumley authored
Reviewed-by:
-
Nicola Tuveri authored
Reviewed-by:
Paul Yang <yang.yang@baishancloud.com> Reviewed-by:
-
Matt Caswell authored
Follow on from CVE-2019-1559 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:
-
- 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)
-
David von Oheimb authored
Reviewed-by:
-
- Feb 24, 2019
-
-
Pauli authored
Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/8318)
-
Pauli authored
Reviewed-by:
-
Pauli authored
Reviewed-by:
-
- 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:
-
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:
-
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
Call close(cfd) before setting cfd = -1. Signed-off-by:
-
Eneas U de Queiroz authored
This fixes commit c703a808 , 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 authored
The devcrypto MODULES line was missing the "engine" attribute. Signed-off-by:
-
Paul Yang authored
Reviewed-by:
-
- Feb 21, 2019
-
-
Kurt Roeckx authored
Reviewed-by:
-
