OpenSSL Security Advisory [30 July 2019]
Windows builds with insecure path defaults (CVE-2019-1552)
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
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.
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
There are official system library calls to obtain the actual locations
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. https://www.wisemo.com 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