- openldap-bugs - openldap.org

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by h.b.furuseth＠usit.uio.no 12 Sep '15

12 Sep '15

On 12/09/15 16:24, michael(a)stroeder.com wrote: > I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this did not > help. slapd still crashes when hitting the assert. Yes, portable.h #undefs it by default. OpenLDAP has always conflated logging, debug output and asserts behind LDAP_DEBUG. We've been saying for some time that we really ought to do something about that someday... Even ignoring that, demanding -NDEBUG is backwards in so many ways: Using C's features like <assert.h> is not the user's job, it's OpenLDAP's (i.e. configure and portable.hin). The person building OpenLDAP might not even be a C programmer who knows about the C language quirk that it has a feature makes errors crash by default. A simple "./configure --prefix=/whatever" ought to be a reasonable way to build OpenLDAP, like with most other packages. There are installation instructions and they do not mention NDEBUG. In particular since this isn't even about catching a bug in OpenLDAP, but in the input. If someone wants to crash-debug the input to slapd, let him #define something when building slapd. You could replace the assert() with debug_assert() or something. The same goes for any other assert which doesn't mean "assert(the code is correct)".

1 0

(ITS#8243) LMDB Makefile bug
by jiayq＠eecs.berkeley.edu 12 Sep '15

12 Sep '15

Full_Name: Yangqing Jia Version: OS: Ubuntu 12.04 URL: Submission from: (NULL) (2601:646:8f00:2700:ac83:6009:7765:c6b0) In the Makefile of LMDB, the installation part reads as follows: install: $(ILIBS) $(IPROGS) $(IHDRS) for f in $(IPROGS); do cp $$f $(DESTDIR)$(prefix)/bin; done for f in $(ILIBS); do cp $$f $(DESTDIR)$(prefix)/lib; done for f in $(IHD%2); do cp $$f $(DESTDIR)$(prefix)/include; done for f in $(IDOCS); do cp $$f $(DESTDIR)$(prefix)/man/man1; done This usually works OK, but it silently asumes that $(DESTDIR)$(prefix)/bin and other folders exist. While it works in most cases, if the folders do not exist, what follows is that the installation script generates FILES instead of FOLDERS named bin, lib, include and man1 respectively. We should add "mkdir -p" commands in the installation part to fix this.

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by michael＠stroeder.com 12 Sep '15

12 Sep '15

hyc(a)symas.com wrote: > Our patch response was too hasty. There is no OpenLDAP bug here, the real > issue is production binaries being built with asserts enabled instead of > compiling with -DNDEBUG. That's an issue for packagers and distros to resolve. > Closing this ITS, not an OpenLDAP bug. I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this did not help. slapd still crashes when hitting the assert. Ciao, Michael.

1 0

Re: (ITS#7964) overlay rwm escape issue with more the 9 rules / rewrite statements
by michael＠stroeder.com 12 Sep '15

12 Sep '15

This is a cryptographically signed message in MIME format. --------------ms030300010006010903020301 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ryan Tandy wrote: > Fixed in git master by removing the extra escaping on insert. You will = have to > adjust your rules to use a single backslash instead of two. I wonder whether that caused a regression parsing multi-line DESC '..' in= schema descriptions. Up to now I could load this but it does not work with current RE24 branch= : objectClass ( 1.3.6.1.4.1.412.100.2.1.3.2 NAME 'dlm1ManagedSystemElement'= DESC 'ManagedSystemElement is the base class for the System Element hierarchy. Membership Criteria: Any distinguishable component of a System is a candidate for inclusion in this class. Examples: software components, such as files; and devices, such as disk drives and controllers, and physical components such as chips and cards.' SUP dlm1ManagedElement ABSTRACT MAY ( dlmInstallDate $ dlmName $ dlmStatus ) ) This is not schema generated by me. Ciao, Michael. --------------ms030300010006010903020301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDkxMjEyMzg0NFowLwYJKoZIhvcNAQkEMSIEIDrXZa1NywG8SrP5ntFoYlltABMT8tTiZXDf 2VaTDJRiMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQAeCC2CW5txoCJMgggs UcEJA2eZPOXbq3XU1XrDvO6tsBacNPuuIvJ/rbcjBYgwy/aTcQfbgeLhgNKeigtYtGIMMAo2 lKohLrccMl7ZlQ+ysZDu8gzK715y9z+SZqsz6/82zK2o1UBRcZpKKMDJjV3fUFc+AoS9mPo5 Vz/P4an5x5YckvOaHb6a7El6gvEbTRbVTwPJldlSo6PIcGDf2Jk/vEDDmBS59VK/+mgaHp7R JwYHYQmSxCYBWuR9JBAB0maoQMJf9tEUMh9CQiwj8CVko92ov6xIOHRfDXOuCDZZ4tdjOPDC lqNaoruOVzuULGhzW9wo5oabo19dgb4pOuI6AAAAAAAA --------------ms030300010006010903020301--

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by hyc＠symas.com 12 Sep '15

12 Sep '15

denis.andzakovic(a)security-assessment.com wrote: > Full_Name: Denis Andzakovic > Version: 2.4.42 > OS: Debian 8 > URL: > Submission from: (NULL) (2402:6000:110:a01:743b:8319:1f96:bd89) > > > OpenLDAP ber_get_next Denial of Service > Affected Versions: OpenLDAP <= 2.4.42 > +----------+ > | Solution | > +----------+ > Ensure that data received from untrusted sources is not able to trigger > conditions resulting in the server crashing. In this specific instance, the > NDEBUG macro should be defined before the inclusion of assert.h by default, > requiring a specific compile time alteration to enable debug. Our patch response was too hasty. There is no OpenLDAP bug here, the real issue is production binaries being built with asserts enabled instead of compiling with -DNDEBUG. That's an issue for packagers and distros to resolve. Closing this ITS, not an OpenLDAP bug. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ITS#8240
by hyc＠symas.com 11 Sep '15

11 Sep '15

michael(a)stroeder.com wrote: > Hmm...wouldn't this ITS justify some quick security release 2.4.43? For the umpteenth time - the Project only considers unintended information disclosures or remote code execution flaws as security issues. Neither applies here. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ITS#8240
by ryan＠nardis.ca 11 Sep '15

11 Sep '15

For the record, this issue is being tracked as CVE-2015-6908. http://www.openwall.com/lists/oss-security/2015/09/11/5

1 0

Re: (ITS#7420) Way to bypass overlay unique and constranit
by subbarao＠computer.org 11 Sep '15

11 Sep '15

Hi Howard, Just wanted to inquire about this comment: >It seems that because of this behavior, the fix will have to be made to each >overlay accordingly. It would be nice if we had a more centralized approach >though. What are your current thoughts on this? Would you be open to adding an explicit check for the RDN attribute in the constraint and unique overlays? Or do you want to hold off on that until you have a chance to investigate a more centralized approach? Thanks, -Kartik

1 0

Re: (ITS#8242) constraint overlay gets bypassed for add operations without RDN attribute explicitly listed
by subbarao＠computer.org 11 Sep '15

11 Sep '15

I just realized that this issue is a duplicate of ITS#7420 which was reported in 2012. Sorry for the duplication. -Kartik

1 0

ITS#8240
by michael＠stroeder.com 11 Sep '15

11 Sep '15

Hmm...wouldn't this ITS justify some quick security release 2.4.43? I'm willing to test in as many of my deployments as possible. CIao, Michael.

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by hyc＠symas.com 11 Sep '15

11 Sep '15

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Thanks for the report. Fixed now in git master. > > Thanks for this quick fix. > > Could this also affect LDAP clients using libldap? The assert was in liblber. Since libldap uses liblber, yes, it can affect clients. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by leo＠yuriev.ru 11 Sep '15

11 Sep '15

2015-09-11 2:11 GMT+03:00 <michael(a)stroeder.com>: > hyc(a)symas.com wrote: >> Thanks for the report. Fixed now in git master. > > Thanks for this quick fix. > > Could this also affect LDAP clients using libldap? > > Ciao, Michael. > Yes, of course - any application that uses liblber for parse or read a data.

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by michael＠stroeder.com 11 Sep '15

11 Sep '15

hyc(a)symas.com wrote: > Thanks for the report. Fixed now in git master. Thanks for this quick fix. Could this also affect LDAP clients using libldap? Ciao, Michael.

1 0

(ITS#8242) constraint overlay gets bypassed for add operations without RDN attribute explicitly listed
by subbarao＠computer.org 10 Sep '15

10 Sep '15

Full_Name: Kartik Subbarao Version: 2.4.41 OS: Ubuntu 14.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (173.75.228.155) I have the constraint overlay configured to disallow space characters in the uid attribute. Normally this behaves as expected and rejects attributes with spaces, such as when I add this LDIF entry with ldapmodify: dn: uid=test app@example,com,dc=example,dc=com objectClass: applicationProcess objectClass: llnwApplication uid: test app(a)example.com cn: test app description: This is a test The constraint overlay properly rejects the add operation. But if I leave out the 'uid' attribute, it bypasses the constraint overlay and adds the entry: dn: uid=test app@example,com,dc=example,dc=com objectClass: applicationProcess objectClass: llnwApplication cn: test app description: This is a test Looking at the source code, this behavior seems to happen because constraint_add() loops through the op->ora_e->e_attrs list, which the RDN attribute is absent from in this case.

1 0

(ITS#8241) assert fail from back-bdb/add failure
by hyc＠openldap.org 10 Sep '15

10 Sep '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.236.74) Submitted by: hyc When adding an entry, the last step before TXN_COMMIT is setting up the entry in the entry cache. If the commit fails (it can't fail for locking reasons at this point, but could fail for disk full or other I/O errors) the entryinfo needs to be removed but isn't. This will later trip an assert when do_add() calls entry_free().

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by hyc＠symas.com 10 Sep '15

10 Sep '15

denis.andzakovic(a)security-assessment.com wrote: > Full_Name: Denis Andzakovic > Version: 2.4.42 > OS: Debian 8 > URL: > Submission from: (NULL) (2402:6000:110:a01:743b:8319:1f96:bd89) > > > OpenLDAP ber_get_next Denial of Service > Affected Versions: OpenLDAP <= 2.4.42 > > +-------------+ > | Description | > +-------------+ > This document details a vulnerability found within the OpenLDAP server daemon. A > Denial of Service vulnerability was discovered within the slapd daemon, allowing > an unauthenticated attacker to crash the OpenLDAP server. > > By sending a crafted packet, an attacker may cause the OpenLDAP server to reach > an assert(9 9 statement, crashing the daemon. This was tested on OpenLDAP 2.4.42 > (built with GCC 4.9.2) and OpenLDAP 2.4.40 installed from the Debian package > repository. Thanks for the report. Fixed now in git master. > +--------------+ > | Exploitation | > +--------------+ > By sending a crafted packet, an attacker can cause the OpenLDAP daemon to crash > with a SIGABRT. This is due to an assert() call within the ber_get_next method > (io.c line 682) that is hit when decoding tampered BER data. > > The following proof of concept exploit can be used to trigger the condition: > > --[ Exploit POC > echo "/4SEhISEd4MKYj5ZMgAAAC8=" | base64 -d | nc -v 127.0.0.1 389 It's easier to just pipe this into liblber/dtest. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by denis.andzakovic＠security-assessment.com 10 Sep '15

10 Sep '15

Full_Name: Denis Andzakovic Version: 2.4.42 OS: Debian 8 URL: Submission from: (NULL) (2402:6000:110:a01:743b:8319:1f96:bd89) OpenLDAP ber_get_next Denial of Service Affected Versions: OpenLDAP <= 2.4.42 +-------------+ | Description | +-------------+ This document details a vulnerability found within the OpenLDAP server daemon. A Denial of Service vulnerability was discovered within the slapd daemon, allowing an unauthenticated attacker to crash the OpenLDAP server. By sending a crafted packet, an attacker may cause the OpenLDAP server to reach an assert(9 9 statement, crashing the daemon. This was tested on OpenLDAP 2.4.42 (built with GCC 4.9.2) and OpenLDAP 2.4.40 installed from the Debian package repository. +--------------+ | Exploitation | +--------------+ By sending a crafted packet, an attacker can cause the OpenLDAP daemon to crash with a SIGABRT. This is due to an assert() call within the ber_get_next method (io.c line 682) that is hit when decoding tampered BER data. The following proof of concept exploit can be used to trigger the condition: --[ Exploit POC echo "/4SEhISEd4MKYj5ZMgAAAC8=" | base64 -d | nc -v 127.0.0.1 389 The above causes slapd to abort as follows when running with '-d3', however it should be noted that this will crash the server even when running in daemon mode. --[ adadp -d3 55f0b36e slap_listener_activate(7): 55f0b36e >>> slap_listener(ldap:///) 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next ldap_read: want=8, got=8 0000: ff 84 84 84 84 84 77 83 ......w. 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next ldap_read: want=1, got=1 0000: 0a . 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next slapd: io.c:682: ber_get_next: Assertion `0' failed. The following GDB back trace provides further information as to the location of the issue. --[ back trace program received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff2e4a700 (LWP 1371)] 0x00007ffff6a13107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/ux%x/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff6a13107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff6a144e8 in __GI_abort () at abort.c:89 #2 0x00007ffff6a0c226 in __assert_fail_base (fmt=0x7ffff6b42ce8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55f280 "0", file=file@entry=0x59bdb1 "io.c", line=line@entry=682, function=function@entry=0x59bf33 <__PRETTY_FUNCTION__.6337> "r_r_get_next") at assert.c:92 #3 0x00007ffff6a0c2d2 in __GI___assert_fail (assertion=assertion@entry=0x55f280 "0", file=file@entry=0x59bdb1 "io.c", line=line@entry=682, function=function@entry=0x59bf33 <__PRETTY_FUNCTION__.6337> "ber_get_next") at assert.c:101 #4 0x000000000053261a in ber_get_next (sb=0x7fffe40008c0, len=0x7ffff2e49b40, ber=0x7fffe4000a00) at io.c:682 #5 0x0000000000420b56 in connection_input (cri=<optimized out>, conn=<optimized out>) at connection.c:1572 #6 connection_read (cri=<optimiz o out>, s=<optimized out>) at connection.c:1460 #7 connection_read_thread (ctx=0x7ffff2e49b90, argv=0xf) at connection.c:1284 #8 0x000000000050c871 in ldap_int_thread_pool_wrapper (xpool=0x8956c0) at tpool.c:696 #9 0x00007ffff6d8f0a4 in start_thread (arg=0x7ffff2e4a700) at pthread_create.c:309 #10 0x00007ffff6ac404d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 +----------+ | Solution | +----------+ Ensure that data received from untrusted sources is not able to trigger conditions resulting in the server crashing. In this specific instance, the NDEBUG macro should be defined before the inclusion of assert.h by default, requiring a specific compile time alteration to enable debug. +-------------------------------+A%A| About Security-Assessment.com | +-------------------------------+ Security-Assessment.com is Australasia's leading team of Information Security consultants specialising in providing high quality Information Security services to clients throughout the Asia Pacific region. Our clients include some of the largest globally recognised companies in areas such as finance, telecommunications, broadcasting, legal and government. Our aim is to provide the very best independent advice and a high level of technical expertise while creating long and lasting professional relationships with our clients. Security-Assessment.com is committed to security research and development, and its team continues to identify and responsibly publish vulnerabilities in public and private software vendor's products. Members of the Security-Assessment.com R&D team are globally recognised through their release of whitepapers and presentations related to new security research. For further information on this issue or any of our service offerings, contact us: Web www.security-assessment.com Email info () security-assessment com Phone +64 4 470 1650

1 0

Re: (ITS#8209) Broken MDB_CP_COMPACT threading
by h.b.furuseth＠usit.uio.no 08 Sep '15

08 Sep '15

I wrote: > Compacting can verify that the written metapage claims > enough DB pages. But not the opposite - it should not > fail if it claims too many pages since that would mean > we can't compact a DB which has suffered page leaks. Duh, yes the opposite too. If there has been a page leak, the root page number written in the new meta will be wrong. > We could detect that and re-write the metas at the end, > if the user requests it and the file is seekable. Though there's no reliable "is file seekable?" test. lseek() can do nothing but still return success on some devices. Another (user) option: Write a file which requires recovery. We'll need something like that with incremental backups anyway. Write dummy metapages at the beginning, with meta.mm_version indicating the file must be recovered. Write a final metapage at the end, or try to seek and rewrite the beginning if the user says so. Recovery must be a separate program, or in mdb_env_open() when we know the metapage is at the end - i.e. before mapping and maybe expanding the file. -- Hallvard

1 0

Re: (ITS#8114) [WIP] WiredTiger Backend for OpenLDAP
by hamano＠osstech.co.jp 08 Sep '15

08 Sep '15

Thanks for merging. Also I've added LDAP MODIFY. Please merge the patches: https://www.osstech.co.jp/download/hamano/openldap/0007-suppress-warn-messa… https://www.osstech.co.jp/download/hamano/openldap/0008-LDAP-MODIFY-handlin… Thank you. On Thu, 20 Aug 2015 02:16:53 +0900, Howard Chu wrote: > > hamano(a)osstech.co.jp wrote: > > Full_Name: HAMANO Tsukasa > > Version: master > > OS: Linux > > URL: https://www.osstech.co.jp/download/hamano/openldap/0001-OpenLDAP-WiredTiger… > > Submission from: (NULL) (183.77.250.155) > > > > > > The attached patch file is derived from OpenLDAP Software. All of the > > modifications to OpenLDAP Software represented in the following > > patch(es) were developed by HAMANO Tsukasa <hamano(a)osstech.co.jp>. I > > have not assigned rights and/or interest in this work to any party. > > > > Copyright 2015 HAMANO Tsukasa <hamano(a)osstech.co.jp> > > Redistribution and use in source and binary forms, with or without > > modification, are permitted only as authorized by the OpenLDAP Public > > License. > > I've merged patches 0001-0004 and added this to git master. Thanks for > the contribution. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Open Source Solution Technology Corporation HAMANO Tsukasa <hamano(a)osstech.co.jp> fingerprint = 3747 AB70 7B98 7882 46F5 87E1 BF91 A2C1 7DC1 5E3D

1 0

(ITS#8239) back-meta crashes after deleting a rewrite rule
by ryan＠openldap.org 07 Sep '15

07 Sep '15

Full_Name: Ryan Tandy Version: master OS: Debian URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan Deleting rewrite rules from a back-meta target is not implemented correctly. Deleting a single value (vs the entire attribute) isn't checked for, the entire rewrite_info and list of saved rules is always freed. Then meta_back_conn_destroy doesn't notice the rewrite_session has already been cleaned up, and tries to free it again.

1 0

Re: (ITS#7964) overlay rwm escape issue with more the 9 rules / rewrite statements
by Ryan Tandy 07 Sep '15

07 Sep '15

Uwe Werler wrote: > If I have rewrite rules like this: > > 23 olcOverlay={1}rwm,olcDatabase={3}hdb,cn=config > objectClass: olcOverlayConfig > objectClass: olcRwmConfig > olcOverlay: {1}rwm > olcRwmRewrite: {0}rwm-rewriteEngine on > olcRwmRewrite: {1}rwm-rewriteContext searchFilter > olcRwmRewrite: {2}rwm-rewriteRule "(.*\$)uid=sapr3(\$.*)" "$1d%d=dlmsapr3$2" > olcRwmRewrite: {3}rwm-rewriteRule "(.*\$)uid=sdb(\$.*)" "$1uid=sdb$2" > olcRwmRewrite: {4}rwm-rewriteRule > "(.*\$)uid=sapadm(\$.*)" "$1uid=dlmsapadm$2" > olcRwmRewrite: {5}rwm-rewriteRule "(.*\$)uid=sapmnt(\$.*)" "$1uid=sapmnt$2" > olcRwmRewrite: {6}m-m-rewriteRule "(.*\$)uid=[a-z0-9]{3}adm(\$.*)" > "$1uid=dlmsidadm$2" > olcRwmRewrite: {7}rwm-rewriteRule "(.*\$)uid=sqd[a-z0-9]{3}(\$.*)" > "$1uid=dlmsqdsid$2" > olcRwmRewrite: {8}rwm-rewriteRule "(.*\$)uid=ora[a-z0-9]{3}(\$.*)" > "$1uid=dlmorasid$2" > olcRwmRewrite: {9}rwm-rewriteRule "(.*\$)uid=sap[a-z0-9]{3}(\$.*)" > "$1uid=dlmsapr3$2" > olcRwmRewrite: {10}rwm-rewriteRule "(.*\$)uid=sap[a-z0-9]{3}db(\$.*)" > "$1uid=dlmsapr3db$2" > olcRwmRewrite: {11}rwm-rewriteRule "(.*\$)uid=db2[a-z0-9]{3}(\$.*)" > "$1uid=dlmdb2sid$2" > olcRwmRewrite: {12}rwm-rewriteRule "(.*\$)uid=db2[a-z0-9]{3}ap(\$.*)" > "$1uid=dlmdb2sid$2" > > then the ninth rule / statent f failes to escape. In this example ora*** get's > not correctly rewritten d dlmora***: See loglevel trace: > > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=sapr3($.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=sdb($.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=sapadm($.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=sapmnt($.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=[a-z0-9]{3}adm($.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=sqd[a-z0-9]{3}($.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*\$)uid=ora[a-z0-9]{3}(\$.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=sap[a-z0-9]{3}($.2929' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=sap[a-z0-9]{3}db($.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=db2[a-z0-9]{3}($.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=db2[a-z0-9]{3}a28%5$.*' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > > If I insert a dummy statement like this: > > olcRwmRewrite: {0}rwm-rewriteEngine on > olcRwmRewrite: {1}rwm-rewriteContext searchFilter > olcRwmRewrite: {2}rwm-rewriteRule "(.*\$)uid=sapr3(\$.*)" "$1uid=dlmsapr3$2" > olcRwmRewrite: {3}rwm-rewriteRule "(.*\$)uid=sdb(\$.*)" "$1uid=sdb$2" > olcRwmRewrite: {4}rwm-rewriteRule "(.*\$)uid=sapadm(\$.*)" > "$1uid=dlmsapadm$2" > olcRwmRewrite: {5}rwm-rewriteRule "(.*\$)uid=sapmnt(\$.*)" "$1uid=sapmnt$2" > olcRwmRewrite: {6}rwm-rewriteRule "(.*\$)uid=[a-z0-9]{3}adm(\$.*)" > "$1uid=dlmsidadm$2" > olcRwmRewrite: {7}rwm-rewriteRule "(.*\$)uid=sqd[a-z0-9]{3}(\$.*)" E E "$1uid=dlmsqdsid$2" > olcRwmRewrite: {8}rwm-rewriteRule "(.*\$)uid=ora[a-z0-9]{3}(\$.*)" > "$1uid=dlmorasid$2" > olcRwmRewrite: {9}rwm-rewriteContext placeHolder alias searchFilter > olcRwmRewrite: {10}rwm-rewriteRule "(.*\$)uid=sap[a-z0-9]{3}(\C%C).*)" > "$1uid=dlmsapr3$2" > olcRwmRewrite: {11}rwm-rewriteRule "(.*\\()uid=sap[a-z0-9]{3}db(\$.*)" > "$1uid=dlmsapr3db$2" > olcRwmRewrite: {12}rwm-rewriteRule "(.*\$)uid=db2[a-z0-9]{3}(\$.*)" > "$1uid=dlmdb2sid$2" > olcRwmRewrite: {13}rwm-rewriteRule "(.*\$)uid=db2[a-z0-9]{3}ap(\$.*)" > "$1uid=dlmdb2sid$2" > > then the escapes are working properly. > > Sometimes this occurs with the last rule too. It seems to me that this happens with the rule most recently inserted. If slapd was recently restarted, this would be the last rule in the list. The parsing rules are slightly different for slapd.conf vs ldif. Notable is that ldif parsing does not perform escape processing. So this slapd.conf line: rwm-rewriteRule "(.*\$)uid=sapr3(\$.*)" "$1uid=dlmsapr3$2" should actually correspond to this cn=config attribute: olcRwmRewrite: rwm-rewriteRule "(.*$)uid=sapr3($.*)" "$1uid=dlmsapr3$2" This is exactly the output of conversion with, for example, slaptest -f slapd.conf -F slapd.d. When a new rwm rule is added, existing rules are reloaded. The bug is that the existing rules were being passed through the slapd.conf line processor, which dropped backslashes on the way, while the rule actually being inserted was passed to the rewrite routines untouched. Fixed in git master by removing the extra escaping on insert. You will have to adjust your rules to use a single backslash instead of two. (bonus: rwm is needlessly reloading existing rules when appending with valx >= last, while it could be

1 0

(ITS#8238) mdb_cursor_put() returns inconsistent xcursor
by h.b.furuseth＠usit.uio.no 06 Sep '15

06 Sep '15

Full_Name: Hallvard B Furuseth Version: LMDB 0.9.16 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-150906.diff Submission from: (NULL) (81.191.45.5) Submitted by: hallvard Replace printf("oops!\n") with mdb_cassert(mc, 0) in cursor_chk(). Add if (!rc && mc->mc_xcursor) mdb_cursor_chk(&mc->mc_xcursor->mx_cursor); just before mdb_cursor_put() returns rc above "bad_sub:". Diff for this enclosed. $ make -s clean test CPPFLAGS="-DMDB_DEBUG" $ ./mtest4 mdb.c:1500: Assertion '0' failed in mdb_cursor_chk()

1 0

Re: (ITS#8237) Crash with MDB_MAXKEYSIZE=1500
by h.b.furuseth＠usit.uio.no 06 Sep '15

06 Sep '15

I wrote: > Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root(): The paste got munged. Test program at <ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-150906.c>.

1 0

(ITS#8237) Crash with MDB_MAXKEYSIZE=1500
by h.b.furuseth＠usit.uio.no 06 Sep '15

06 Sep '15

Full_Name: Hallvard B Furuseth Version: LMDB 0.9.10-0.9.15 OS: Linux x86_64 URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root(): #define MDB_MAXKEYSIZE 1500 #include "mdb.c" #include "midl.c" int main(void) { MDB_dbi dbi; MDB_env *env; MDB_txn *txn; int i, rc =DMDB_SUCCESS; mdb_env_create(&env); mdb_env_open(env, "./testdb", MDB_WRITEMAP, 0664); mdb_txn_begin(env, NULL, 0, &txn); mdb_dbi_open(txn, NULL, 0, &dbi); for (i = 0; i < 6 && !rc; i++) { static char buf[1600] = "340215"; DB_v_val key = {1500, buf+i}, data = {500, buf}; mdb_put(txn, dbi, &key, &data, 0); } mdb_txn_abort(txn); mdb_env_close(env); return rc; } Broken by 34459e05856619e8 "ITS#7589 another mdb_page_split fix".

1 0

Re: (ITS#8230) [new PATCHes] totp: bug fixes and improvements
by peter＠adpm.de 06 Sep '15

06 Sep '15

Hi, Please have a look at the improved patch series in https://github.com/marschap/openldap/commits/contrib-totp3 and https://github.com/marschap/openldap/commits/contrib-totp4 They try to address the issues in the previous versions Changes: * contrib/passwd/totp: fix the big-endian case, support 32-bit archs Use memcpy for the WORDS_BIGENDIAN case [much simpler] Use uint64_t for same results in 32- and 64-bit cases * contrib/passwd/totp: support compiling using nettle Fix the botched previous patch. The two branches differ only in that patch, giving the following alternatives: - contrib-totp3 continues to use the HMAC_... macros It still requires the #if...#else...#endif to harmonize the setup in do_hmac() - contrib-totp4 gets rid of the HMAC_... macros It uses the different implementations directly in do_hmac() Of course separated by #if...#else..#endif Functionally both patches are equivalent: in my tests they yield the same results for OpenSSL and GnuTLS. Best PEter -- Peter Marschall peter(a)adpm.de

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs