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.
Reviewed-by: Andy Polyakov <appro@openssl.org>
This takes us away from the idea that we know exactly how our static
libraries are going to get used. Instead, we make them available to
build shareable things with, be it other shared libraries or DSOs.
On the other hand, we also have greater control of when the shared
library cflags. They will never be used with object files meant got
binaries, such as apps/openssl or test/test*.
With unified, we take this a bit further and prepare for having to
deal with extra cflags specifically to be used with DSOs (dynamic
engines), libraries and binaries (applications).
Reviewed-by: Rich Salz <rsalz@openssl.org>
This silences the memory sanitizer. All fields were already correctly
initialized but the struct padding wasn't, causing an uninitialized read
warning.
Reviewed-by: Tim Hudson <tjh@openssl.org>
All those flags existed because we had all the dependencies versioned
in the repository, and wanted to have it be consistent, no matter what
the local configuration was. Now that the dependencies are gone from
the versioned Makefile.ins, it makes much more sense to use the exact
same flags as when compiling the object files.
Reviewed-by: Rich Salz <rsalz@openssl.org>
When OPENSSL_NO_ASYNC is set, make ASYNC_{un,}block_pause() do nothing.
This prevents md_rand.c from failing to build. Probably better to do it
this way than to wrap every instance in an explicit #ifdef.
A bunch of new socket code got added to a new file crypto/bio/b_addr.c.
Make it all go away if OPENSSL_NO_SOCK is defined.
Allow configuration with no-ripemd, no-ts, no-ui
We use these for the UEFI build.
Also remove the 'Really???' comment from no-err and no-locking. We use
those too.
We need to drop the crypto/engine directory from the build too, and also
set OPENSSL_NO_ENGINE
Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Most of the times, it seems that socklen_t is unsigned.
Unfortunately, this isn't always the case, and it doesn't compare with
a size_t without warning.
A cast resolves the issue.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Removes SSIZE_MAX definition from bss_bio.c and changes that file to use
OSSL_SSIZE_MAX.
No need to account for OPENSSL_SYS_VXWORKS, since that never actually
gets defined anywhere. It must be a historical artifact.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Ben Laurie <ben@openssl.org>
The actual bug with current getnameinfo() on VMS is not that it puts
gibberish in the service buffer, but that it doesn't touch it at all.
The gibberish we dealt with before was simply stuff that happened to
be on the stack.
It's better to initialise the service buffer properly (with the empty
string) and check if it's still an empty string after the
getnameinfo() call, and fill it with the direct numerical translation
of the raw port if that's the case.
Reviewed-by: Rich Salz <rsalz@openssl.org>
As noted already, some platforms don't fill in ai_protocol as
expected. To circumvent that, we have BIO_ADDRINFO_protocol() to
compute a sensible answer in that case.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
It seems like it gives back gibberish. If we asked for a numeric
service, it's easy to check for a digit in the first position, and
if there isn't any, rewrite it using older methods.
Reviewed-by: Rich Salz <rsalz@openssl.org>
- One typo fixed in crypto/bio/b_addr.c
- Add a comment in doc/crypto/BIO_parse_hostserv.pod to explain the
blank lines with one lonely space each.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Don't cast malloc-family return values.
Also found some places where (a) blank line was missing; and (b)
the *wrong* return value was checked.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(if priority is set to host)
Signed-off-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Adds a new function BIO_ADDR_clear to reset a BIO_ADDR back to an
unitialised state, and to set the family to AF_UNSPEC.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Both getaddrinfo() and getnameinfo() have to be preceeded with a call
to BIO_sock_init().
Also, make sure to give gai_strerror() the actual error code.
Reviewed-by: Stephen Henson <steve@openssl.org>
The control commands that previously took a struct sockaddr * have
been changed to take a BIO_ADDR * instead.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Because of the way bio_lcl.h is organised, we must not include
internal/cryptlib.h before it. As a matter of fact, bio_lcl.h
includes internal/cryptlib.h on its own.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Because different platforms have different levels of support for IPv6,
different kinds of sockaddr variants, and some have getaddrinfo et al
while others don't, we could end up with a mess if ifdefs, duplicate
code and other maintainance nightmares.
Instead, we're introducing wrappers around the common form for socket
communication:
BIO_ADDR, closely related to struct sockaddr and some of its variants.
BIO_ADDRINFO, closely related to struct addrinfo.
With that comes support routines, both convenient creators and
accessors, plus a few utility functions:
BIO_parse_hostserv, takes a string of the form host:service and
splits it into host and service. It checks for * in both parts, and
converts any [ipv6-address] syntax to ust the IPv6 address.
BIO_lookup, looks up information on a host.
All routines handle IPv4 (AF_INET) and IPv6 (AF_INET6) addresses, and
there is support for local sockets (AF_UNIX) as well.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Now that we have the foundation for the "unified" build scheme in
place, we add build.info files. They have been generated from the
Makefiles in the same directories. Things that are platform specific
will appear in later commits.
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>
Remove lint, tags, dclean, tests.
This is prep for a new makedepend scheme.
This is temporary pending unified makefile, and might help it.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Create Makefile's from Makefile.in
Rename Makefile.org to Makefile.in
Rename Makefiles to Makefile.in
Address review feedback from Viktor and Richard
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
