Message-Id: <201511221917.tAMJHS20019987@delorie.com> Date: Sun, 22 Nov 2015 20:15:51 +0100 From: "Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via djgpp-announce AT delorie DOT com]" To: djgpp-announce AT delorie DOT com Subject: ANNOUNCE: DJGPP port of OpenSSL 1.0.1p 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.1p 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 supports DJGPP out-of-the-box so there is no need to adjust 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. - 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.05 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 WATT32 must be installed. It can be downloaded as: ftp://ftp.delorie.com/pub/djgpp/current/v2tk/wat3222br5.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: 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 WAT32 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. - Configuring, compiling and running the test suite takes around 01:30 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.1o and 1.0.1p [9 Jul 2015] *) Alternate chains certificate forgery During certificate verfification, OpenSSL will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and "issue" an invalid certificate. This issue was reported to OpenSSL by Adam Langley/David Benjamin (Google/BoringSSL). [Matt Caswell] Changes between 1.0.1n and 1.0.1o [12 Jun 2015] *) Fix HMAC ABI incompatibility. The previous version introduced an ABI incompatibility in the handling of HMAC. The previous ABI has now been restored. Changes between 1.0.1m and 1.0.1n [11 Jun 2015] *) Malformed ECParameters causes infinite loop When processing an ECParameters structure OpenSSL enters an infinite loop if the curve specified is over a specially malformed binary polynomial field. This can be used to perform denial of service against any system which processes public keys, certificate requests or certificates. This includes TLS clients and TLS servers with client authentication enabled. This issue was reported to OpenSSL by Joseph Barr-Pixton. (CVE-2015-1788) [Andy Polyakov] *) Exploitable out-of-bounds read in X509_cmp_time X509_cmp_time does not properly check the length of the ASN1_TIME string and can read a few bytes out of bounds. In addition, X509_cmp_time accepts an arbitrary number of fractional seconds in the time string. An attacker can use this to craft malformed certificates and CRLs of various sizes and potentially cause a segmentation fault, resulting in a DoS on applications that verify certificates or CRLs. TLS clients that verify CRLs are affected. TLS clients and servers with client authentication enabled may be affected if they use custom verification callbacks. This issue was reported to OpenSSL by Robert Swiecki (Google), and independently by Hanno Böck. (CVE-2015-1789) [Emilia Käsper] *) PKCS7 crash with missing EnvelopedContent The PKCS#7 parsing code does not handle missing inner EncryptedContent correctly. An attacker can craft malformed ASN.1-encoded PKCS#7 blobs with missing content and trigger a NULL pointer dereference on parsing. Applications that decrypt PKCS#7 data or otherwise parse PKCS#7 structures from untrusted sources are affected. OpenSSL clients and servers are not affected. This issue was reported to OpenSSL by Michal Zalewski (Google). (CVE-2015-1790) [Emilia Käsper] *) CMS verify infinite loop with unknown hash function When verifying a signedData message the CMS code can enter an infinite loop if presented with an unknown hash function OID. This can be used to perform denial of service against any system which verifies signedData messages using the CMS code. This issue was reported to OpenSSL by Johannes Bauer. (CVE-2015-1792) [Stephen Henson] *) Race condition handling NewSessionTicket If a NewSessionTicket is received by a multi-threaded client when attempting to reuse a previous ticket then a race condition can occur potentially leading to a double free of the ticket data. (CVE-2015-1791) [Matt Caswell] *) Reject DH handshakes with parameters shorter than 768 bits. [Kurt Roeckx and Emilia Kasper] Changes between 1.0.1l and 1.0.1m [19 Mar 2015] *) Segmentation fault in ASN1_TYPE_cmp fix The function ASN1_TYPE_cmp will crash with an invalid read if an attempt is made to compare ASN.1 boolean types. Since ASN1_TYPE_cmp is used to check certificate signature algorithm consistency 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. (CVE-2015-0286) [Stephen Henson] *) ASN.1 structure reuse memory corruption fix Reusing a structure in ASN.1 parsing may allow an attacker to cause memory corruption via an invalid write. Such reuse is and has been strongly discouraged and is believed to be rare. Applications that parse structures containing CHOICE or ANY DEFINED BY components may be affected. Certificate parsing (d2i_X509 and related functions) are however not affected. OpenSSL clients and servers are not affected. (CVE-2015-0287) [Stephen Henson] *) PKCS7 NULL pointer dereferences fix The PKCS#7 parsing code does not handle missing outer ContentInfo correctly. An attacker can craft malformed ASN.1-encoded PKCS#7 blobs with missing content and trigger a NULL pointer dereference on parsing. Applications that verify PKCS#7 signatures, decrypt PKCS#7 data or otherwise parse PKCS#7 structures from untrusted sources are affected. OpenSSL clients and servers are not affected. This issue was reported to OpenSSL by Michal Zalewski (Google). (CVE-2015-0289) [Emilia Käsper] *) DoS via reachable assert in SSLv2 servers fix A malicious client can trigger an OPENSSL_assert (i.e., an abort) in servers that both support SSLv2 and enable export cipher suites by sending a specially crafted SSLv2 CLIENT-MASTER-KEY message. This issue was discovered by Sean Burford (Google) and Emilia Käsper (OpenSSL development team). (CVE-2015-0293) [Emilia Käsper] *) Use After Free following d2i_ECPrivatekey error fix A malformed EC private key file consumed via the d2i_ECPrivateKey function could cause a use after free condition. This, in turn, could cause a double free in several private key parsing functions (such as d2i_PrivateKey or EVP_PKCS82PKEY) and could lead to a DoS attack or memory corruption for applications that receive EC private keys from untrusted sources. This scenario is considered rare. This issue was discovered by the BoringSSL project and fixed in their commit 517073cd4b. (CVE-2015-0209) [Matt Caswell] *) X509_to_X509_REQ NULL pointer deref fix The function X509_to_X509_REQ will crash with a NULL pointer dereference if the certificate key is invalid. This function is rarely used in practice. This issue was discovered by Brian Carpenter. (CVE-2015-0288) [Stephen Henson] *) Removed the export ciphers from the DEFAULT ciphers [Kurt Roeckx] Changes between 1.0.1k and 1.0.1l [15 Jan 2015] *) Build fixes for the Windows and OpenVMS platforms [Matt Caswell and 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 2015-11-20): OpenSSL 1.0.1p binary, headers, libraries and man format documentation: ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl101pb.zip OpenSSL 1.0.1p source: ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl101ps.zip Send openssl specific bug reports to . Send suggestions and bug reports concerning the DJGPP port to comp.os.msdos.djgpp or . If you are not sure if the failure is really a openssl failure or a djgpp specific failure, report it here and *not* to . Enjoy. Guerrero, Juan Manuel P.S.: I have tested wat3222br5 and ssl101pb by recompiling lynx288s and using it to access different homepages and downloading files.