slapd segfault on filter parse error
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openldap |
Fix Released
|
Undecided
|
Unassigned | ||
openldap (Debian) |
Fix Released
|
Unknown
|
|||
openldap (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Lucas Kanashiro | ||
Bionic |
Fix Released
|
Undecided
|
Lucas Kanashiro | ||
Disco |
Fix Released
|
Undecided
|
Lucas Kanashiro |
Bug Description
[Impact]
Users willing to use the slapd rwm overlay will face a slapd segmentation fault when trying to rewrite some rules. Backporting this fix will allow users using stable releases to take advantage of this feature without crashing slapd. This issue was fixed by upstream not freeing the rwm overlay filter memory without prior checking.
[Test Case]
In this test case, the rwm overlay will be used and a rule will be created to deny any search request for uid=root, then the 'ldapsearch' will be invoked to trigger the failure. It is important to mention that the 'ldapsearch' command should fail regardless the presence of the bug in the package, the target here is the slapd crash. To reproduce this bug one can follow the procedure below in Ubuntu xenial, bionic or disco:
$ sudo apt-get update
Use debconf to pre-seed slapd questions before install it:
$ debconf-
slapd slapd/no_
slapd slapd/domain string example.com
slapd shared/organization string example.com
slapd slapd/password1 password test
slapd slapd/password2 password test
slapd slapd/backend select MDB
slapd slapd/move_
EOF
$ sudo apt-get install slapd ldap-utils -y
Create a file called 'add-rwm.ldif' with the following content:
$ cat add-rwm.ldif
dn: cn=module{
changetype: modify
add: olcModuleLoad
olcModuleLoad: rwm
dn: olcOverlay=
changetype: add
objectClass: olcOverlayConfig
objectClass: olcRwmConfig
olcOverlay: rwm
olcRwmRewrite: {0} rwm-rewriteEngine "on"
olcRwmRewrite: {1} rwm-rewriteContext "searchFilter"
olcRwmRewrite: {2} rwm-rewriteRule "(.*)(uid=
With this file in place, run:
$ sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f add-rwm.ldif
Now, to trigger the crash:
$ ldapsearch -x -h localhost -b dc=example,dc=com -LLL uid=root
Server is unwilling to perform (53)
Additional information: searchFilter/
slapd process will die, and /var/crash will have a crash file for slapd. You can run the following command to confirm the error:
$ cat /var/log/syslog | grep filter_free
Aug 9 19:51:05 popular-gorilla slapd[1479]: filter_free: unknown filter type=28530
-> Expected behavior
In this test case, as mentioned before, the 'ldapsearch' command should fail but the 'slapd' process should not die. As result, we don't expect a slapd crash report in /var/crash directory.
[Regression Potential]
Since the fix is a patch provided by upstream (reviewed by maintainers and us) simple mistakes like typos are not expected. The patch impacts only the rwm module which is not loaded by default. So any regression would affect only the users that make use of this overlay. If an user is not using rwm overlay and is facing any issue, it should be related to other problems related to LDAP directory services.
[Original message]
Hello!
We have faced slapd crash, seems an attacker was trying to brute force one
of our services and uid parsing failures caused slapd crash:
Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH
base="ou=
filter=
Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH attr=objectClass uid
userPassword uidNumber gidNumber gecos homeDirectory loginShell
krbPrincipalName cn memberOf modifyTimestamp modifyTimestamp
shadowLastChange shadowMin shadow
Max shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange
krbPasswordExpi
userAccountControl nsAccountLock host loginDisabled loginExpirationTime
loginAllowedTimeMap sshPublic
Key
Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SEARCH RESULT tag=101 err=0
nentries=0 text=massaged filter parse error
Jul 26 18:59:47 kernel: [ 9441.554161] slapd[2367]: segfault at 18 ip
00007fc8d18ec512 sp 00007fc8889e2810 error 4 in libc-2.23.so
[7fc8d1868000+
Another faulty filter example:
filter=
filter=
$ lsb_release -rd
Description: Ubuntu 16.04.5 LTS
Release: 16.04
$ slapd -VVV
@(#) $OpenLDAP: slapd (Ubuntu) (May 22 2018 13:54:12) $
buildd@
:/build/
Included static backends:
config
ldif
$ apt-cache policy slapd
slapd:
Installed: 2.4.42+
Candidate: 2.4.42+
Version table:
2.
500 http://
Packages
*** 2.4.42+
100 /var/lib/
2.
500 http://
Packages
2.
500 http://
affects ubuntu/openldap
Related branches
- Christian Ehrhardt (community): Approve
- Canonical Server: Pending requested
- git-ubuntu developers: Pending requested
-
Diff: 70 lines (+48/-0)3 files modifieddebian/changelog (+6/-0)
debian/patches/rwm-do-not-free-original-filter.patch (+41/-0)
debian/patches/series (+1/-0)
- Christian Ehrhardt (community): Approve
- Canonical Server: Pending requested
- Canonical Server packageset reviewers: Pending requested
-
Diff: 70 lines (+48/-0)3 files modifieddebian/changelog (+6/-0)
debian/patches/rwm-do-not-free-original-filter.patch (+41/-0)
debian/patches/series (+1/-0)
- Christian Ehrhardt (community): Approve
- Canonical Server: Pending requested
- git-ubuntu developers: Pending requested
-
Diff: 70 lines (+48/-0)3 files modifieddebian/changelog (+6/-0)
debian/patches/rwm-do-not-free-original-filter.patch (+41/-0)
debian/patches/series (+1/-0)
tags: | added: server-next |
tags: | added: patch |
tags: | added: bitesize |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
Changed in openldap (Ubuntu Xenial): | |
assignee: | nobody → Lucas Kanashiro (lucaskanashiro) |
Changed in openldap (Ubuntu Bionic): | |
assignee: | nobody → Lucas Kanashiro (lucaskanashiro) |
Changed in openldap (Ubuntu Disco): | |
assignee: | nobody → Lucas Kanashiro (lucaskanashiro) |
Changed in openldap (Debian): | |
status: | Unknown → Fix Released |
Hello, thank you for the report.
I was able to reproduce the crash locally by intentionally
mis-configuring the rwm overlay.
Could you please provide a copy of your rwm overlay configuration? I
would like to see what the actual parse failure was in your instance.