delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2018/07/16/14:44:22

X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Message-Id: <201807161843.w6GIhuN0032210@delorie.com>
Date: Mon, 16 Jul 2018 19:20:33 +0200
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.2o uploaded.
Reply-To: djgpp AT delorie DOT com

This is a port of OpenSSL 1.0.2o 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 made assumptions 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/zlb1211b.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 and on Win98SE.
     There is no guarantee that this may be possible with any other DOS-
     like OS.  Due to the use of long file names it will not be possible
     to configure and compile without LFN support.

   - the port has been compiled using gcc346b, bnu230b and djdev206 (CVS build).

   - configuring, compiling and running the test suite takes around 02:15 h
     on WinXP installed on a virtual machine.


   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.2n and 1.0.2o [27 Mar 2018]

   *) Constructed ASN.1 types with a recursive definition could exceed the stack

      Constructed ASN.1 types with a recursive definition (such as can be found
      in PKCS7) could eventually exceed the stack given malicious input with
      excessive recursion. This could result in a Denial Of Service attack. There
      are no such structures used within SSL/TLS that come from untrusted sources
      so this is considered safe.

      This issue was reported to OpenSSL on 4th January 2018 by the OSS-fuzz
      project.
      (CVE-2018-0739)
      [Matt Caswell]

  Changes between 1.0.2m and 1.0.2n [7 Dec 2017]

   *) Read/write after SSL object in error state

      OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state"
      mechanism. The intent was that if a fatal error occurred during a handshake
      then OpenSSL would move into the error state and would immediately fail if
      you attempted to continue the handshake. This works as designed for the
      explicit handshake functions (SSL_do_handshake(), SSL_accept() and
      SSL_connect()), however due to a bug it does not work correctly if
      SSL_read() or SSL_write() is called directly. In that scenario, if the
      handshake fails then a fatal error will be returned in the initial function
      call. If SSL_read()/SSL_write() is subsequently called by the application
      for the same SSL object then it will succeed and the data is passed without
      being decrypted/encrypted directly from the SSL/TLS record layer.

      In order to exploit this issue an application bug would have to be present
      that resulted in a call to SSL_read()/SSL_write() being issued after having
      already received a fatal error.

      This issue was reported to OpenSSL by David Benjamin (Google).
      (CVE-2017-3737)
      [Matt Caswell]

   *) rsaz_1024_mul_avx2 overflow bug on x86_64

      There is an overflow bug in the AVX2 Montgomery multiplication procedure
      used in exponentiation with 1024-bit moduli. No EC algorithms are affected.
      Analysis suggests that attacks against RSA and DSA as a result of this
      defect would be very difficult to perform and are not believed likely.
      Attacks against DH1024 are considered just feasible, because most of the
      work necessary to deduce information about a private key may be performed
      offline. The amount of resources required for such an attack would be
      significant. However, for an attack on TLS to be meaningful, the server
      would have to share the DH1024 private key among multiple clients, which is
      no longer an option since CVE-2016-0701.

      This only affects processors that support the AVX2 but not ADX extensions
      like Intel Haswell (4th generation).

      This issue was reported to OpenSSL by David Benjamin (Google). The issue
      was originally found via the OSS-Fuzz project.
      (CVE-2017-3738)
      [Andy Polyakov]

  Changes between 1.0.2l and 1.0.2m [2 Nov 2017]

   *) bn_sqrx8x_internal carry bug on x86_64

      There is a carry propagating bug in the x86_64 Montgomery squaring
      procedure. No EC algorithms are affected. Analysis suggests that attacks
      against RSA and DSA as a result of this defect would be very difficult to
      perform and are not believed likely. Attacks against DH are considered just
      feasible (although very difficult) because most of the work necessary to
      deduce information about a private key may be performed offline. The amount
      of resources required for such an attack would be very significant and
      likely only accessible to a limited number of attackers. An attacker would
      additionally need online access to an unpatched system using the target
      private key in a scenario with persistent DH parameters and a private
      key that is shared between multiple clients.

      This only affects processors that support the BMI1, BMI2 and ADX extensions
      like Intel Broadwell (5th generation) and later or AMD Ryzen.

      This issue was reported to OpenSSL by the OSS-Fuzz project.
      (CVE-2017-3736)
      [Andy Polyakov]

   *) Malformed X.509 IPAddressFamily could cause OOB read

      If an X.509 certificate has a malformed IPAddressFamily extension,
      OpenSSL could do a one-byte buffer overread. The most likely result
      would be an erroneous display of the certificate in text format.

      This issue was reported to OpenSSL by the OSS-Fuzz project.
      (CVE-2017-3735)
      [Rich Salz]

  Changes between 1.0.2k and 1.0.2l [25 May 2017]

   *) Have 'config' recognise 64-bit mingw and choose 'mingw64' as the target
      platform rather than 'mingw'.
      [Richard Levitte]


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


   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 2018-07-09):

     OpenSSL 1.0.2o binary, headers, libraries and man format documentation:
     ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl102ob.zip

     OpenSSL 1.0.2o source:
     ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl102os.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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019