Movely removal of unnecessary brackets but some could be bugs addressed too.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4202)
return true for characters > 127. I.e. they are allowing extended ASCII
characters through which then cause problems. E.g. marking superscript '2' as
a number then causes the common (ch - '0') conversion to number to fail
miserably. Likewise letters with diacritical marks can also cause problems.
If a non-ASCII character set is being used (currently only EBCDIC), it is
adjusted for.
The implementation uses a single table with a bit for each of the defined
classes. These functions accept an int argument and fail for
values out of range or for characters outside of the ASCII set. They will
work for both signed and unsigned character inputs.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4102)
[extended tests]
Original text:
Use BUF_strlcpy() instead of strcpy().
Use BUF_strlcat() instead of strcat().
Use BIO_snprintf() instead of sprintf().
In some cases, keep better track of buffer lengths.
This is part of a large change submitted by Markus Friedl <markus@openbsd.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/3701)
The second BN_is_zero test can never be true.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3434)
Never output -0; make "negative zero" an impossibility.
Do better checking on BN_rand top/bottom requirements and #bits.
Update doc.
Ignoring trailing garbage in BN_asc2bn.
Port this commit from boringSSL: https://boringssl.googlesource.com/boringssl/+/899b9b19a4cd3fe526aaf5047ab9234cdca19f7d%5E!/
Ensure |BN_div| never gives negative zero in the no_branch code.
Have |bn_correct_top| fix |bn->neg| if the input is zero so that we
don't have negative zeros lying around.
Thanks to Brian Smith for noticing.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The bound on log(2)/3 on the second line is incorrect and has an extra
zero compared to the divisions in the third line. log(2)/3 = 0.10034...
which is bounded by 0.101 and not 0.1001. The divisions actually
correspond to 0.101 which is fine. The third line also dropped a factor
of three.
The actual code appears to be fine. Just the comments are wrong.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Fix an off by one error in the overflow check added by 07bed46f33
("Check for errors in BN_bn2dec()").
Reviewed-by: Stephen Henson <steve@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
If an oversize BIGNUM is presented to BN_bn2dec() it can cause
BN_div_word() to fail and not reduce the value of 't' resulting
in OOB writes to the bn_data buffer and eventually crashing.
Fix by checking return value of BN_div_word() and checking writes
don't overflow buffer.
Thanks to Shi Lei for reporting this bug.
CVE-2016-2182
Reviewed-by: Tim Hudson <tjh@openssl.org>
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>
This was done by the following
find . -name '*.[ch]' | /tmp/pl
where /tmp/pl is the following three-line script:
print unless $. == 1 && m@/\* .*\.[ch] \*/@;
close ARGV if eof; # Close file to reset $.
And then some hand-editing of other files.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
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>
There are header files in crypto/ that are used by a number of crypto/
submodules. Move those to crypto/include/internal and adapt the
affected source code and Makefiles.
The header files that got moved are:
crypto/cryptolib.h
crypto/md32_common.h
Reviewed-by: Rich Salz <rsalz@openssl.org>
This gets BN_.*free:
BN_BLINDING_free BN_CTX_free BN_FLG_FREE BN_GENCB_free
BN_MONT_CTX_free BN_RECP_CTX_free BN_clear_free BN_free BUF_MEM_free
Also fix a call to DSA_SIG_free to ccgost engine and remove some #ifdef'd
dead code in engines/e_ubsec.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The following compile options (#ifdef's) are removed:
OPENSSL_NO_BIO OPENSSL_NO_BUFFER OPENSSL_NO_CHAIN_VERIFY
OPENSSL_NO_EVP OPENSSL_NO_FIPS_ERR OPENSSL_NO_HASH_COMP
OPENSSL_NO_LHASH OPENSSL_NO_OBJECT OPENSSL_NO_SPEED OPENSSL_NO_STACK
OPENSSL_NO_X509 OPENSSL_NO_X509_VERIFY
This diff is big because of updating the indents on preprocessor lines.
Reviewed-by: Richard Levitte <levitte@openssl.org>
OPENSSL_NO_RIPEMD160, OPENSSL_NO_RIPEMD merged into OPENSSL_NO_RMD160
OPENSSL_NO_FP_API merged into OPENSSL_NO_STDIO
Two typo's on #endif comments fixed:
OPENSSL_NO_ECB fixed to OPENSSL_NO_OCB
OPENSSL_NO_HW_SureWare fixed to OPENSSL_NO_HW_SUREWARE
Reviewed-by: Richard Levitte <levitte@openssl.org>
knock-on work than expected - they've been extracted into a patch
series that can be completed elsewhere, or in a different branch,
before merging back to HEAD.
- Remove unused and unuseful debug cruft.
- Remove unnecessary 'top' fudging from BN_copy().
- Fix a potential memory leak and simplify the expansion logic in
BN_bin2bn().
Submitted by: Nils Larsch
Reviewed by: Geoff Thorpe
Use BUF_strlcat() instead of strcat().
Use BIO_snprintf() instead of sprintf().
In some cases, keep better track of buffer lengths.
This is part of a large change submitted by Markus Friedl <markus@openbsd.org>
against inconsistent BIGNUMs coming out of any of its API functions. So
this change no longer "fixes" the bn_print.c functions, but it makes for
cleaner code. This patch was a part of ticket 697.
PR: 697
Submitted by: Otto Moerbeek
Reviewed by: Geoff Thorpe
sure they are available in opensslconf.h, by giving them names starting
with "OPENSSL_" to avoid conflicts with other packages and by making
sure e_os2.h will cover all platform-specific cases together with
opensslconf.h.
I've checked fairly well that nothing breaks with this (apart from
external software that will adapt if they have used something like
NO_KRB5), but I can't guarantee it completely, so a review of this
change would be a good thing.
like Malloc, Realloc and especially Free conflict with already existing names
on some operating systems or other packages. That is reason enough to change
the names of the OpenSSL memory allocation macros to something that has a
better chance of being unique, like prepending them with OPENSSL_.
This change includes all the name changes needed throughout all C files.
used with negative char values, so I've added casts to unsigned char.
Maybe what really should be done is change all those arrays and
pointers to type unsigned char [] or unsigned char *, respectively;
but using plain char with those predicates is just wrong, so something
had to be done.
Submitted by:
Reviewed by:
PR:
