Upstream bug : http://www.openldap.org/its/index.cgi/Software%20Bugs?id=7059;selectid=7059 With more infos on novell bugzilla : https://bugzilla.novell.com/show_bug.cgi?id=724201 http://www.openwall.com/lists/oss-security/2011/10/26/5 http://www.openwall.com/lists/oss-security/2011/10/26/4
Summary: 1-byte buffer overflow in slapd => CVE-2011-4079: 1-byte buffer overflow in slapd
Ping ?
From the ITS: "Also, this bug had no effect on most Linux installs because glibc malloc always allocates at least 16 bytes. The bug was only detected because I was running valgrind to check for leaks; there was no known crash related to this bug." However, I have submitted 2.4.25-1.1.mga1 to updates_testing for Mageia 1. Should be available in approx 2 hours or so. Another fix is included, which will fix (for *future* upgrades) the error messages you will see in upgrading *from* 2.4.25-1.mga1. If you force-upgrade a 2nd time, the error messages should be gone (and you can test before, and compare to after upgrading, with 'service ldap stop;service ldap recover').
CC: (none) => bgmilne
Ok thanks, the package is available, reassigned to the QA.
Assignee: bgmilne => qa-bugsSummary: CVE-2011-4079: 1-byte buffer overflow in slapd => CVE-2011-4079: 1-byte buffer overflow in slapd (in openldap)
Testing complete on i586 for the srpm openldap-2.4.25-1.1.mga1.src.rpm Just confirming the ldap server and client work. I have kolab installed and setup (a lengthy process), and used https://localhost/kolab/admin to create a new ldap user, and then delete it.
CC: (none) => davidwhodgins
can someone test on x86_64 ?
CC: (none) => dmorganec
Is there a simple way to test this? I'm willing to test but not really sure what I'm doing. I've installed all the openldap packages but get.. # service ldap start Starting slapd (ldap + ldaps): [FAILED] I don't know where to go from here.
Installed openldap-tests and testing using /usr/share/openldap/tests/run all
Aside from lots of warnings of a missing file /usr/bin/ldif-filter which I can't find in our rpms all but one of the tests completed OK. I piped the output to a file ldaptest # grep -e ">>>>>" ldaptests >>>>> Executing all LDAP tests for bdb >>>>> Starting test000-rootdse for bdb... >>>>> Test succeeded >>>>> ./scripts/test000-rootdse completed OK for bdb. >>>>> Starting test001-slapadd for bdb... >>>>> Test succeeded >>>>> ./scripts/test001-slapadd completed OK for bdb. >>>>> Starting test002-populate for bdb... >>>>> Test succeeded >>>>> ./scripts/test002-populate completed OK for bdb. >>>>> Starting test003-search for bdb... >>>>> Test succeeded >>>>> ./scripts/test003-search completed OK for bdb. >>>>> Starting test004-modify for bdb... >>>>> Test succeeded >>>>> ./scripts/test004-modify completed OK for bdb. >>>>> Starting test005-modrdn for bdb... >>>>> Test succeeded >>>>> ./scripts/test005-modrdn completed OK for bdb. >>>>> Starting test006-acls for bdb... >>>>> Test succeeded >>>>> ./scripts/test006-acls completed OK for bdb. >>>>> Starting test008-concurrency for bdb... >>>>> Test succeeded >>>>> ./scripts/test008-concurrency completed OK for bdb. >>>>> Starting test009-referral for bdb... >>>>> Test succeeded >>>>> ./scripts/test009-referral completed OK for bdb. >>>>> Starting test010-passwd for bdb... >>>>> Test succeeded >>>>> ./scripts/test010-passwd completed OK for bdb. >>>>> Starting test011-glue-slapadd for bdb... >>>>> Test succeeded >>>>> ./scripts/test011-glue-slapadd completed OK for bdb. >>>>> Starting test012-glue-populate for bdb... >>>>> Test succeeded >>>>> ./scripts/test012-glue-populate completed OK for bdb. >>>>> Starting test013-language for bdb... >>>>> Test succeeded >>>>> ./scripts/test013-language completed OK for bdb. >>>>> Starting test014-whoami for bdb... >>>>> Test succeeded >>>>> ./scripts/test014-whoami completed OK for bdb. >>>>> Starting test015-xsearch for bdb... >>>>> Test succeeded >>>>> ./scripts/test015-xsearch completed OK for bdb. >>>>> Starting test016-subref for bdb... >>>>> Test succeeded >>>>> ./scripts/test016-subref completed OK for bdb. >>>>> Starting test017-syncreplication-refresh for bdb... >>>>> Test succeeded >>>>> ./scripts/test017-syncreplication-refresh completed OK for bdb. >>>>> Starting test018-syncreplication-persist for bdb... >>>>> Test succeeded >>>>> ./scripts/test018-syncreplication-persist completed OK for bdb. >>>>> Starting test019-syncreplication-cascade for bdb... >>>>> Test succeeded >>>>> ./scripts/test019-syncreplication-cascade completed OK for bdb. >>>>> Starting test020-proxycache for bdb... >>>>> Test succeeded >>>>> ./scripts/test020-proxycache completed OK for bdb. >>>>> Starting test021-certificate for bdb... >>>>> Test succeeded >>>>> ./scripts/test021-certificate completed OK for bdb. >>>>> Starting test022-ppolicy for bdb... >>>>> ./scripts/test022-ppolicy failed for bdb (exit 80) Does test022-ppolicy failing constitute a problem?
# ./run test022-ppolicy Cleaning up test run directory leftover from previous run. Running ./scripts/test022-ppolicy for bdb... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Testing account lockout... Waiting 20 seconds for lockout to reset... Testing password expiration Waiting 20 seconds for password to expire... Resetting password to clear expired status Filling password history... Testing password history... Testing forced reset... Clearing forced reset... Testing Safe modify... Testing length requirement... Testing hashed length requirement... Testing multiple password add/modify checks... Setting up policy state forwarding test... Starting slapd consumer on TCP/IP port 9012... Configuring syncprov on provider... ldapadd failed for moduleLoad (80)!
ping dmorgan :) If this is nothing to worry about then this can be validated.
Just assigning dmorgan for confirmation before validation. Please reassign QA when you've had a chance to look. Thankyou :)
CC: (none) => qa-bugsAssignee: qa-bugs => dmorganec
Ping. Check comment 10 and 11.
Firstly, note that the tests are run during package building. If a test (that is supposed to pass) fails, the package build will fail. There is however value in providing the test suite for uses other than testing (e.g. users asking questions about how to configure specific complex examples are sometimes pointed to the test suite). Additionally, for people who wanted to do additional testing, it is useful (along with the tools in openldap-testprogs ) This specific test is failing due to: echo "Configuring syncprov on provider..." if [ "$SYNCPROV" = syncprovmod ]; then $LDAPADD -D cn=config -H $URI1 -y $CONFIGPWF <<EOF >> $TESTOUT 2>&1 dn: cn=module,cn=config objectclass: olcModuleList cn: module olcModulePath: $TESTWD/../servers/slapd/overlays olcModuleLoad: syncprov.la Obviously the olcModulePath is wrong for an installed system. The following patch makes this test work: ======================================= $ diff -u scripts/{.,}test022-ppolicy --- scripts/.test022-ppolicy 2011-11-25 20:52:29.000000000 +0200 +++ scripts/test022-ppolicy 2012-02-07 15:29:45.000000000 +0200 @@ -426,7 +426,7 @@ dn: cn=module,cn=config objectclass: olcModuleList cn: module -olcModulePath: $TESTWD/../servers/slapd/overlays +olcModulePath: /usr/lib64/openldap olcModuleLoad: syncprov.la EOF @@ -475,7 +475,7 @@ dn: cn=module,cn=config objectclass: olcModuleList cn: module -olcModulePath: $TESTWD/../servers/slapd/back-ldap +olcModulePath: /usr/lib64/openldap olcModuleLoad: back_ldap.la EOF ======================================= and all tests up to test055 pass. test056 fails due to ldif-filter. I am expecting (manually copying ldif-filter from openldap-2.4.28/tests/progs/.libs/ldif-filter to /usr/bin will resolve the rest). I will fix these issues in cauldron, but I don't see the value in pushing new packages for this update. The more important aspect is from comment #7, but that may be related to bug #1978 Please check the paths for TLS-related aspects in slapd.conf, they probably need to be changed to: TLSCertificateFile /etc/pki/tls/certs/ldap.pem TLSCACertificateFile /etc/pki/tls/certs/ldap.pem (Since this error is most likely present in the original package, and the best fix has not been done in cauldron, I would prefer not to address this via security update and delay it further).
These are the current settings, if it helps. # To allow TLS-enabled connections, create /etc/ssl/openldap/ldap.pem # and uncomment the following lines. #TLSRandFile /dev/random #TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /etc/pki/tls/private/ldap.pem TLSCertificateKeyFile /etc/pki/tls/private/ldap.pem #TLSCACertificatePath /etc/ssl/openldap/ #TLSCACertificateFile /etc/ssl/cacert.pem TLSCACertificateFile /etc/pki/tls/private/ldap.pem #TLSVerifyClient never # ([never]|allow|try|demand)
With those setting copied into the conf # service ldap start Starting slapd (ldap + ldaps): [ OK ]
Talking to openldap maintainer blingme on IRC he would rather this update was validated and deal with the other issues separately. Bug 4428 created for the default TLS settings issue Validating the update. Advisory ----------- This security update for openldap provides a fix for CVE-2011-4079 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4079 Off-by-one error in the UTF8StringNormalize function in OpenLDAP 2.4.26 and earlier allows remote attackers to cause a denial of service (slapd crash) via a zero-length string that triggers a heap-based buffer overflow, as demonstrated using an empty postalAddressAttribute value. ----------- SRPM: openldap-2.4.25-1.1.mga1.src.rpm Would sysadmin please push from core/updates_testing to core/updates Thankyou!
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugsAssignee: dmorganec => qa-bugs
update pushed
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED