CVE-2015-1816 - LDAP server SSL certificate not verified
|Assigned To:||Marek Hulán|
|Found in release:||Pull request:||https://github.com/theforeman/foreman/pull/2265|
|Velocity based estimate||-|
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.
#3 Updated by Marek Hulán almost 2 years ago
- File 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.
#4 Updated by Marek Hulán almost 2 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.
#9 Updated by Dominic Cleal almost 2 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
#12 Updated by Dominic Cleal almost 2 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
#13 Updated by Vasil Mikhalenya almost 2 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
#15 Updated by Dominic Cleal almost 2 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
#17 Updated by Dominic Cleal almost 2 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.