Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
  • CodeLinaro CodeLinaro codelinaro
  • Joshua Sickmeyer Joshua Sickmeyer joshua.sickmeyer
  • lnx build lnx build lnxbuild
  • Manifest Service Manifest Service manifest_service
  • SM AutoSBA to Code Linaro SM AutoSBA to Code Linaro svcautosbacodelinaro
5 authors
  1. May 04, 2022
  3. Apr 29, 2022
    • Matt Caswell's avatar
      Fix BN_hex2bn/BN_dec2bn NULL ptr/heap corruption · 12d6fe16
      Matt Caswell authored 
      
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: default avatarAndy Polyakov <appro@openssl.org>

Change-Id: I8e2028a0bb8db9793edf9def7dac75efa6ab4024
Signed-off-by: default avatarSaahil Tomar <quic_saahtoma@quicinc.com>
      12d6fe16
  5. Apr 18, 2022
  7. Apr 14, 2022
    • Mark Adler's avatar
      Avoid pre-decrement of pointer in big-endian CRC calculation. · 7c7dbe97
      Mark Adler authored 
      
There was a small optimization for PowerPCs to pre-increment a
pointer when accessing a word, instead of post-incrementing. This
required prefacing the loop with a decrement of the pointer,
possibly pointing before the object passed. This is not compliant
with the C standard, for which decrementing a pointer before its
allocated memory is undefined. When tested on a modern PowerPC
with a modern compiler, the optimization no longer has any effect.
Due to all that, and per the recommendation of a security audit of
the zlib code by Trail of Bits and TrustInSoft, in support of the
Mozilla Foundation, this "optimization" was removed, in order to
avoid the possibility of undefined behavior.

Change-Id: I8c7b57d093640405d61a5588706cb51147738be5
Signed-off-by: default avatarSaahil Tomar <quic_saahtoma@quicinc.com>
      7c7dbe97
    • Mark Adler's avatar
      Remove offset pointer optimization in inftrees.c. · 9264ae67
      Mark Adler authored 
      
inftrees.c was subtracting an offset from a pointer to an array,
in order to provide a pointer that allowed indexing starting at
the offset. This is not compliant with the C standard, for which
the behavior of a pointer decremented before its allocated memory
is undefined. Per the recommendation of a security audit of the
zlib code by Trail of Bits and TrustInSoft, in support of the
Mozilla Foundation, this tiny optimization was removed, in order
to avoid the possibility of undefined behavior.

Change-Id: I2fcd56f809dc2e57b660e389e09fdbab82a4afba
Signed-off-by: default avatarSaahil Tomar <quic_saahtoma@quicinc.com>
      9264ae67
    • Mark Adler's avatar
      Use post-increment only in inffast.c. · ece00c57
      Mark Adler authored 
      
An old inffast.c optimization turns out to not be optimal anymore
with modern compilers, and furthermore was not compliant with the
C standard, for which decrementing a pointer before its allocated
memory is undefined. Per the recommendation of a security audit of
the zlib code by Trail of Bits and TrustInSoft, in support of the
Mozilla Foundation, this "optimization" was removed, in order to
avoid the possibility of undefined behavior.

Change-Id: I14c859d451eb746d9f218face47d41a1ff672a1d
Signed-off-by: default avatarSaahil Tomar <quic_saahtoma@quicinc.com>
      ece00c57
  9. Apr 13, 2022
  11. Apr 12, 2022
  13. Apr 08, 2022
  15. Apr 06, 2022
  17. Apr 05, 2022
  19. Apr 04, 2022
  21. Mar 16, 2022
    • Matt Caswell's avatar
      Fix BN_hex2bn/BN_dec2bn NULL ptr/heap corruption · 9d98d20e
      Matt Caswell authored 
      
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: default avatarAndy Polyakov <appro@openssl.org>

Change-Id: I3d43b96946c5a3ebb116ec352b23389f68e2905a
Signed-off-by: default avatarSaahil Tomar <quic_saahtoma@quicinc.com>
      9d98d20e
    • Geoff Thorpe's avatar
      evp: prevent underflow in base64 decoding · 1c4aafd9
      Geoff Thorpe authored 
      
This patch resolves RT ticket #2608.

Thanks to Robert Dugal for originally spotting this, and to David
Ramos for noticing that the ball had been dropped.

Signed-off-by: default avatarGeoff Thorpe <geoff@openssl.org>

Change-Id: I8c30ac4d804b59052befeb92815f1abe2ddf710e
Signed-off-by: default avatarSaahil Tomar <quic_saahtoma@quicinc.com>
      1c4aafd9
    • Matt Caswell's avatar
      Fix encrypt overflow · 6ff27d09
      Matt Caswell authored 
      
An overflow can occur in the EVP_EncryptUpdate function. If a person is
able to supply very large amounts of input data after a previous call to
EVP_EncryptUpdate with a partial block then a length check can overflow
resulting in a heap corruption.

Following an analysis of all OpenSSL internal usage of the
EVP_EncryptUpdate function all usage is one of two forms.

The first form is like this:
EVP_EncryptInit()
EVP_EncryptUpdate()

i.e. where the EVP_EncryptUpdate() call is known to be the first called
function after an EVP_EncryptInit(), and therefore that specific call
must be safe.

The second form is where the length passed to EVP_EncryptUpdate() can be
seen from the code to be some small value and therefore there is no
possibility of an overflow.

Since all instances are one of these two forms, I believe that there can
be no overflows in internal code due to this problem.

It should be noted that EVP_DecryptUpdate() can call EVP_EncryptUpdate()
in certain code paths. Also EVP_CipherUpdate() is a synonym for
EVP_EncryptUpdate(). Therefore I have checked all instances of these
calls too, and came to the same conclusion, i.e. there are no instances
in internal usage where an overflow could occur.

This could still represent a security issue for end user code that calls
this function directly.

CVE-2016-2106

Issue reported by Guido Vranken.

Reviewed-by: default avatarTim Hudson <tjh@openssl.org>

Change-Id: Icda362e5477f7f784f860183a62874443876d81b
Signed-off-by: default avatarSaahil Tomar <quic_saahtoma@quicinc.com>
      6ff27d09
  23. Mar 15, 2022
  25. Feb 10, 2022
  27. Oct 06, 2021
  29. Sep 21, 2021
  31. Sep 16, 2021
  33. Sep 08, 2021
  35. Oct 30, 2020
  37. Oct 29, 2020
  39. Oct 05, 2020
  41. Sep 25, 2020
  43. Sep 06, 2020
  45. Aug 20, 2020
  47. Aug 18, 2020
  49. Aug 14, 2020