Re: openssl hash value - how to generate ?

[Salz, Rich via openssl-users]

>At the bottom of the man page for x509 it states the following:
The hash algorithm used in the -subject_hash and -issuer_hash options 
before OpenSSL 1.0.0 was based on the deprecated MD5
algorithm and the encoding of the distinguished name. In OpenSSL 1.0.0 and 
later it is based on a canonical version of the DN
using SHA1.

The text isn't great.  In both cases the printed form is not what is used. 
Instead, by "canonical form" is meant the X.509 ASN1/DER encoding.

Your guess -- "I think I'm using a different string" -- is correct.

Re: OpenSSL Security Advisory

[Jakob Bohm via openssl-users]

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 
some-program-loading-an-openssl-using-plugin.exe),

  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 
Administrator

  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)
==



Enjoy

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

Re: CVE-2019-1552 clarification

[Matt Caswell]

On 30/07/2019 16:49, Quanah Gibson-Mount wrote:
> As someone who does build OpenSSL on windows, my gist is that if I use a
> non-default OPENSSLDIR I'm ok?  Can someone confirm?  Thanks!
> 
> I.e., I use --openssldir=/opt/symas/ssl

As long as your non-default location is suitably protected to stop untrusted
users from making changes to config files/default engines etc, then you are 
fine.

Matt

CVE-2019-1552 clarification

[Quanah Gibson-Mount]

As someone who does build OpenSSL on windows, my gist is that if I use a 
non-default OPENSSLDIR I'm ok?  Can someone confirm?  Thanks!


I.e., I use --openssldir=/opt/symas/ssl

Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

openssl hash value - how to generate ?

[Ben Burrows]

Hi,

I am trying to (independantly of openssl) generate the hash for a certificate 
(the short string
that would be used as the symlink name in the openssl/certs directory).
eg, this command
openssl x509 -in CERT.pem -noout -hash
I am trying to do this because I wanted to know how openssl was calculating 
this.

At the bottom of the man page for x509 it states the following:
The hash algorithm used in the -subject_hash and -issuer_hash options before 
OpenSSL 1.0.0 was based on the deprecated MD5
algorithm and the encoding of the distinguished name. In OpenSSL 1.0.0 and 
later it is based on a canonical version of the DN
using SHA1.

Thats a great start but not enough detail to let me generate this myself.
Since I know the hash uses sha1 I should be able to generate the hash with 
"shasum" passing in the correct data. And there is the issue. All the 
conbinations of data I have passed in give me a different hash to what openssl 
generates. Its much longer but I beleive that is because openssl just chops 
everything past 8 chars off.
Since the man page says its a hash of the DN (subject) I tried passing in the 
subject (in the various formats available from openssl)

openssl x509 -noout -in CERT.pem -text | grep Subject:
Subject: C=GB, O=My Company, OU=My Department, CN=MyName

openssl x509 -in CERT.pem -noout -subject
subject= /C=GB/O=My Company/OU=My Department/CN=MyName

openssl x509 -in CERT.pem -noout -subject -nameopt RFC2253
subject= CN=MyName,OU=My Department,O=My Company,C=GB

I then feed that into shasum like so (showing just one of the 6 combinations. I 
tried the subject for the three variations with and without the "subject= " or 
"Subject: " prefix)

printf "CN=MyName,OU=My Department,O=My Company,C=GB" | shasum
6a73b8417b2f51195e1d0bcee3c2adbc1fb73124  -

I tried looking at the code but I am not really a coder and definately not a 
C/C++ one and I was getting rather out of my depth trying to follow it.

What I THINK my problem is is that the string that openssl is using as the 
input for the has is different to what I am using. Is there some way I can see 
what its using or am I going in the wrong direction here?

Regards
Ben

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
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
  b15a19c148384e73338aa7c5b12652138e35ed28
- - 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.

Note
=

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.


Referenses
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20190730.txt

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

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAl1AU3sACgkQ1enkP335
7oxnEw//ebb9FK16oXpvW6nifNgSHUBYRaq+3ApvSfGG8Er1M0Zn80iD/WY8wzM7
ZabUUNlOdnOs0iQivMYzy+8QzP9NRaqX2WZk/Q1koNT5WAt9+VDCw6hhbp6FN8B9
9aeRvdawNME9JPysl3KOR6DnYJQnpJgV0yQ2pJM2yMKNuDFkvy6E9ieMoWAGx5Ya
8JZ4KGFubA1vDPj5xowkRDxZo+SLdAaEMQw0YG8DWSK5BViZV+3d4OMAAL1RjnZy
s4OSghqi7wUbgo8XO38/roN4y4BEgmEXU0IpSRNf1xrwCoFM82hEgOO3xWxPtbZk
EtDcMUTtMYa1g5IMdGIkVvS4wnNr2j2BAi8WECkPf5QCzCoaX/Xc9jutslTw20M/
UoZnyGgVoOQCsO6ECwLUnSEp772mhS1056c4OKb62kfhlIcGkWi5vk5wjWVZFxEx
rXJC7xabp29e051mnrJtLr85UWUv5B/ywREPyvbdjWg6lJBxB0dOYXMQLpJi6B5i
/bDX7czP/1EeOg+FDSGOR174JGIyMYmPqpyzGpdds72GfOQqtGHC2z41FlvHMglB
9VobSZnF97MIan4/9H4ge+gUUq0PeIZ+invvgCHzuW4oYBOngwwVD5QXfSQUjA9a
etYHkJx+3t4hPrPKAT/J0jHA7AbWtYK7dL6qTxSwli2Gl/D4ipk=
=gxli
-END PGP SIGNATURE-