Mail Archives: djgpp-announce/2016/07/03/14:51:37
This is a port of OpenSSL 1.0.1t to MSDOS/DJGPP.
The OpenSSL Project is an Open Source toolkit implementing the Secure Sockets
Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as
a full-strength general purpose cryptography library. OpenSSL is based on
the excellent SSLeay library developed from Eric A. Young and Tim J. Hudson.
The OpenSSL toolkit is licensed under a dual-license (the OpenSSL license
plus the SSLeay license) situation, which basically means that you are free
to get and use it for commercial and non-commercial purposes as long as you
fulfill the conditions of both licenses.
DJGPP specific changes.
=======================
Fortunately, OpenSSL has been supporting DJGPP out-of-the-box so there is no
need for major adjustments of the source code itself. Neitherless there are
assumptions made about the file system used and its capabilities that require
some changes in the perl configuration scripts and in the way source package
is unzipped.
- the configure script assumes that DJGPP provides termio so it defines
TERMIO instead of TERMIOS as used to be. This had to be reverted.
- undefining the DEVRANDOM_EGD macro because neither MS-DOS nor FreeDOS
provide 'egd' sockets.
- all the adjustments required for the use of the DJGPP port of the current
version of the Watt-32 library.
- the new macro HAS_LFN_SUPPORT checks if underlying file system supports
long file names or not.
- the new function dosify_filename replaces leading dot in passed file name
if file system does not support LFN. It also replaces all leading dots in
the dirname part and the basename part of the file name.
- all these changes have found their way into the new OpenSSl 1.1.0 version
but will not become part neither of version 1.0.1 nor version 1.0.2. That
is because both versions are maintaining versions only and will not offer
new OS/port specific features anymore.
- all new DJGPP specific files are store in the /djgpp directory.
- to install, configure and compile the sources LFN support is required.
- all links (linked files) in the archive have been removed. Depending on if
djtar or tar is used and depending on if they are from DJGPP 2.03 or 2.04
all these tar programs create different kind of files to represent those
links and this breaks either the configuration step or later the building
step.
- the /djgpp directory contains unpack.sh. This small shell script uses
djtar to create a file list of the archive, identifies the links, extract
the sources using djtar and removes all links. Of course, if you download
the DJGPP port all this has already been done.
- as usual the /djgpp directory contains also the diffs file. It shows how
I have changed some of the perl scripts used during the configuration and
building steps to check for the OS used and to copy the files instead of
trying to create links even if this is possible.
- the binaries, headers and libraries will be installed in the corresponding
directories of the DJGPP installation tree. All documentation will be
installend in /dev/env/DJDIR/share/ssl/man. This means that you will have
to adjust your MANPATH in djgpp.env if you want that the man program finds
these new manpages.
- to be able to configure and compile this port, the DJGPP port of perl must
be installed. openssl uses a mix of perl scripts and Makefiles to configure
and compile the sources. I have used perl588b but the previous one may work
as well but I have never tested this.
- to be able to configure and compile this port, the DJGPP port of WATT-32
must be installed. It can be downloaded as:
ftp://ftp.delorie.com/pub/djgpp/current/v2tk/wat3222br6.zip
After having installed the port make sure that the WATT_ROOT environment
variable points to the directory where the headers and the library reside.
This is:
set WATT_ROOT=/dev/env/DJDIR/net/watt
Due to the dependency of WATT-32 and the required value of the WATT_ROOT
environment variable, the source package is not configured at all. You
have to install WATT-32 first and then you can configure and build openssl
as described in the original INSTALL.DJGPP file.
- the port has been configured and compiled to support for zlib compression.
The zlib port used is
ftp://ftp.delorie.com/pub/djgpp/current/v2tk/zlib128br2.zip
but any other version of the port may work as well.
- the test suite passes except for the last test that requires some certificate
that needs to be requested. For some test, it is also required that the port
of GNU bc is installed.
- the binary package of openssl ist not completely SFN clean. But this
concerns the manpages only. Neither the libraries nor the headers are
affected. I do not have the time to invent SFN clean names for hundreds
of manpages which names may change and become useless with the next openssl
update. Of course, the headers and libraries are 8.3 clean and the use of
the libraries do not require LFN support at all.
- as any cryptographic software, openssl needs a source of unpredictable data
to work correctly. Many open source operating systems provide a "randomness
device" (/dev/urandom or /dev/random) that serves this purpose. As of
version 0.9.7f of openssl the DJGPP port checks upon /dev/urandom$ for a
3rd party "randomness" DOS driver. One such driver, NOISE.SYS, can be
obtained from "http://www.rahul.net/dkaufman/index.html" as:
<http://www.rahul.net/dkaufman/noise063a2.zip>
Please read the instructions carefully. This driver works on DOS and may
be on some versions of Windows but it does not work for all versions of
Windows. For XP it does not work and I have found no replacement. This
means that for WinXP and probably for Win2K there is there is no "randomness"
support for openssl available.
- most but not all programs of the /examples directory can be successfully
compiled but they may not work. I have no intention to fix them, neither
less they may serve as example how to use the library and how to compile
and link your application with this library together with the WATT-32
library and the zlib library.
- the port has been configured and compiled on WinXP SP3. There is no
guarantee that this may be possible with any other DOS-like OS. Due
to the massive use of long file names it will not be possible to configure
and compile without LFN support.
- the port has been compiled using gcc346b, bnu226br3 and djdev205.
- configuring, compiling and running the test suite takes around 02:15 h.
For further information about OpenSSL please read the man pages,
various README files and NEWS file. Also visit the home page of openssl.
Please note that I am not an user of openssl. I have only ported it because
I needed it to create another port. This means that I am not able to answer
openssl specific questions.
This is an verbatim extract of the CHANGES file:
-------------------------------------------------------------------------------
Changes between 1.0.1s and 1.0.1t [3 May 2016]
*) Prevent padding oracle in AES-NI CBC MAC check
A MITM attacker can use a padding oracle attack to decrypt traffic
when the connection uses an AES CBC cipher and the server support
AES-NI.
This issue was introduced as part of the fix for Lucky 13 padding
attack (CVE-2013-0169). The padding check was rewritten to be in
constant time by making sure that always the same bytes are read and
compared against either the MAC or padding bytes. But it no longer
checked that there was enough data to have both the MAC and padding
bytes.
This issue was reported by Juraj Somorovsky using TLS-Attacker.
(CVE-2016-2107)
[Kurt Roeckx]
*) Fix EVP_EncodeUpdate overflow
An overflow can occur in the EVP_EncodeUpdate() function which is used for
Base64 encoding of binary data. If an attacker is able to supply very large
amounts of input data then a length check can overflow resulting in a heap
corruption.
Internally to OpenSSL the EVP_EncodeUpdate() function is primarly used by
the PEM_write_bio* family of functions. These are mainly used within the
OpenSSL command line applications, so any application which processes data
from an untrusted source and outputs it as a PEM file should be considered
vulnerable to this issue. User applications that call these APIs directly
with large amounts of untrusted data may also be vulnerable.
This issue was reported by Guido Vranken.
(CVE-2016-2105)
[Matt Caswell]
*) Fix EVP_EncryptUpdate overflow
An overflow can occur in the EVP_EncryptUpdate() function. If an attacker
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 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, it is believed 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(). All instances
of these calls have also been analysed too and it is believed there are no
instances in internal usage where an overflow could occur.
This issue was reported by Guido Vranken.
(CVE-2016-2106)
[Matt Caswell]
*) Prevent ASN.1 BIO excessive memory allocation
When ASN.1 data is read from a BIO using functions such as d2i_CMS_bio()
a short invalid encoding can casuse allocation of large amounts of memory
potentially consuming excessive resources or exhausting memory.
Any application parsing untrusted data through d2i BIO functions is
affected. The memory based functions such as d2i_X509() are *not* affected.
Since the memory based functions are used by the TLS library, TLS
applications are not affected.
This issue was reported by Brian Carpenter.
(CVE-2016-2109)
[Stephen Henson]
*) EBCDIC overread
ASN1 Strings that are over 1024 bytes can cause an overread in applications
using the X509_NAME_oneline() function on EBCDIC systems. This could result
in arbitrary stack data being returned in the buffer.
This issue was reported by Guido Vranken.
(CVE-2016-2176)
[Matt Caswell]
*) Modify behavior of ALPN to invoke callback after SNI/servername
callback, such that updates to the SSL_CTX affect ALPN.
[Todd Short]
*) Remove LOW from the DEFAULT cipher list. This removes singles DES from the
default.
[Kurt Roeckx]
*) Only remove the SSLv2 methods with the no-ssl2-method option. When the
methods are enabled and ssl2 is disabled the methods return NULL.
[Kurt Roeckx]
Changes between 1.0.1r and 1.0.1s [1 Mar 2016]
* Disable weak ciphers in SSLv3 and up in default builds of OpenSSL.
Builds that are not configured with "enable-weak-ssl-ciphers" will not
provide any "EXPORT" or "LOW" strength ciphers.
[Viktor Dukhovni]
* Disable SSLv2 default build, default negotiation and weak ciphers. SSLv2
is by default disabled at build-time. Builds that are not configured with
"enable-ssl2" will not support SSLv2. Even if "enable-ssl2" is used,
users who want to negotiate SSLv2 via the version-flexible SSLv23_method()
will need to explicitly call either of:
SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2);
or
SSL_clear_options(ssl, SSL_OP_NO_SSLv2);
as appropriate. Even if either of those is used, or the application
explicitly uses the version-specific SSLv2_method() or its client and
server variants, SSLv2 ciphers vulnerable to exhaustive search key
recovery have been removed. Specifically, the SSLv2 40-bit EXPORT
ciphers, and SSLv2 56-bit DES are no longer available.
(CVE-2016-0800)
[Viktor Dukhovni]
*) Fix a double-free in DSA code
A double free bug was discovered when OpenSSL parses malformed DSA private
keys and could lead to a DoS attack or memory corruption for applications
that receive DSA private keys from untrusted sources. This scenario is
considered rare.
This issue was reported to OpenSSL by Adam Langley(Google/BoringSSL) using
libFuzzer.
(CVE-2016-0705)
[Stephen Henson]
*) Disable SRP fake user seed to address a server memory leak.
Add a new method SRP_VBASE_get1_by_user that handles the seed properly.
SRP_VBASE_get_by_user had inconsistent memory management behaviour.
In order to fix an unavoidable memory leak, SRP_VBASE_get_by_user
was changed to ignore the "fake user" SRP seed, even if the seed
is configured.
Users should use SRP_VBASE_get1_by_user instead. Note that in
SRP_VBASE_get1_by_user, caller must free the returned value. Note
also that even though configuring the SRP seed attempts to hide
invalid usernames by continuing the handshake with fake
credentials, this behaviour is not constant time and no strong
guarantees are made that the handshake is indistinguishable from
that of a valid user.
(CVE-2016-0798)
[Emilia Käsper]
*) Fix BN_hex2bn/BN_dec2bn NULL pointer deref/heap corruption
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 can leave the internal BIGNUM data
field 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 the internal BIGNUM data field, 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 these functions use 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 rare.
This issue was reported to OpenSSL by Guido Vranken.
(CVE-2016-0797)
[Matt Caswell]
*) 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.
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.
This issue was reported to OpenSSL Guido Vranken.
(CVE-2016-0799)
[Matt Caswell]
*) Side channel attack on modular exponentiation
A side-channel attack was found which makes use of cache-bank conflicts on
the Intel Sandy-Bridge microarchitecture which could lead to the recovery
of RSA keys. The ability to exploit this issue is limited as it relies on
an attacker who has control of code in a thread running on the same
hyper-threaded core as the victim thread which is performing decryptions.
This issue was reported to OpenSSL by Yuval Yarom, The University of
Adelaide and NICTA, Daniel Genkin, Technion and Tel Aviv University, and
Nadia Heninger, University of Pennsylvania with more information at
http://cachebleed.info.
(CVE-2016-0702)
[Andy Polyakov]
*) Change the req app to generate a 2048-bit RSA/DSA key by default,
if no keysize is specified with default_bits. This fixes an
omission in an earlier change that changed all RSA/DSA key generation
apps to use 2048 bits by default.
[Emilia Käsper]
Changes between 1.0.1q and 1.0.1r [28 Jan 2016]
*) Protection for DH small subgroup attacks
As a precautionary measure the SSL_OP_SINGLE_DH_USE option has been
switched on by default and cannot be disabled. This could have some
performance impact.
[Matt Caswell]
*) SSLv2 doesn't block disabled ciphers
A malicious client can negotiate SSLv2 ciphers that have been disabled on
the server and complete SSLv2 handshakes even if all SSLv2 ciphers have
been disabled, provided that the SSLv2 protocol was not also disabled via
SSL_OP_NO_SSLv2.
This issue was reported to OpenSSL on 26th December 2015 by Nimrod Aviram
and Sebastian Schinzel.
(CVE-2015-3197)
[Viktor Dukhovni]
*) Reject DH handshakes with parameters shorter than 1024 bits.
[Kurt Roeckx]
Changes between 1.0.1p and 1.0.1q [3 Dec 2015]
*) Certificate verify crash with missing PSS parameter
The signature verification routines will crash with a NULL pointer
dereference if presented with an ASN.1 signature using the RSA PSS
algorithm and absent mask generation function parameter. Since these
routines are used to verify certificate signature algorithms this can be
used to crash any certificate verification operation and exploited in a
DoS attack. Any application which performs certificate verification is
vulnerable including OpenSSL clients and servers which enable client
authentication.
This issue was reported to OpenSSL by Loïc Jonas Etienne (Qnective AG).
(CVE-2015-3194)
[Stephen Henson]
*) X509_ATTRIBUTE memory leak
When presented with a malformed X509_ATTRIBUTE structure OpenSSL will leak
memory. This structure is used by the PKCS#7 and CMS routines so any
application which reads PKCS#7 or CMS data from untrusted sources is
affected. SSL/TLS is not affected.
This issue was reported to OpenSSL by Adam Langley (Google/BoringSSL) using
libFuzzer.
(CVE-2015-3195)
[Stephen Henson]
*) Rewrite EVP_DecodeUpdate (base64 decoding) to fix several bugs.
This changes the decoding behaviour for some invalid messages,
though the change is mostly in the more lenient direction, and
legacy behaviour is preserved as much as possible.
[Emilia Käsper]
*) In DSA_generate_parameters_ex, if the provided seed is too short,
use a random seed, as already documented.
[Rich Salz and Ismo Puustinen <ismo DOT puustinen AT intel DOT com>]
-------------------------------------------------------------------------------
The port has been compiled using djdev205 and consists of two packages that
can be downloaded from ftp.delorie.com and mirrors as (time stamp 2016-06-17):
OpenSSL 1.0.1t binary, headers, libraries and man format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl101tb.zip
OpenSSL 1.0.1t source:
ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl101ts.zip
Send openssl specific bug reports to <openssl-bugs AT openssl DOT org>.
Send suggestions and bug reports concerning the DJGPP port to
comp.os.msdos.djgpp or <djgpp AT delorie DOT com>.
If you are not sure if the failure is really a openssl failure
or a djgpp specific failure, report it here and *not* to
<openssl-bugs AT openssl DOT org>.
Enjoy.
Guerrero, Juan Manuel <juan DOT guerrero AT gmx DOT de>
- Raw text -