Bug #9858
closed
CVE-2015-1816 - LDAP server SSL certificate not verified
Added by Marek Hulán about 9 years ago.
Updated almost 6 years ago.
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
- Category set to Authentication
- Status changed from New to Assigned
- Private changed from No to Yes
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.
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.
- 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
- 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
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.
- 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
- Pull request https://github.com/theforeman/foreman/pull/2265 added
- Pull request deleted (
- Related to Bug #9885: CVE-2015-1816 - LDAP server SSL certificate not verified added
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
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
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
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
On deb systems I though it was in /etc/ssl/certs
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.
- Related to Bug #10139: Cannot verify LDAPS SSL certificate on Debian installation added
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by