OpenSSL Security Advisory

Previous Topic Next Topic
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

OpenSSL Security Advisory

Hash: SHA512

OpenSSL Security Advisory [30 July 2019]

Windows builds with insecure path defaults (CVE-2019-1552)

Severity: Low

OpenSSL has internal defaults for a directory tree where it can find a
configuration file as well as certificates used for verification in
TLS.  This directory is most commonly referred to as OPENSSLDIR, and
is configurable with the --prefix / --openssldir configuration options.

For OpenSSL versions 1.1.0 and 1.1.1, the mingw configuration targets
assume that resulting programs and libraries are installed in a
Unix-like environment and the default prefix for program installation
as well as for OPENSSLDIR should be '/usr/local'.

However, mingw programs are Windows programs, and as such, find
themselves looking at sub-directories of 'C:/usr/local', which may be
world writable, which enables untrusted users to modify OpenSSL's
default configuration, insert CA certificates, modify (or even
replace) existing engine modules, etc.

For OpenSSL 1.0.2, '/usr/local/ssl' is used as default for OPENSSLDIR
on all Unix and Windows targets, including Visual C builds.  However,
some build instructions for the diverse Windows targets on 1.0.2
encourage you to specify your own --prefix.

OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue.
Due to the limited scope of affected deployments this has been
assessed as low severity and therefore we are not creating new
releases at this time.

The mitigations are found in these commits:
- - For 1.1.1, commit 54aa9d51b09d67e90db443f682cface795f5af9e
- - For 1.1.0, commit e32bc855a81a2d48d215c506bdeb4f598045f7e9 and
- - For 1.0.2, commit d333ebaf9c77332754a9d5e111e2f53e1de54fdd

The 1.1.1 and 1.1.0 mitigation set more appropriate defaults for
mingw, while the 1.0.2 mitigation documents the issue and provides
enhanced examples.

This issue was reported by Rich Mirth.  The fix was developed by
Richard Levitte from the OpenSSL development team.  It was reported to
OpenSSL on 9th Jun 2019.


OpenSSL 1.0.2 and 1.1.0 are currently only receiving security updates.
Support for 1.0.2 will end on 31st December 2019. Support for 1.1.0
will end on 11th September 2019. Users of these versions should
upgrade to OpenSSL 1.1.1.


URL for this Security Advisory:

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:

Reply | Threaded
Open this post in threaded view

Re: OpenSSL Security Advisory

OpenSSL - User mailing list
Having reviewed the git commit for 1.1.1 I notice the following issue:

The environment variables that usually point to the secure administrator
directories (such as "Program Files") are not themselves secured, and not
intended as a secure means of obtaining these directory locations, which
are (by definition) subject to change via system configuration (initial
or later!).

There are official system library calls to obtain the actual locations
as follows:

1. If looking for the location where a program is itself installed, use
   the GetModuleFilenameW(own-hinstance) call to obtain the path to once
   own DLL or EXE.  This automatically adapts to wherever the DLL or EXE
   is copied or moved.   This is a kernel32.dll API and returns a location
   with security very close to that of the binary itself.The name
   returned is from the in-process instance of the dynamic linker.

2. If looking for the location where the running program's top level file
   (such as openssl.exe or
   use that same call but pass NULL for the hinstance parameter.

3. If looking for the system-wide secured "/etc" directory, use the
   GetSystemDirectoryW() call and append the fixed string "\\Drivers\\etc" .
   This location is permanently restricted to the system administrators and
   already contains a few traditional unix files such as "hosts". This too
   is a kernel32.dll API.  The name returned is from a system internal value
   set during OS boot.

4. If looking for the directory intended to hold system-wide configuration
   and data files, use the SHGetFolderPathW(CSIDL_COMMON_APPDATA) API from
   shfolder.dll or shell32.dll (fallback) to ask for the "all-users data
   directory", append a company/project name (such as "\\OpenSSL") and
   specify an appropriate ACL in the security argument to CreateDirectoryW()
   (if the directory doesn't already exist with a user-modified ACL,
   CreateDirectoryW will atomically detect this and return a specific error
   code in the per thread GetLastError() variable).Note that mkdir()
   only creates one level of directories per invocation and you may want
   different ACLs when creating missing parent directories.  The values
   returned by SHGetFolderPathW() are typically from one or more
   controlled registry keys.

Some of the above APIs may require their return value to be canonicalized
via the GetFullPathNameW() API in corner cases, retaining the result in
a global variable is advisable.

On 30/07/2019 16:27, OpenSSL wrote:
> OpenSSL Security Advisory [30 July 2019]
> ========================================
> Windows builds with insecure path defaults (CVE-2019-1552)
> ==========================================================


Jakob Bohm, CIO, Partner, WiseMo A/S.
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded