Bug 1346055 (CVE-2016-4983) - CVE-2016-4983 dovecot insecure SSL/TLS key and certificate file creation
Summary: CVE-2016-4983 dovecot insecure SSL/TLS key and certificate file creation
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2016-4983
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1346056
Blocks: 1346019 1349160
TreeView+ depends on / blocked
 
Reported: 2016-06-13 19:36 UTC by Kurt Seifried
Modified: 2021-02-17 03:43 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-06 07:56:03 UTC
Embargoed:


Attachments (Terms of Use)

Description Kurt Seifried 2016-06-13 19:36:42 UTC
Kurt Seifried of Red Hat reports:

The dovecot rpm creates the SSL/TLS key files using the following rpm postinstall script in RHEL 4:

# create a ssl cert
if [ ! -f /usr/share/ssl/certs/dovecot.pem ]; then
pushd /usr/share/ssl &>/dev/null
umask 077
cat << EOF | openssl req -new -x509 -days 365 -nodes -out certs/dovecot.pem -keyout private/dovecot.pem &>/dev/null
--
SomeState
SomeCity
SomeOrganization
SomeOrganizationalUnit
localhost.localdomain
root
EOF
chown root:root private/dovecot.pem certs/dovecot.pem
chmod 600 private/dovecot.pem certs/dovecot.pem

And later versions use a postinstall of:

# generate the ssl certificates
if [ ! -f /etc/pki/dovecot/certs/dovecot.pem ]; then
    SSLDIR=/etc/pki/dovecot OPENSSLCONFIG=/etc/pki/dovecot/dovecot-openssl.cnf \
         /usr/libexec/dovecot/mkcert.sh &> /dev/null
fi

from: /usr/libexec/dovecot/mkcert.sh

$OPENSSL req -new -x509 -nodes -config $OPENSSLCONFIG -out $CERTFILE -keyout $KEYFILE -days 365 || exit 2
chown root:root $CERTFILE $KEYFILE
chmod 0600 $CERTFILE $KEYFILE

this can lead to the contents of the file being exposed between the time the file is created and the chmod command runs. I would suggest setting umask 077 first. 

Additionally this secret value needs to be unique per instance or install but this value is created at install-time and not during the first run. All container and image instances created would share the same password as this password is set at rpm install time, and each instance should recieve a unique password. 

This bug is being file because Product Security considers "first run problems" to be bugs with the source package and with the container or image only in the aggregate. This view is in collaboration with upstream Fedora. See: https://fedorahosted.org/fpc/ticket/506

The recommended resolution for services is to follow the "First-time Service Setup" pattern (see: https://fedoraproject.org/wiki/Packaging:Initial_Service_Setup ). Other packages may should use a runtime check and generation or similar procedure.

Comment 1 Kurt Seifried 2016-06-13 19:36:50 UTC
Acknowledgments:

Name: Kurt Seifried (Red Hat)

Comment 2 Kurt Seifried 2016-06-13 19:37:43 UTC
Created dovecot tracking bugs for this issue:

Affects: fedora-all [bug 1346056]

Comment 3 Michal Hlavinka 2016-06-23 11:50:11 UTC
I don't understand this bug report. Could you clarify it a little bit more?

> this can lead to the contents of the file being exposed between 
> the time the file is created and the chmod command runs. 
> I would suggest setting umask 077 first. 

1) you suggest umask 077 first which is already there, just above the cat <<EOF line
2) what does it matter if it was exposed for a short moment (which it isn't) it the content is just a dummy template/placeholder. It is stored in post script which is known to everyone anyway. It can be queried from the system by regular user by: $ rpm -q --scripts dovecot AND the "quality" of the certificate data "SomeState" "SomeCity" etc. is something won't be trusted by anyone in real life even if someone tried to deploy dovecot with such a certificate which I doubt.

It is just a placeholder template to allow to run dovecot for testing on localhost, nothing more. It's no secret whatsoever.

Also you file a bug for "fedora-all" with recommendation of "First-time Service Setup" which is what fedora packages already do.

Comment 4 Kurt Seifried 2016-07-14 02:15:10 UTC
Basically everything has to be first run, even "test data", for container and related systems this stuff will cause problems, hence it needs to be removed/fixed.


Note You need to log in before you can comment on or make changes to this bug.