Full_Name: Sauli Pahlman Version: 2.4.22 OS: Ubuntu Linux 9.10 i386 URL: Submission from: (NULL) (93.190.96.120) Two OpenLDAP preauth, out of box and stock config exploitable vulnerabilities. One null pointer dereference and one free based on uninitialized pointer, potentially leading to total compromise. = Description of bug #1 OpenLDAP crashes with segfault during the processing of a modrdn call with maliciously formed destination rdn string. No authentication is required to trigger this vulnerability. = Description of bug #2 OpenLDAP crashes at a null pointer dereference during the processing of modrdn call with maliciously formed destination rdn string. No authentication is required to trigger this vulnerability. = Analysis #1 In the function modrdn.c:386:slap_modrdn2mods() a call is made to 448:*desc->ad_type->sat_equality->smr_normalize() without checking its return value. In this case the call fails and leaves mod_tmp->sml_nvalues uninitialized which leads to an invalid free() later in modrdn.c:202:slap_mods_free(). The breakdown of smr_normalize() is caused by invalid UTF-8 sequences, which are passed to the software via hex-formatted strings. It could be possible to insert and execute malicious code by careful manipulation of the program state prior to triggering the vulnerability. At least with a vanilla compilation of 2.4.22 it proved possible to freely control the invalid pointer being freed. For example, the following kind of log message is produced: * ** glibc detected *** /usr/sbin/slapd: double free or corruption (out): 0x002ce400 *** = Analysis #2 As with bug #1, the crash occurs during a call to smr_normalize, but in this case the call points to IA5StringNormalize which crashes with a null pointer dereference at schema_init.c:2696. = Proof of concept #1 ldapmodrdn -x cn=something,dc=anything cn=#80 Some tries may be required to reach segfault depending on what lies in the uninitialized memory. = Proof of concept #2 ldapmodrdn -x dc=something,dc=anything dc= = Tested versions OpenLDAP 2.4.22 (vanilla), 2.4.11-1+lenny1, 2.4.21-0ubuntu5 = Credits The vulnerability was found by Ilkka Mattila and Tuomas Salom�ki with Codenomicon LDAPv3 test suite at the Codenomicon Crash Test Party. = CERT-FI Case number [FICORA #383115]
changed state Open to Active moved from Incoming to Software Bugs
changed notes changed state Active to Test
vulncoord@ficora.fi wrote: > Full_Name: Sauli Pahlman > Version: 2.4.22 > OS: Ubuntu Linux 9.10 i386 > URL: > Submission from: (NULL) (93.190.96.120) > > > Two OpenLDAP preauth, out of box and stock config exploitable vulnerabilities. > One null pointer dereference and one free based on uninitialized pointer, > potentially leading to total compromise. Thanks for the report. Bug #1 is now fixed in HEAD. Kurt, Ando, re: #2, it seems to me that ldap_bv2rdn_x should return an error for zero-length RDN values. When is it ever useful to name an entry with an empty-valued RDN? > = Description of bug #1 > OpenLDAP crashes with segfault during the processing of a modrdn call with > maliciously formed destination rdn string. No authentication is required to > trigger this vulnerability. > > = Description of bug #2 > OpenLDAP crashes at a null pointer dereference during the processing of modrdn > call with maliciously formed destination rdn string. No authentication is > required to trigger this vulnerability. > > = Analysis #1 > In the function modrdn.c:386:slap_modrdn2mods() a call is made to > 448:*desc->ad_type->sat_equality->smr_normalize() without checking its return > value. In this case the call fails and leaves mod_tmp->sml_nvalues uninitialized > which leads to an invalid free() later in modrdn.c:202:slap_mods_free(). The > breakdown of smr_normalize() is caused by invalid UTF-8 sequences, which are > passed to the software via hex-formatted strings. It could be possible to insert > and execute malicious code by careful manipulation of the program state prior to > triggering the vulnerability. At least with a vanilla compilation of 2.4.22 it > proved possible to freely control the invalid pointer being freed. For example, > the following kind of log message is produced: > * ** glibc detected *** /usr/sbin/slapd: double free or corruption (out): > 0x002ce400 *** > > = Analysis #2 > As with bug #1, the crash occurs during a call to smr_normalize, but in this > case the call points to IA5StringNormalize which crashes with a null pointer > dereference at schema_init.c:2696. > > = Proof of concept #1 > ldapmodrdn -x cn=something,dc=anything cn=#80 > Some tries may be required to reach segfault depending on what lies in the > uninitialized memory. > > = Proof of concept #2 > ldapmodrdn -x dc=something,dc=anything dc= > > = Tested versions > OpenLDAP 2.4.22 (vanilla), 2.4.11-1+lenny1, 2.4.21-0ubuntu5 > > = Credits > The vulnerability was found by Ilkka Mattila and Tuomas Salomäki with > Codenomicon LDAPv3 test suite at the Codenomicon Crash Test Party. > > = CERT-FI Case number [FICORA #383115] > > -- -- 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 Jun 6, 2010, at 11:48 AM, hyc@highlandsun.com wrote: > vulncoord@ficora.fi wrote: >> Full_Name: Sauli Pahlman >> Version: 2.4.22 >> OS: Ubuntu Linux 9.10 i386 >> URL: >> Submission from: (NULL) (93.190.96.120) >> >> >> Two OpenLDAP preauth, out of box and stock config exploitable vulnerabilities. >> One null pointer dereference and one free based on uninitialized pointer, >> potentially leading to total compromise. > > Thanks for the report. Bug #1 is now fixed in HEAD. Kurt, Ando, re: #2, it > seems to me that ldap_bv2rdn_x should return an error for zero-length RDN > values. When is it ever useful to name an entry with an empty-valued RDN? While it likely technically legal for the RDN to contain an AVA with a zero length value, I concur that it not generally useful. I have no objection to restricting distinguishing values to those which have non-zero length. -- Kurt > >> = Description of bug #1 >> OpenLDAP crashes with segfault during the processing of a modrdn call with >> maliciously formed destination rdn string. No authentication is required to >> trigger this vulnerability. >> >> = Description of bug #2 >> OpenLDAP crashes at a null pointer dereference during the processing of modrdn >> call with maliciously formed destination rdn string. No authentication is >> required to trigger this vulnerability. >> >> = Analysis #1 >> In the function modrdn.c:386:slap_modrdn2mods() a call is made to >> 448:*desc->ad_type->sat_equality->smr_normalize() without checking its return >> value. In this case the call fails and leaves mod_tmp->sml_nvalues uninitialized >> which leads to an invalid free() later in modrdn.c:202:slap_mods_free(). The >> breakdown of smr_normalize() is caused by invalid UTF-8 sequences, which are >> passed to the software via hex-formatted strings. It could be possible to insert >> and execute malicious code by careful manipulation of the program state prior to >> triggering the vulnerability. At least with a vanilla compilation of 2.4.22 it >> proved possible to freely control the invalid pointer being freed. For example, >> the following kind of log message is produced: >> * ** glibc detected *** /usr/sbin/slapd: double free or corruption (out): >> 0x002ce400 *** >> >> = Analysis #2 >> As with bug #1, the crash occurs during a call to smr_normalize, but in this >> case the call points to IA5StringNormalize which crashes with a null pointer >> dereference at schema_init.c:2696. >> >> = Proof of concept #1 >> ldapmodrdn -x cn=something,dc=anything cn=#80 >> Some tries may be required to reach segfault depending on what lies in the >> uninitialized memory. >> >> = Proof of concept #2 >> ldapmodrdn -x dc=something,dc=anything dc= >> >> = Tested versions >> OpenLDAP 2.4.22 (vanilla), 2.4.11-1+lenny1, 2.4.21-0ubuntu5 >> >> = Credits >> The vulnerability was found by Ilkka Mattila and Tuomas Salomäki with >> Codenomicon LDAPv3 test suite at the Codenomicon Crash Test Party. >> >> = CERT-FI Case number [FICORA #383115] >> >> > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > >
Kurt Zeilenga wrote: > > On Jun 6, 2010, at 11:48 AM, hyc@highlandsun.com wrote: > >> vulncoord@ficora.fi wrote: >>> Full_Name: Sauli Pahlman >>> Version: 2.4.22 >>> OS: Ubuntu Linux 9.10 i386 >>> URL: >>> Submission from: (NULL) (93.190.96.120) >>> >>> >>> Two OpenLDAP preauth, out of box and stock config exploitable vulnerabilities. >>> One null pointer dereference and one free based on uninitialized pointer, >>> potentially leading to total compromise. >> >> Thanks for the report. Bug #1 is now fixed in HEAD. Kurt, Ando, re: #2, it >> seems to me that ldap_bv2rdn_x should return an error for zero-length RDN >> values. When is it ever useful to name an entry with an empty-valued RDN? > > While it likely technically legal for the RDN to contain an AVA with a zero length value, I concur that it not generally useful. > > I have no objection to restricting distinguishing values to those which have non-zero length. OK. I've left libldap alone and fixed this in slapd. Back to Bug #1, this should have been caught in do_modrdn(), long before slap_modrdn2mods() got invoked, since we run dnPrettyNormal() on the inputs. The reason it doesn't is because when parsing "cn=#80" libldap sets the ava flag LDAP_AVA_BINARY. In slapd/dn.c when LDAPRDN_rewrite() sees this flag it skips the normalizers and validators. Seems to me that we should not be skipping them, we should always be validating according to the RDN type's syntax. Agreed? > > -- Kurt > >> >>> = Description of bug #1 >>> OpenLDAP crashes with segfault during the processing of a modrdn call with >>> maliciously formed destination rdn string. No authentication is required to >>> trigger this vulnerability. >>> >>> = Description of bug #2 >>> OpenLDAP crashes at a null pointer dereference during the processing of modrdn >>> call with maliciously formed destination rdn string. No authentication is >>> required to trigger this vulnerability. >>> >>> = Analysis #1 >>> In the function modrdn.c:386:slap_modrdn2mods() a call is made to >>> 448:*desc->ad_type->sat_equality->smr_normalize() without checking its return >>> value. In this case the call fails and leaves mod_tmp->sml_nvalues uninitialized >>> which leads to an invalid free() later in modrdn.c:202:slap_mods_free(). The >>> breakdown of smr_normalize() is caused by invalid UTF-8 sequences, which are >>> passed to the software via hex-formatted strings. It could be possible to insert >>> and execute malicious code by careful manipulation of the program state prior to >>> triggering the vulnerability. At least with a vanilla compilation of 2.4.22 it >>> proved possible to freely control the invalid pointer being freed. For example, >>> the following kind of log message is produced: >>> * ** glibc detected *** /usr/sbin/slapd: double free or corruption (out): >>> 0x002ce400 *** >>> >>> = Analysis #2 >>> As with bug #1, the crash occurs during a call to smr_normalize, but in this >>> case the call points to IA5StringNormalize which crashes with a null pointer >>> dereference at schema_init.c:2696. >>> >>> = Proof of concept #1 >>> ldapmodrdn -x cn=something,dc=anything cn=#80 >>> Some tries may be required to reach segfault depending on what lies in the >>> uninitialized memory. >>> >>> = Proof of concept #2 >>> ldapmodrdn -x dc=something,dc=anything dc= >>> >>> = Tested versions >>> OpenLDAP 2.4.22 (vanilla), 2.4.11-1+lenny1, 2.4.21-0ubuntu5 >>> >>> = Credits >>> The vulnerability was found by Ilkka Mattila and Tuomas Salomäki with >>> Codenomicon LDAPv3 test suite at the Codenomicon Crash Test Party. >>> >>> = CERT-FI Case number [FICORA #383115] -- -- 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 Jun 6, 2010, at 2:35 PM, Howard Chu wrote: > Kurt Zeilenga wrote: >> >> On Jun 6, 2010, at 11:48 AM, hyc@highlandsun.com wrote: >> >>> vulncoord@ficora.fi wrote: >>>> Full_Name: Sauli Pahlman >>>> Version: 2.4.22 >>>> OS: Ubuntu Linux 9.10 i386 >>>> URL: >>>> Submission from: (NULL) (93.190.96.120) >>>> >>>> >>>> Two OpenLDAP preauth, out of box and stock config exploitable vulnerabilities. >>>> One null pointer dereference and one free based on uninitialized pointer, >>>> potentially leading to total compromise. >>> >>> Thanks for the report. Bug #1 is now fixed in HEAD. Kurt, Ando, re: #2, it >>> seems to me that ldap_bv2rdn_x should return an error for zero-length RDN >>> values. When is it ever useful to name an entry with an empty-valued RDN? >> >> While it likely technically legal for the RDN to contain an AVA with a zero length value, I concur that it not generally useful. >> >> I have no objection to restricting distinguishing values to those which have non-zero length. > > OK. I've left libldap alone and fixed this in slapd. > > Back to Bug #1, this should have been caught in do_modrdn(), long before slap_modrdn2mods() got invoked, since we run dnPrettyNormal() on the inputs. The reason it doesn't is because when parsing "cn=#80" libldap sets the ava flag LDAP_AVA_BINARY. In slapd/dn.c when LDAPRDN_rewrite() sees this flag it skips the normalizers and validators. Seems to me that we should not be skipping them, we should always be validating according to the RDN type's syntax. Agreed? So, an AVA of cn=#80 means the BER encoding of this distinguished value is hex 80. That's obviously not a proper BER encoding of a directory string. We generally don't handle BER to LDAP string conversions. So, I think the simple fix is to error in case. -- Kurt >> >> -- Kurt >> >>> >>>> = Description of bug #1 >>>> OpenLDAP crashes with segfault during the processing of a modrdn call with >>>> maliciously formed destination rdn string. No authentication is required to >>>> trigger this vulnerability. >>>> >>>> = Description of bug #2 >>>> OpenLDAP crashes at a null pointer dereference during the processing of modrdn >>>> call with maliciously formed destination rdn string. No authentication is >>>> required to trigger this vulnerability. >>>> >>>> = Analysis #1 >>>> In the function modrdn.c:386:slap_modrdn2mods() a call is made to >>>> 448:*desc->ad_type->sat_equality->smr_normalize() without checking its return >>>> value. In this case the call fails and leaves mod_tmp->sml_nvalues uninitialized >>>> which leads to an invalid free() later in modrdn.c:202:slap_mods_free(). The >>>> breakdown of smr_normalize() is caused by invalid UTF-8 sequences, which are >>>> passed to the software via hex-formatted strings. It could be possible to insert >>>> and execute malicious code by careful manipulation of the program state prior to >>>> triggering the vulnerability. At least with a vanilla compilation of 2.4.22 it >>>> proved possible to freely control the invalid pointer being freed. For example, >>>> the following kind of log message is produced: >>>> * ** glibc detected *** /usr/sbin/slapd: double free or corruption (out): >>>> 0x002ce400 *** >>>> >>>> = Analysis #2 >>>> As with bug #1, the crash occurs during a call to smr_normalize, but in this >>>> case the call points to IA5StringNormalize which crashes with a null pointer >>>> dereference at schema_init.c:2696. >>>> >>>> = Proof of concept #1 >>>> ldapmodrdn -x cn=something,dc=anything cn=#80 >>>> Some tries may be required to reach segfault depending on what lies in the >>>> uninitialized memory. >>>> >>>> = Proof of concept #2 >>>> ldapmodrdn -x dc=something,dc=anything dc= >>>> >>>> = Tested versions >>>> OpenLDAP 2.4.22 (vanilla), 2.4.11-1+lenny1, 2.4.21-0ubuntu5 >>>> >>>> = Credits >>>> The vulnerability was found by Ilkka Mattila and Tuomas Salomäki with >>>> Codenomicon LDAPv3 test suite at the Codenomicon Crash Test Party. >>>> >>>> = CERT-FI Case number [FICORA #383115] > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/
Kurt Zeilenga wrote: > > On Jun 6, 2010, at 2:35 PM, Howard Chu wrote: > >> Kurt Zeilenga wrote: >>> >>> On Jun 6, 2010, at 11:48 AM, hyc@highlandsun.com wrote: >>> >>>> vulncoord@ficora.fi wrote: >>>>> Full_Name: Sauli Pahlman >>>>> Version: 2.4.22 >>>>> OS: Ubuntu Linux 9.10 i386 >>>>> URL: >>>>> Submission from: (NULL) (93.190.96.120) >>>>> >>>>> >>>>> Two OpenLDAP preauth, out of box and stock config exploitable vulnerabilities. >>>>> One null pointer dereference and one free based on uninitialized pointer, >>>>> potentially leading to total compromise. >>>> >>>> Thanks for the report. Bug #1 is now fixed in HEAD. Kurt, Ando, re: #2, it >>>> seems to me that ldap_bv2rdn_x should return an error for zero-length RDN >>>> values. When is it ever useful to name an entry with an empty-valued RDN? >>> >>> While it likely technically legal for the RDN to contain an AVA with a zero length value, I concur that it not generally useful. >>> >>> I have no objection to restricting distinguishing values to those which have non-zero length. >> >> OK. I've left libldap alone and fixed this in slapd. >> >> Back to Bug #1, this should have been caught in do_modrdn(), long before slap_modrdn2mods() got invoked, since we run dnPrettyNormal() on the inputs. The reason it doesn't is because when parsing "cn=#80" libldap sets the ava flag LDAP_AVA_BINARY. In slapd/dn.c when LDAPRDN_rewrite() sees this flag it skips the normalizers and validators. Seems to me that we should not be skipping them, we should always be validating according to the RDN type's syntax. Agreed? > > So, an AVA of cn=#80 means the BER encoding of this distinguished value is hex 80. That's obviously not a proper BER encoding of a directory string. > > We generally don't handle BER to LDAP string conversions. So, I think the simple fix is to error in case. Sounds good. OK, HEAD now simply rejects BER encoded RDN values. > > -- Kurt > >>> >>> -- Kurt >>> >>>> >>>>> = Description of bug #1 >>>>> OpenLDAP crashes with segfault during the processing of a modrdn call with >>>>> maliciously formed destination rdn string. No authentication is required to >>>>> trigger this vulnerability. >>>>> >>>>> = Description of bug #2 >>>>> OpenLDAP crashes at a null pointer dereference during the processing of modrdn >>>>> call with maliciously formed destination rdn string. No authentication is >>>>> required to trigger this vulnerability. >>>>> >>>>> = Analysis #1 >>>>> In the function modrdn.c:386:slap_modrdn2mods() a call is made to >>>>> 448:*desc->ad_type->sat_equality->smr_normalize() without checking its return >>>>> value. In this case the call fails and leaves mod_tmp->sml_nvalues uninitialized >>>>> which leads to an invalid free() later in modrdn.c:202:slap_mods_free(). The >>>>> breakdown of smr_normalize() is caused by invalid UTF-8 sequences, which are >>>>> passed to the software via hex-formatted strings. It could be possible to insert >>>>> and execute malicious code by careful manipulation of the program state prior to >>>>> triggering the vulnerability. At least with a vanilla compilation of 2.4.22 it >>>>> proved possible to freely control the invalid pointer being freed. For example, >>>>> the following kind of log message is produced: >>>>> * ** glibc detected *** /usr/sbin/slapd: double free or corruption (out): >>>>> 0x002ce400 *** >>>>> >>>>> = Analysis #2 >>>>> As with bug #1, the crash occurs during a call to smr_normalize, but in this >>>>> case the call points to IA5StringNormalize which crashes with a null pointer >>>>> dereference at schema_init.c:2696. >>>>> >>>>> = Proof of concept #1 >>>>> ldapmodrdn -x cn=something,dc=anything cn=#80 >>>>> Some tries may be required to reach segfault depending on what lies in the >>>>> uninitialized memory. >>>>> >>>>> = Proof of concept #2 >>>>> ldapmodrdn -x dc=something,dc=anything dc= >>>>> >>>>> = Tested versions >>>>> OpenLDAP 2.4.22 (vanilla), 2.4.11-1+lenny1, 2.4.21-0ubuntu5 >>>>> >>>>> = Credits >>>>> The vulnerability was found by Ilkka Mattila and Tuomas Salomäki with >>>>> Codenomicon LDAPv3 test suite at the Codenomicon Crash Test Party. >>>>> >>>>> = CERT-FI Case number [FICORA #383115] -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Test to Release
>> Two OpenLDAP preauth, out of box and stock config exploitable >> vulnerabilities. >> One null pointer dereference and one free based on uninitialized pointer, >> potentially leading to total compromise. > > Thanks for the report. Bug #1 is now fixed in HEAD. Kurt, Ando, re: #2, > it seems to me that ldap_bv2rdn_x should return an error for zero-length > RDN values. When is it ever useful to name an entry with an empty-valued > RDN? Hi, I noticed that this is now fixed in HEAD and 2.4 REL_ENG branches. Are you planning to publish a new minor version on this? Also, is it OK for you if we inform vendor-sec about these issues? Regards, Sauli Pahlman CERT-FI
CERT-FI Vulnerability Coordination wrote: > >>> Two OpenLDAP preauth, out of box and stock config exploitable >>> vulnerabilities. >>> One null pointer dereference and one free based on uninitialized pointer, >>> potentially leading to total compromise. >> >> Thanks for the report. Bug #1 is now fixed in HEAD. Kurt, Ando, re: #2, >> it seems to me that ldap_bv2rdn_x should return an error for zero-length >> RDN values. When is it ever useful to name an entry with an empty-valued >> RDN? > > Hi, > > I noticed that this is now fixed in HEAD and 2.4 REL_ENG branches. Are > you planning to publish a new minor version on this? Also, is it OK for > you if we inform vendor-sec about these issues? Yes, we've just done a call for testing on the new release: http://www.openldap.org/lists/openldap-devel/201006/msg00000.html If no problems are reported it should be available in a few days. Typically we won't make a security ITS like this public until the release is actually posted. Do you have any particular time pressure in these other notifications? > Regards, > > Sauli Pahlman > CERT-FI > -- -- 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 Jun 11, 2010, at 6:58 AM, vulncoord@ficora.fi wrote: > >>> Two OpenLDAP preauth, out of box and stock config exploitable >>> vulnerabilities. >>> One null pointer dereference and one free based on uninitialized pointer, >>> potentially leading to total compromise. >> >> Thanks for the report. Bug #1 is now fixed in HEAD. Kurt, Ando, re: #2, >> it seems to me that ldap_bv2rdn_x should return an error for zero-length >> RDN values. When is it ever useful to name an entry with an empty-valued >> RDN? > > Hi, > > I noticed that this is now fixed in HEAD and 2.4 REL_ENG branches. Are > you planning to publish a new minor version on this? I believe new patch release is being tested now. > Also, is it OK for you if we inform vendor-sec about these issues? The Foundation does not consider any issue report to be subject to any requirement for it or any other party to hold in confidence. I suspect the Project will soon be making this particular report public. -- Kurt (as Executive Director, OpenLDAP Foundation)
>> Hi, >> >> I noticed that this is now fixed in HEAD and 2.4 REL_ENG branches. Are >> you planning to publish a new minor version on this? Also, is it OK for >> you if we inform vendor-sec about these issues? > > Yes, we've just done a call for testing on the new release: > > http://www.openldap.org/lists/openldap-devel/201006/msg00000.html > > If no problems are reported it should be available in a few days. > > Typically we won't make a security ITS like this public until the > release is actually posted. Do you have any particular time pressure in > these other notifications? Ah, quick availablity sounds good. We do not have any time constraints, you can take the time you need. It would be ideal however if we could give vendor-sec an early warning on this release, perhaps around two days before the information becomes public. I am not a big fan of embargoes, but vendor-sec in used to embargoes so we can require them to embargo the information until 2.4.23 is officially released. Sauli
>> Also, is it OK for you if we inform vendor-sec about these issues? > > The Foundation does not consider any issue report to be subject to > any requirement for it or any other party to hold in confidence. I > suspect the Project will soon be making this particular report > public. OK, we do not have any problem with releasing right away once everything is tested. Perhaps I could inform vendor-sec tomorrow and ask them to embargo the information until 2.4.23 is available. This would perhaps give the vendors some time to prepare new packages. And you just do the release whenever you are ready. -Sauli
CERT-FI Vulnerability Coordination wrote: >>> Hi, >>> >>> I noticed that this is now fixed in HEAD and 2.4 REL_ENG branches. Are >>> you planning to publish a new minor version on this? Also, is it OK for >>> you if we inform vendor-sec about these issues? >> >> Yes, we've just done a call for testing on the new release: >> >> http://www.openldap.org/lists/openldap-devel/201006/msg00000.html >> >> If no problems are reported it should be available in a few days. >> >> Typically we won't make a security ITS like this public until the >> release is actually posted. Do you have any particular time pressure in >> these other notifications? > > Ah, quick availablity sounds good. We do not have any time constraints, > you can take the time you need. It would be ideal however if we could > give vendor-sec an early warning on this release, perhaps around two > days before the information becomes public. I am not a big fan of > embargoes, but vendor-sec in used to embargoes so we can require them to > embargo the information until 2.4.23 is officially released. That sounds fine then, thanks. > Sauli > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Hi, I am not sure whether you have any use for these, but we have allocated CVEs for the two issues. They are as follows: > = Description of bug #1 > OpenLDAP crashes with segfault during the processing of a modrdn call > with maliciously formed destination rdn string. No authentication is > required to trigger this vulnerability. CVE-2010-0211 > = Description of bug #2 > OpenLDAP crashes at a null pointer dereference during the processing > of modrdn call with maliciously formed destination rdn string. No > authentication is required to trigger this vulnerability. CVE-2010-0212 -Sauli
changed notes changed state Release to Closed
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> I noticed that this is now fixed in HEAD and 2.4 REL_ENG branches. Are >> you planning to publish a new minor version on this? Also, is it OK for >> you if we inform vendor-sec about these issues? > > Yes, we've just done a call for testing on the new release: > > http://www.openldap.org/lists/openldap-devel/201006/msg00000.html > > If no problems are reported it should be available in a few days. > > Typically we won't make a security ITS like this public until the > release is actually posted. Do you have any particular time pressure in > these other notifications? Are you planning to make ITS#6570 public or mention it's security relevancy? I also noticed that 2.4.23 came out last week so perhaps we could give Linux vendors etc a go regarding their releases? Regards, Sauli -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkwy4K4ACgkQ/64aC2E+yK/YMACeLS9KL5m327+PypRGD6Kywhlu 4hYAn29XgMXPZ/w1oof4naoVfXZc4iPt =WyyH -----END PGP SIGNATURE-----
changed notes published 6570 marked public
fixed in HEAD fixed in RE24