Message-Id: <201612312037.uBVKbi4Z030101@delorie.com>
Date: Sat, 31 Dec 2016 21:22:03 +0100
From: "Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via djgpp-announce AT delorie DOT com]" <djgpp-announce AT delorie DOT com>
To: djgpp-announce AT delorie DOT com
Subject: ANNOUNCE: DJGPP port of OpenSSL 1.0.1u uploaded.
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Reply-To: djgpp AT delorie DOT com

This is a port of OpenSSL 1.0.1u 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.  This port has been created because 1.0.2 is the Long Term Support
   (LTS) version (support will be provided until 31st December 2019) and the 1.0.1
   version is currently only receiving security bug fixes and all support will be
   discontinued for this version on 31st December 2016.


   - 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.

   - 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, bnu227b and djdev206.

   - 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 a verbatim extract of the CHANGES file:
-------------------------------------------------------------------------------
  Changes between 1.0.1t and 1.0.1u [22 Sep 2016]

   *) OCSP Status Request extension unbounded memory growth

      A malicious client can send an excessively large OCSP Status Request
      extension. If that client continually requests renegotiation, sending a
      large OCSP Status Request extension each time, then there will be unbounded
      memory growth on the server. This will eventually lead to a Denial Of
      Service attack through memory exhaustion. Servers with a default
      configuration are vulnerable even if they do not support OCSP. Builds using
      the "no-ocsp" build time option are not affected.

      This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
      (CVE-2016-6304)
      [Matt Caswell]

   *) In order to mitigate the SWEET32 attack, the DES ciphers were moved from
      HIGH to MEDIUM.

      This issue was reported to OpenSSL Karthikeyan Bhargavan and Gaetan
      Leurent (INRIA)
      (CVE-2016-2183)
      [Rich Salz]

   *) OOB write in MDC2_Update()

      An overflow can occur in MDC2_Update() either if called directly or
      through the EVP_DigestUpdate() function using MDC2. 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.

      The amount of data needed is comparable to SIZE_MAX which is impractical
      on most platforms.

      This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
      (CVE-2016-6303)
      [Stephen Henson]

   *) Malformed SHA512 ticket DoS

      If a server uses SHA512 for TLS session ticket HMAC it is vulnerable to a
      DoS attack where a malformed ticket will result in an OOB read which will
      ultimately crash.

      The use of SHA512 in TLS session tickets is comparatively rare as it requires
      a custom server callback and ticket lookup mechanism.

      This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
      (CVE-2016-6302)
      [Stephen Henson]

   *) OOB write in BN_bn2dec()

      The function BN_bn2dec() does not check the return value of BN_div_word().
      This can cause an OOB write if an application uses this function with an
      overly large BIGNUM. This could be a problem if an overly large certificate
      or CRL is printed out from an untrusted source. TLS is not affected because
      record limits will reject an oversized certificate before it is parsed.

      This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
      (CVE-2016-2182)
      [Stephen Henson]

   *) OOB read in TS_OBJ_print_bio()

      The function TS_OBJ_print_bio() misuses OBJ_obj2txt(): the return value is
      the total length the OID text representation would use and not the amount
      of data written. This will result in OOB reads when large OIDs are
      presented.

      This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
      (CVE-2016-2180)
      [Stephen Henson]

   *) Pointer arithmetic undefined behaviour

      Avoid some undefined pointer arithmetic

      A common idiom in the codebase is to check limits in the following manner:
      "p + len > limit"

      Where "p" points to some malloc'd data of SIZE bytes and
      limit == p + SIZE

      "len" here could be from some externally supplied data (e.g. from a TLS
      message).

      The rules of C pointer arithmetic are such that "p + len" is only well
      defined where len <= SIZE. Therefore the above idiom is actually
      undefined behaviour.

      For example this could cause problems if some malloc implementation
      provides an address for "p" such that "p + len" actually overflows for
      values of len that are too big and therefore p + len < limit.

      This issue was reported to OpenSSL by Guido Vranken
      (CVE-2016-2177)
      [Matt Caswell]

   *) Constant time flag not preserved in DSA signing

      Operations in the DSA signing algorithm should run in constant time in
      order to avoid side channel attacks. A flaw in the OpenSSL DSA
      implementation means that a non-constant time codepath is followed for
      certain operations. This has been demonstrated through a cache-timing
      attack to be sufficient for an attacker to recover the private DSA key.

      This issue was reported by César Pereida (Aalto University), Billy Brumley
      (Tampere University of Technology), and Yuval Yarom (The University of
      Adelaide and NICTA).
      (CVE-2016-2178)
      [César Pereida]

   *) DTLS buffered message DoS

      In a DTLS connection where handshake messages are delivered out-of-order
      those messages that OpenSSL is not yet ready to process will be buffered
      for later use. Under certain circumstances, a flaw in the logic means that
      those messages do not get removed from the buffer even though the handshake
      has been completed. An attacker could force up to approx. 15 messages to
      remain in the buffer when they are no longer required. These messages will
      be cleared when the DTLS connection is closed. The default maximum size for
      a message is 100k. Therefore the attacker could force an additional 1500k
      to be consumed per connection. By opening many simulataneous connections an
      attacker could cause a DoS attack through memory exhaustion.

      This issue was reported to OpenSSL by Quan Luo.
      (CVE-2016-2179)
      [Matt Caswell]

   *) DTLS replay protection DoS

      A flaw in the DTLS replay attack protection mechanism means that records
      that arrive for future epochs update the replay protection "window" before
      the MAC for the record has been validated. This could be exploited by an
      attacker by sending a record for the next epoch (which does not have to
      decrypt or have a valid MAC), with a very large sequence number. This means
      that all subsequent legitimate packets are dropped causing a denial of
      service for a specific DTLS connection.

      This issue was reported to OpenSSL by the OCAP audit team.
      (CVE-2016-2181)
      [Matt Caswell]

   *) Certificate message OOB reads

      In OpenSSL 1.0.2 and earlier some missing message length checks can result
      in OOB reads of up to 2 bytes beyond an allocated buffer. There is a
      theoretical DoS risk but this has not been observed in practice on common
      platforms.

      The messages affected are client certificate, client certificate request
      and server certificate. As a result the attack can only be performed
      against a client or a server which enables client authentication.

      This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
      (CVE-2016-6306)
      [Stephen Henson]



-------------------------------------------------------------------------------


   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-12-23):

     OpenSSL 1.0.1u binary, headers, libraries and man format documentation:
     ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl101ub.zip

     OpenSSL 1.0.1u source:
     ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl101us.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>