Bug 43459 - Make bind9 LDAP queries use TLS
Make bind9 LDAP queries use TLS
Status: NEW
Product: UCS
Classification: Unclassified
Component: DNS
UCS 4.4
All Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-01-31 17:58 CET by Frank Greif
Modified: 2019-05-13 09:24 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Security Issue
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score: 3.7 (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N)
hahn: Patch_Available+


Attachments
Assert encrypted connection (1.71 KB, patch)
2017-04-18 17:02 CEST, Philipp Hahn
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Greif 2017-01-31 17:58:42 CET
When using LDAP backend for DNS, the zone configurations talk unencrypted to LDAP. Some contributing points:

* the x-tls option is not mandatory, so Bind does not try STARTTLS
* Setting ldap/server/port to 7636 does not help because there's currently no variable to set the protocol ('ldap://' hardwired in the listener script)
* changing x-tls to !x-tls (critical extension) throws a Bind error 'URL: unknown critical extension'

I'd propose to make the listener script generate an ldaps:// URI when the port is set to 7636. Or somebody knows how to make the URL in zone files look like to force it into using STARTTLS?

Note the problem is not critical as long as Bind talks to the local LDAP instance. But given the possibility to install Bind on all server roles there would be the chance for machine credentials to be revealed.
Comment 1 Philipp Hahn univentionstaff 2017-04-18 17:01:33 CEST
The UDL module "services/univention-bind/bind.py" always adds "x-tls" to the URI.
This triggers "bind9-ldap/ldapdb.c:168" to call ldap_start_tls_s(), but it does NOT check the return value for errors - so the connection remains unencrypted.

There also is no CA/CRL checking as none of the LDAP_OPT_X_TLS_* options are set, so BIND will connect to ANY server which at least provides a (random) certificate.

To re-produce this, disable TLS in slapd and trigger a BIND reload; this will hapil
 sed -i -e '/^TLS/s/^/#/' /etc/ldap/slapd.conf
 serivce slapd restart
 tcpdump -i lo 'tcp port 7389' -s 65535 -w /tmp/pcap &
 rndc -p 55555 reload `dnsdomainname`
This will show that BIND9 sends the bind credentials unencrypted.
Comment 2 Philipp Hahn univentionstaff 2017-04-18 17:02:13 CEST
Created attachment 8781 [details]
Assert encrypted connection

Similar to ldaptools -ZZ
Comment 3 Philipp Hahn univentionstaff 2019-05-13 09:24:50 CEST
By default univention-bind is only installed on UCS roles running OpenLDAP, so the connection is to localhost - on my test system <ldap://127.0.0.1/> is used which is the default in "/usr/lib/univention-directory-listener/system/bind.py" unless UCRV "bind/ldap/server/ip" is explicitly set to some other value - by default this is unset.
(But using an IP address breaks checking the hostname of the certificate)

So this issue is only for systems where the package univention-bind is manually installed on a Member Server.