| Age | Commit message (Collapse) | Author |
|---|
|
The previous commit fixed a bug with BN_mod_word() which would have been
caught if we had a test for it. This commit adds one.
Reviewed-by: Andy Polyakov <appro@openssl.org>
|
|
On systems where we do not have BN_ULLONG (e.g. typically 64 bit systems)
then BN_mod_word() can return incorrect results if the supplied modulus is
too big.
RT#4501
Reviewed-by: Andy Polyakov <appro@openssl.org>
(cherry picked from commit 37258dadaa9e36db4b96a3aa54aa6c67136160cc)
|
|
As it turns out branch hints grew as kind of a misconception. In
addition their interpretation by GNU assembler is affected by
assembler flags and can end up with opposite meaning on different
processors. As we have to loose quite a lot on misinterprerations,
especially on newer processors, we just omit them altogether.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit 20b88bb160865b0c2998056fe841b1cbacd6d4c7)
|
|
Some OSes, *cough*-dows, insist on stack being "wired" to
physical memory in strictly sequential manner, i.e. if stack
allocation spans two pages, then reference to farmost one can
be punishable by SEGV. But page walking can do good even on
other OSes, because it guarantees that villain thread hits
the guard page before it can make damage to innocent one...
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit adc4f1fc25b2cac90076f1e1695b05b7aeeae501)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
and reorganize/harmonize post-conditions.
Additional hardening following on from CVE-2016-0702
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from master)
|
|
At the same time remove miniscule bias in final subtraction.
Performance penalty varies from platform to platform, and even with
key length. For rsa2048 sign it was observed to be 4% for Sandy
Bridge and 7% on Broadwell.
CVE-2016-0702
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from master)
|
|
Performance penalty is 2%.
CVE-2016-0702
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from master)
|
|
Performance penalty is 2% on Linux and 5% on Windows.
CVE-2016-0702
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from master)
|
|
Performance penalty varies from platform to platform, and even
key length. For rsa2048 sign it was observed to reach almost 10%.
CVE-2016-0702
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from master)
Resolved conflicts:
crypto/bn/bn_exp.c
|
|
In the BN_hex2bn function the number of hex digits is calculated using
an int value |i|. Later |bn_expand| is called with a value of |i * 4|.
For large values of |i| this can result in |bn_expand| not allocating any
memory because |i * 4| is negative. This leaves ret->d as NULL leading
to a subsequent NULL ptr deref. For very large values of |i|, the
calculation |i * 4| could be a positive value smaller than |i|. In this
case memory is allocated to ret->d, but it is insufficiently sized
leading to heap corruption. A similar issue exists in BN_dec2bn.
This could have security consequences if BN_hex2bn/BN_dec2bn is ever
called by user applications with very large untrusted hex/dec data. This is
anticipated to be a rare occurrence.
All OpenSSL internal usage of this function uses data that is not expected
to be untrusted, e.g. config file data or application command line
arguments. If user developed applications generate config file data based
on untrusted data then it is possible that this could also lead to security
consequences. This is also anticipated to be a rare.
Issue reported by Guido Vranken.
CVE-2016-0797
Reviewed-by: Andy Polyakov <appro@openssl.org>
|
|
Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
|
|
Some URLs in the source code ended up getting mangled by indent. This fixes
it. Based on a patch supplied by Arnaud Lacombe <al@aerilon.ca>
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Commit 2b0180c37fa6ffc48ee40caa831ca398b828e680 attempted to do this but
only hit one of many BN_mod_exp codepaths. Fix remaining variants and add
a test for each method.
Thanks to Hanno Boeck for reporting this issue.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
(cherry picked from commit d911097d7c93e4cfeab624b34d73fe51da158b69)
|
|
RT#4171
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
(cherry picked from commit b9749432346f69b29d82070041e71b237d718ce7)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit e7c078db57908cbf16074c68034977565ffaf107)
|
|
RT#4142
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 76eba0d94bb418325be6409b272eac5e2bd4a0a9)
Resolved conflicts:
crypto/bn/asm/x86_64-mont.pl
crypto/bn/asm/x86_64-mont5.pl
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
|
|
The problem remained unnoticed so far, because it's never called by default.
You have to craft OPENSSL_ppccap environment variable to trigger the problem.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit e4693b4e2a0c3f6241d4d3e61460c34c7e0013f6)
|
|
is couple percent faster]. Triggered by RT#4128, but solves the problem by real modulo-scheduling.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 9d0e4dc6351df7d0c08400c4b4cf17c017022e50)
|
|
Signed-off-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Rich Salz <rsalz@akamai.com>
MR #1276, RT #4107
(cherry picked from commit 94b3664a528258df5ebcaae213d19bf6568cc47d)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit d900a015b5a89ea2018e6122dd2738925e4d68ab)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 3f6c7691870d1cd2ad0e0c83638cef3f35a0b548)
|
|
BN_with_flags() will read the dest->flags to keep the BN_FLG_MALLOCED but
overwrites everything else.
Signed-off-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Rich Salz <rsalz@openssl.org>
MR #1231
(cherry picked from commit f92768e6f5259069bd21dbed2b98b3423c1dfca4)
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
|
|
Don't dereference |d| when |top| is zero. Also test that various BIGNUM methods behave correctly on zero/even inputs.
Follow-up to b11980d79a52ec08844f08bea0e66c04b691840b
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 4d04226c2ec7e7f69f6234def63631648e35e828)
|
|
The function BN_MONT_CTX_set was assuming that the modulus was non-zero
and therefore that |mod->top| > 0. In an error situation that may not be
the case and could cause a seg fault.
This is a follow on from CVE-2015-1794.
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
From a CloudFlare patch.
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit f4ee22be03bb8318b1e0f00e116be231ba12fdef)
|
|
This leaves behind files with names ending with '.iso-8859-1'. These
should be safe to remove. If something went wrong when re-encoding,
there will be some files with names ending with '.utf8' left behind.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 2d540402aac7a05af9c99b58864d53c0201a0b42)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
A small rearrangement so the inclusion of rsaz_exp.h would be
unconditional, but what that header defines becomes conditional.
This solves the weirdness where rsaz_exp.h gets in and out of the
dependency list for bn_exp.c, depending on the present architecture.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Reviewed-by: Stephen Henson <steve@openssl.org>
|
|
CVE-2015-1788
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 4924b37ee01f71ae19c94a8934b80eeb2f677932)
|
|
A BIGNUM can have the value of -0. The function BN_bn2hex fails to account
for this and can allocate a buffer one byte too short in the event of -0
being used, leading to a one byte buffer overrun. All usage within the
OpenSSL library is considered safe. Any security risk is considered
negligible.
With thanks to Mateusz Kocielski (LogicalTrust), Marek Kroemeke and
Filip Palian for discovering and reporting this issue.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit c56353071d9849220714d8a556806703771b9269)
Conflicts:
crypto/bn/bn_print.c
|
|
RT#3859
Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit 60c268b21ac81cc6b1af5c5470282a613b96f6fd)
|
|
bn_get_bits5 was overstepping array boundary by 1 byte. It was exclusively
read overstep and data could not have been used. The only potential problem
would be if array happens to end on the very edge of last accesible page.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 69567687b0b7ed67831c17a010f4d46dfd059aef)
|
|
RT#3852
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 86e5d1e32b2d702a5fc777e612cd746e790098ef)
|
|
BLKINIT optimization worked on T4, but for some reason appears "too
aggressive" for T3 triggering intermiitent EC failures. It's not clear
why only EC is affected...
Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit 579734ced696125c0768a2f4e56e97939b0e6e49)
|
|
We had updates of certain header files in both Makefile.org and the
Makefile in the directory the header file lived in. This is error
prone and also sometimes generates slightly different results (usually
just a comment that differs) depending on which way the update was
done.
This removes the file update targets from the top level Makefile, adds
an update: target in all Makefiles and has it depend on the depend: or
local_depend: targets, whichever is appropriate, so we don't get a
double run through the whole file tree.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 0f539dc1a2f45580435c39dada44dd276e79cb88)
Conflicts:
Makefile.org
apps/Makefile
test/Makefile
|
|
If BN_rand is called with |bits| set to 1 and |top| set to 1 then a 1 byte
buffer overflow can occur. There are no such instances within the OpenSSL at
the moment.
Thanks to Mateusz Kocielski (LogicalTrust), Marek Kroemeke, Filip Palian for
discovering and reporting this issue.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
|
|
The functions BN_rshift and BN_lshift shift their arguments to the right or
left by a specified number of bits. Unpredicatable results (including
crashes) can occur if a negative number is supplied for the shift value.
Thanks to Mateusz Kocielski (LogicalTrust), Marek Kroemeke and Filip Palian
for discovering and reporting this issue.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
(cherry picked from commit 7cc18d8158b5fc2676393d99b51c30c135502107)
Conflicts:
crypto/bn/bn.h
crypto/bn/bn_err.c
|
|
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Reviewed-by: Matt Caswell <gitlab@openssl.org>
|
|
Ensure all calls to RAND_bytes and RAND_pseudo_bytes have their return
value checked correctly
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
In the event of an error |rr| could be NULL. Therefore don't assume you can
use |rr| in the error handling code.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(cherry picked from commit 8c5a7b33c6269c3bd6bc0df6b4c22e4fba03b485)
|
|
Reviewed-by: Andy Polyakov <appro@openssl.org>
|
|
Reviewed-by: Stephen Henson <steve@openssl.org>
|
|
This should be a one off operation (subsequent invokation of the
script should not move them)
This commit is for the 1.0.2 changes
Reviewed-by: Tim Hudson <tjh@openssl.org>
|
