OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Software Bugs/6570
Full headers

From: vulncoord@ficora.fi
Subject: SECURITY: Two OpenLDAP preauth vulnerabilities
Compose comment
Download message
State:
0 replies:
13 followups: 1 2 3 4 5 6 7 8 9 10 11 12 13

Major security issue: yes  no

Notes:

Notification:


Date: Fri, 04 Jun 2010 08:09:34 +0000
From: vulncoord@ficora.fi
To: openldap-its@OpenLDAP.org
Subject: SECURITY: Two OpenLDAP preauth vulnerabilities
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]

Followup 1

Download message
Date: Sun, 06 Jun 2010 11:48:00 -0700
From: Howard Chu <hyc@highlandsun.com>
To: vulncoord@ficora.fi
CC: openldap-its@openldap.org
Subject: Re: (ITS#6570) SECURITY: Two OpenLDAP preauth vulnerabilities
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/



Followup 2

Download message
Subject: Re: (ITS#6570) SECURITY: Two OpenLDAP preauth vulnerabilities
From: Kurt Zeilenga <Kurt@OpenLDAP.org>
Date: Sun, 6 Jun 2010 13:58:31 -0700
Cc: openldap-its@OpenLDAP.org
To: hyc@highlandsun.com
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)
>>=20
>>=20
>> 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.
>=20
> Thanks for the report. Bug #1 is now fixed in HEAD. Kurt, Ando, re: =
#2, it=20
> seems to me that ldap_bv2rdn_x should return an error for zero-length =
RDN=20
> 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

>=20
>> =3D 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.
>>=20
>> =3D 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.
>>=20
>> =3D 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 ***
>>=20
>> =3D 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.
>>=20
>> =3D Proof of concept #1
>> 	ldapmodrdn -x cn=3Dsomething,dc=3Danything cn=3D#80
>> 	Some tries may be required to reach segfault depending on what =
lies in the
>> uninitialized memory.
>>=20
>> =3D Proof of concept #2
>> 	ldapmodrdn -x dc=3Dsomething,dc=3Danything dc=3D
>>=20
>> =3D Tested versions
>> 	OpenLDAP 2.4.22 (vanilla), 2.4.11-1+lenny1, 2.4.21-0ubuntu5
>>=20
>> =3D Credits
>> 	The vulnerability was found by Ilkka Mattila and Tuomas Salom=E4ki=
 with
>> Codenomicon LDAPv3 test suite at the Codenomicon Crash Test Party.
>>=20
>> =3D CERT-FI Case number [FICORA #383115]
>>=20
>>=20
>=20
>=20
> --=20
>   -- Howard Chu
>   CTO, Symas Corp.           http://www.symas.com
>   Director, Highland Sun     http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/
>=20
>=20



Followup 3

Download message
Date: Sun, 06 Jun 2010 14:35:46 -0700
From: Howard Chu <hyc@highlandsun.com>
To: Kurt Zeilenga <Kurt@OpenLDAP.org>
CC: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6570) SECURITY: Two OpenLDAP preauth vulnerabilities
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/



Followup 4

Download message
Subject: Re: (ITS#6570) SECURITY: Two OpenLDAP preauth vulnerabilities
From: Kurt Zeilenga <Kurt@OpenLDAP.org>
Date: Sun, 6 Jun 2010 14:45:43 -0700
Cc: openldap-its@OpenLDAP.org
To: Howard Chu <hyc@highlandsun.com>
On Jun 6, 2010, at 2:35 PM, Howard Chu wrote:

> Kurt Zeilenga wrote:
>>=20
>> On Jun 6, 2010, at 11:48 AM, hyc@highlandsun.com wrote:
>>=20
>>> 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)
>>>>=20
>>>>=20
>>>> 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.
>>>=20
>>> 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?
>>=20
>> While it likely technically legal for the RDN to contain an AVA with =
a zero length value, I concur that it not generally useful.
>>=20
>> I have no objection to restricting distinguishing values to those =
which have non-zero length.
>=20
> OK. I've left libldap alone and fixed this in slapd.
>=20
> 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=3D#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=3D#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

>>=20
>> -- Kurt
>>=20
>>>=20
>>>> =3D 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.
>>>>=20
>>>> =3D 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.
>>>>=20
>>>> =3D 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 ***
>>>>=20
>>>> =3D 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.
>>>>=20
>>>> =3D Proof of concept #1
>>>> 	ldapmodrdn -x cn=3Dsomething,dc=3Danything cn=3D#80
>>>> 	Some tries may be required to reach segfault depending on what
=
lies in the
>>>> uninitialized memory.
>>>>=20
>>>> =3D Proof of concept #2
>>>> 	ldapmodrdn -x dc=3Dsomething,dc=3Danything dc=3D
>>>>=20
>>>> =3D Tested versions
>>>> 	OpenLDAP 2.4.22 (vanilla), 2.4.11-1+lenny1, 2.4.21-0ubuntu5
>>>>=20
>>>> =3D Credits
>>>> 	The vulnerability was found by Ilkka Mattila and Tuomas
Salom=E4ki=
 with
>>>> Codenomicon LDAPv3 test suite at the Codenomicon Crash Test
Party.
>>>>=20
>>>> =3D CERT-FI Case number [FICORA #383115]
>=20
>=20

Message of length 5214 truncated


Followup 5

Download message
Date: Sun, 06 Jun 2010 15:04:10 -0700
From: Howard Chu <hyc@highlandsun.com>
To: Kurt Zeilenga <Kurt@OpenLDAP.org>
CC: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6570) SECURITY: Two OpenLDAP preauth vulnerabilities
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
>

Message of length 5452 truncated


Followup 6

Download message
Date: Fri, 11 Jun 2010 16:57:18 +0300
From: CERT-FI Vulnerability Coordination <vulncoord@ficora.fi>
To: Howard Chu <hyc@highlandsun.com>
CC: openldap-its@openldap.org
Subject: Re: [FICORA #383115] (ITS#6570) SECURITY: Two OpenLDAP preauth vulnerabilities
>> 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



Followup 7

Download message
Date: Fri, 11 Jun 2010 11:53:04 -0700
From: Howard Chu <hyc@highlandsun.com>
To: CERT-FI Vulnerability Coordination <vulncoord@ficora.fi>
CC: openldap-its@openldap.org
Subject: Re: [FICORA #383115] (ITS#6570) SECURITY: Two OpenLDAP preauth vulnerabilities
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/



Followup 8

Download message
Subject: Re: [FICORA #383115] (ITS#6570) SECURITY: Two OpenLDAP preauth vulnerabilities
From: Kurt Zeilenga <Kurt@OpenLDAP.org>
Date: Fri, 11 Jun 2010 12:25:51 -0700
Cc: openldap-its@OpenLDAP.org
To: vulncoord@ficora.fi
On Jun 11, 2010, at 6:58 AM, vulncoord@ficora.fi wrote:

>=20
>>> 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.
>>=20
>> 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?
>=20
> Hi,
>=20
> 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)



Followup 9

Download message
Date: Sat, 12 Jun 2010 00:40:12 +0300
From: CERT-FI Vulnerability Coordination <vulncoord@ficora.fi>
To: Howard Chu <hyc@highlandsun.com>
CC: openldap-its@openldap.org
Subject: Re: [FICORA #383115] (ITS#6570) SECURITY: Two OpenLDAP preauth vulnerabilities
>> 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



Followup 10

Download message
Date: Sat, 12 Jun 2010 00:45:46 +0300
From: CERT-FI Vulnerability Coordination <vulncoord@ficora.fi>
To: Kurt Zeilenga <Kurt@OpenLDAP.org>
CC: openldap-its@OpenLDAP.org,
        CERT-FI Vulnerability Co-ordination <vulncoord@ficora.fi>
Subject: Re: [FICORA #383115] (ITS#6570) SECURITY: Two OpenLDAP preauth vulnerabilities
>> 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



Followup 11

Download message
Date: Sat, 12 Jun 2010 01:05:05 -0700
From: Howard Chu <hyc@highlandsun.com>
To: CERT-FI Vulnerability Coordination <vulncoord@ficora.fi>
CC: openldap-its@openldap.org
Subject: Re: [FICORA #383115] (ITS#6570) SECURITY: Two OpenLDAP preauth vulnerabilities
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/



Followup 12

Download message
Date: Tue, 15 Jun 2010 13:24:29 +0300
From: CERT-FI Vulnerability Coordination <vulncoord@ficora.fi>
To: Howard Chu <hyc@highlandsun.com>
CC: openldap-its@openldap.org,
        CERT-FI Vulnerability Co-ordination <vulncoord@ficora.fi>
Subject: Re: [FICORA #383115] (ITS#6570) SECURITY: Two OpenLDAP preauth vulnerabilities
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



Followup 13

Download message
Date: Tue, 06 Jul 2010 10:52:25 +0300
From: CERT-FI Vulnerability Coordination <vulncoord@ficora.fi>
To: Howard Chu <hyc@highlandsun.com>
CC: openldap-its@openldap.org,
        CERT-FI Vulnerability Co-ordination <vulncoord@ficora.fi>
Subject: Re: [FICORA #383115] (ITS#6570) SECURITY: Two OpenLDAP preauth vulnerabilities
-----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-----


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org