tree c07e2e455b3e189ae7ae988ff52690d9c0e99559
parent 0eee91ef65a218f59a8b1c77443ddb0a2da991f4
author Matt Caswell <matt@openssl.org> 1456405786 -0700
committer Gerrit - the friendly Code Review server <code-review@localhost> 1472503219 -0700

Fix memory issues in BIO_*printf functions

The internal |fmtstr| function used in processing a "%s" format string
in the BIO_*printf functions could overflow while calculating the length
of a string and cause an OOB read when printing very long strings.

Additionally the internal |doapr_outch| function can attempt to write to
an OOB memory location (at an offset from the NULL pointer) in the event of
a memory allocation failure. In 1.0.2 and below this could be caused where
the size of a buffer to be allocated is greater than INT_MAX. E.g. this
could be in processing a very long "%s" format string. Memory leaks can also
occur.

These issues will only occur on certain platforms where sizeof(size_t) >
sizeof(int). E.g. many 64 bit systems. The first issue may mask the second
issue dependent on compiler behaviour.

These problems could enable attacks where large amounts of untrusted data
is passed to the BIO_*printf functions. If applications use these functions
in this way then they could be vulnerable. OpenSSL itself uses these
functions when printing out human-readable dumps of ASN.1 data. Therefore
applications that print this data could be vulnerable if the data is from
untrusted sources. OpenSSL command line applications could also be
vulnerable where they print out ASN.1 data, or if untrusted data is passed
as command line arguments.

Libssl is not considered directly vulnerable. Additionally certificates etc
received via remote connections via libssl are also unlikely to be able to
trigger these issues because of message size limits enforced within libssl.

CVE-2016-0799

Issue reported by Guido Vranken.

(cherry-picked from commit 578b956fe741bf8e84055547b1e83c28dd902c73)

Bug: 29060514
Change-Id: I8bba4cc655dd01e5a384d15f3cf10eff3ca530e5
(cherry picked from commit 93efbca025e7e441b7991c380f79d864ce81dec5)