Bug #9858
closed
CVE-2015-1816 - LDAP server SSL certificate not verified
Description
When making an SSL connection to an LDAP authentication source in Foreman, the remote server certificate is accepted without any verification against known certificate authorities.
This can allow the LDAP connection between Foreman and the LDAP server to be attacked, and a different LDAP server could be contacted to authenticate users to Foreman.
Expected behaviour is that the certificate authority for the LDAP server should be stored and trusted somewhere, e.g. the system trust store (/etc/pki/tls/certs/ca-bundle.crt, or via update-ca-certificates).
Affects Foreman 1.3.0 or higher - since Puppet was removed as a dependency, the default SSL behaviour went back to no verification.
Files
Updated by Marek Hulán over 9 years ago
- Category set to Authentication
- Status changed from New to Assigned
Updated by Marek Hulán over 9 years ago
- File fix_9858.diff fix_9858.diff added
- Status changed from Assigned to Ready For Testing
This patch requires ldap_fluff 0.3.4 and ruby-net-ldap 0.10, note that ruby-net-ldap dropped Ruby 1.8.7 support in 0.9 so backporting for Foreman 1.7 on debian might be quite hard.
Updated by Marek Hulán over 9 years ago
The issue is that when user enables LDAPS, we don't check the certificate of LDAP server. ruby-net-ldap sets verify_mode to none by default. They added a way to pass parameters to SSL context so we can now enforce verify_mode to peer (on ruby-net-ldap 0.10 and latest ldap_fluff 0.3.4). After this patch if users use LDAPS and they didn't install CA authority certificate in their /etc/pki/* correctly they will start to see SSL exceptions.
As a following enhancement we can add a way to specify ca_file so they don't have to install it system-wide but that's out of scope of this fix.
Updated by Marek Hulán over 9 years ago
- Subject changed from Satellite 6 authentication with Active Directory on LDAP and LDAPS fails to CVE-2015-1816 - Satellite 6 authentication with Active Directory on LDAP and LDAPS fails
Updated by Dominic Cleal over 9 years ago
- Subject changed from CVE-2015-1816 - Satellite 6 authentication with Active Directory on LDAP and LDAPS fails to CVE-2015-1816 - LDAP server SSL certificate not verified
- Description updated (diff)
- Translation missing: en.field_release set to 36
Updated by Marek Hulán over 9 years ago
- File fix_9858_monkey.diff fix_9858_monkey.diff added
Updated by Dominic Cleal over 9 years ago
Both fixes verified as fixing the issue, thanks.
Regarding the fix for develop: a) require ldap_fluff 0.3.4 in the Gemfile, b) add tests for the new #to_config behaviour.
Updated by Dominic Cleal over 9 years ago
- Description updated (diff)
- Private changed from Yes to No
Unembargoed, fixing in public for Foreman 1.7.4 and 1.8.0-RC2. Marek, could you please open pull requests?
The "fix_9858_monkey.diff" patch may be applied to /usr/share/foreman on a production 1.7 (or probably older) installation to mitigate the issue, restart Apache/httpd to have it take effect.
To trust the LDAP server's certificate:
- On a Red Hat based OS, add the LDAP server's CA certificate to /etc/pki/tls/certs/ca-bundle.crt
- On Debian or Ubuntu, store the CA under /usr/local/share/ca-certificates/ with a .crt extension and run
update-ca-certificates
Updated by The Foreman Bot over 9 years ago
- Pull request https://github.com/theforeman/foreman/pull/2265 added
- Pull request deleted (
)
Updated by Dominic Cleal over 9 years ago
- Related to Bug #9885: CVE-2015-1816 - LDAP server SSL certificate not verified added
Updated by Dominic Cleal over 9 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Fixed on 1.7-stable in https://github.com/theforeman/foreman/commit/74f2d0ec0f207dc56cd00ae93ba61c47039d03a5
Updated by Vasil Mikhalenya over 9 years ago
Guys, seems it does not work. AD auth with ssl enabled stopped working after upgrade to 1.7.4
Put CA, SubCA to /usr/lib/ssl/certs/ and run update-ca-certificates
openssl -CApath /usr/lib/ssl/certs/ connects smoothly but in foreman get
SSL_connect SYSCALL returned=5 errno=0 state=SSLv3 read server certificate B: certificate verify failed
Updated by Marek Hulán over 9 years ago
Why you have to specify the -CApath? I think you should verify the certificate installation without any params (curl https://$fqdn). Also I usually found cert storage at /etc/pki not in /usr/lib
Updated by Dominic Cleal over 9 years ago
The path depends on the OS, but as you mention update-ca-certificates, I assume it's Debian or Ubuntu. It should in that case be /usr/local/share/ca-certificates/, not /usr/lib. Try restarting apache2 after adding to the certificate store.
Please also attach or pastebin the full output from: openssl s_client -CApath /etc/ssl/certs -connect ldap.example.com:636
Updated by Marek Hulán over 9 years ago
On deb systems I though it was in /etc/ssl/certs
Updated by Dominic Cleal over 9 years ago
Marek Hulán wrote:
On deb systems I though it was in /etc/ssl/certs
That's the dir that update-ca-certificates manages, I think you're meant to put your cert in /usr/local/share/ca-certificates/ for it to combine, else it could be wiped if it ever runs with --fresh.
Updated by Dominic Cleal over 9 years ago
- Related to Bug #10139: Cannot verify LDAPS SSL certificate on Debian installation added