Re: (ITS#7286) Malformed search filter to back-ldap/slapo-rwm crashes slapd
by gahaverkamp＠lbl.gov
--e89a8fb1fbfae973ef04c1b0bad6
Content-Type: text/plain; charset=ISO-8859-1
I thought I had, but I now see that I left off "full".
(gdb) bt full
#0 0x0000003f6987a31c in free () from /lib64/libc.so.6
No symbol table info available.
#1 0x000000000043ca3e in ava_free (op=0x7fffe8002970, ava=0x7fffe8002e50,
freeit=1) at ava.c:50
No locals.
#2 0x000000000042453a in filter_free_x (op=0x7fffe8002970,
f=0x7fffe8002ed0, freeme=1) at filter.c:531
p = <value optimized out>
next = <value optimized out>
#3 0x0000000000423127 in do_search (op=0x7fffe8002970, rs=0x7ffff640b950)
at search.c:260
base = {bv_len = 10, bv_val = 0x7fffe8002707 "cn=example"}
siz = 1
off = <value optimized out>
i = <value optimized out>
#4 0x0000000000420cfb in connection_operation (ctx=0x7ffff640bab0,
arg_v=0x7fffe8002970) at connection.c:1150
rc = 80
cancel = <value optimized out>
op = 0x7fffe8002970
rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 1, sr_err = 0,
sr_matched = 0x0, sr_text = 0x56d3ae "massaged filter parse error", sr_ref
= 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags =
0, r_operational_attrs = 0x0,
r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl =
{r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}},
sr_flags = 0}
tag = 99
opidx = SLAP_OP_SEARCH
conn = 0x7ffff6c103d0
memctx = 0x7fffe8000a80
memctx_null = 0x0
memsiz = 1048576
__PRETTY_FUNCTION__ = "connection_operation"
#5 0x00000000004214d5 in connection_read_thread (ctx=0x7ffff640bab0,
argv=<value optimized out>) at connection.c:1286
rc = <value optimized out>
cri = {op = 0x7fffe8002970, func = 0, arg = 0x0, ctx =
0x7ffff640bab0, nullop = <value optimized out>}
s = <value optimized out>
#6 0x000000000050cc30 in ldap_int_thread_pool_wrapper (xpool=0x8809a0) at
tpool.c:688
pool = 0x8809a0
task = 0x7ffff00008c0
work_list = <value optimized out>
ctx = {ltu_id = 140737324828416, ltu_key = {{ltk_key = 0x41fa50,
ltk_data = 0x7fffe8002900, ltk_free = 0x41fb20 <conn_counter_destroy>},
{ltk_key = 0x473490, ltk_data = 0x7fffe8000a80, ltk_free = 0x4734b0
<slap_sl_mem_destroy>}, {ltk_key = 0x0,
ltk_data = 0x0, ltk_free = 0} <repeats 30 times>}}
kctx = <value optimized out>
keyslot = 923
hash = <value optimized out>
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#7 0x0000003f69c077f1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#8 0x0000003f698e592d in clone () from /lib64/libc.so.6
No symbol table info available.
On Mon, Jun 4, 2012 at 7:17 PM, <quanah(a)zimbra.com> wrote:
> --On Tuesday, June 05, 2012 1:50 AM +0000 gahaverkamp(a)lbl.gov wrote:
>
> > Full_Name: Greg Haverkamp
> > Version: 2.4.31
> > OS: RHEL 6.2/OS X 10.7
> > URL: ftp://ftp.openldap.org/incoming/
> > Submission from: (NULL) (128.3.10.46)
> >
> >
> > When a request to a massaged suffix is made of back-ldap/slapo-rwm with a
> > malformed filter, slapd crashes on the two tested platforms (RHEL 6.2/OS
> X
> > 10.7). The last bits of the debug log and the backtrace are below:
>
> I would suggest putting slapd under gdb and providing a backtrace.
>
> See <http://www.openldap.org/faq/data/cache/59.html>
>
> --Quanah
>
>
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
>
>
--e89a8fb1fbfae973ef04c1b0bad6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I thought I had, but I now see that I left off "full".<div><br></=
div><div><div>(gdb) bt full</div><div>#0 =A00x0000003f6987a31c in free () f=
rom /lib64/libc.so.6</div><div>No symbol table info available.</div><div>#1=
=A00x000000000043ca3e in ava_free (op=3D0x7fffe8002970, ava=3D0x7fffe8002e=
50, freeit=3D1) at ava.c:50</div>
<div>No locals.</div><div>#2 =A00x000000000042453a in filter_free_x (op=3D0=
x7fffe8002970, f=3D0x7fffe8002ed0, freeme=3D1) at filter.c:531</div><div>=
=A0 =A0 =A0 =A0 p =3D <value optimized out></div><div>=A0 =A0 =A0 =A0=
next =3D <value optimized out></div>
<div>#3 =A00x0000000000423127 in do_search (op=3D0x7fffe8002970, rs=3D0x7ff=
ff640b950) at search.c:260</div><div>=A0 =A0 =A0 =A0 base =3D {bv_len =3D 1=
0, bv_val =3D 0x7fffe8002707 "cn=3Dexample"}</div><div>=A0 =A0 =
=A0 =A0 siz =3D 1</div><div>=A0 =A0 =A0 =A0 off =3D <value optimized out=
></div>
<div>=A0 =A0 =A0 =A0 i =3D <value optimized out></div><div>#4 =A00x00=
00000000420cfb in connection_operation (ctx=3D0x7ffff640bab0, arg_v=3D0x7ff=
fe8002970) at connection.c:1150</div><div>=A0 =A0 =A0 =A0 rc =3D 80</div><d=
iv>=A0 =A0 =A0 =A0 cancel =3D <value optimized out></div>
<div>=A0 =A0 =A0 =A0 op =3D 0x7fffe8002970</div><div>=A0 =A0 =A0 =A0 rs =3D=
{sr_type =3D REP_RESULT, sr_tag =3D 101, sr_msgid =3D 1, sr_err =3D 0, sr_=
matched =3D 0x0, sr_text =3D 0x56d3ae "massaged filter parse error&quo=
t;, sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr_un =3D {sru_search =3D {r_entry =
=3D 0x0, r_attr_flags =3D 0, r_operational_attrs =3D 0x0,=A0</div>
<div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 r_attrs =3D 0x0, r_nentries =3D 0, r_v2ref=
=3D 0x0}, sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid =
=3D 0x0, r_rspdata =3D 0x0}}, sr_flags =3D 0}</div><div>=A0 =A0 =A0 =A0 tag=
=3D 99</div><div>=A0 =A0 =A0 =A0 opidx =3D SLAP_OP_SEARCH</div>
<div>=A0 =A0 =A0 =A0 conn =3D 0x7ffff6c103d0</div><div>=A0 =A0 =A0 =A0 memc=
tx =3D 0x7fffe8000a80</div><div>=A0 =A0 =A0 =A0 memctx_null =3D 0x0</div><d=
iv>=A0 =A0 =A0 =A0 memsiz =3D 1048576</div><div>=A0 =A0 =A0 =A0 __PRETTY_FU=
NCTION__ =3D "connection_operation"</div>
<div>#5 =A00x00000000004214d5 in connection_read_thread (ctx=3D0x7ffff640ba=
b0, argv=3D<value optimized out>) at connection.c:1286</div><div>=A0 =
=A0 =A0 =A0 rc =3D <value optimized out></div><div>=A0 =A0 =A0 =A0 cr=
i =3D {op =3D 0x7fffe8002970, func =3D 0, arg =3D 0x0, ctx =3D 0x7ffff640ba=
b0, nullop =3D <value optimized out>}</div>
<div>=A0 =A0 =A0 =A0 s =3D <value optimized out></div><div>#6 =A00x00=
0000000050cc30 in ldap_int_thread_pool_wrapper (xpool=3D0x8809a0) at tpool.=
c:688</div><div>=A0 =A0 =A0 =A0 pool =3D 0x8809a0</div><div>=A0 =A0 =A0 =A0=
task =3D 0x7ffff00008c0</div>
<div>=A0 =A0 =A0 =A0 work_list =3D <value optimized out></div><div>=
=A0 =A0 =A0 =A0 ctx =3D {ltu_id =3D 140737324828416, ltu_key =3D {{ltk_key =
=3D 0x41fa50, ltk_data =3D 0x7fffe8002900, ltk_free =3D 0x41fb20 <conn_c=
ounter_destroy>}, {ltk_key =3D 0x473490, ltk_data =3D 0x7fffe8000a80, lt=
k_free =3D 0x4734b0 <slap_sl_mem_destroy>}, {ltk_key =3D 0x0,=A0</div=
>
<div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 ltk_data =3D 0x0, ltk_free =3D 0} <repe=
ats 30 times>}}</div><div>=A0 =A0 =A0 =A0 kctx =3D <value optimized o=
ut></div><div>=A0 =A0 =A0 =A0 keyslot =3D 923</div><div>=A0 =A0 =A0 =A0 =
hash =3D <value optimized out></div><div>
=A0 =A0 =A0 =A0 __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper&=
quot;</div><div>#7 =A00x0000003f69c077f1 in start_thread () from /lib64/lib=
pthread.so.0</div><div>No symbol table info available.</div><div>#8 =A00x00=
00003f698e592d in clone () from /lib64/libc.so.6</div>
<div>No symbol table info available.</div></div><div><br></div><div><br><di=
v><br><div class=3D"gmail_quote">On Mon, Jun 4, 2012 at 7:17 PM, <span dir=
=3D"ltr"><<a href=3D"mailto:quanah@zimbra.com" target=3D"_blank">quanah@=
zimbra.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">--On=
Tuesday, June 05, 2012 1:50 AM +0000 <a href=3D"mailto:gahaverkamp@lbl.gov=
">gahaverkamp(a)lbl.gov</a> wrote:<br>
<br>
> Full_Name: Greg Haverkamp<br>
> Version: 2.4.31<br>
> OS: RHEL 6.2/OS X 10.7<br>
> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ft=
p://ftp.openldap.org/incoming/</a><br>
> Submission from: (NULL) (128.3.10.46)<br>
><br>
><br>
> When a request to a massaged suffix is made of back-ldap/slapo-rwm wit=
h a<br>
> malformed filter, slapd crashes on the two tested platforms (RHEL 6.2/=
OS X<br>
> 10.7). =A0The last bits of the debug log and the backtrace are below:<=
br>
<br>
I would suggest putting slapd under gdb and providing a backtrace.<br>
<br>
See <<a href=3D"http://www.openldap.org/faq/data/cache/59.html" target=
=3D"_blank">http://www.openldap.org/faq/data/cache/59.html</a>><br>
<br>
--Quanah<br>
<br>
<br>
<br>
--<br>
<br>
Quanah Gibson-Mount<br>
Sr. Member of Technical Staff<br>
Zimbra, Inc<br>
A Division of VMware, Inc.<br>
--------------------<br>
Zimbra :: =A0the leader in open source messaging and collaboration<br>
<br>
<br>
</div></div></blockquote></div><br></div></div>
--e89a8fb1fbfae973ef04c1b0bad6--
10 years, 10 months
Re: (ITS#7286) Malformed search filter to back-ldap/slapo-rwm crashes slapd
by quanah＠zimbra.com
--On Tuesday, June 05, 2012 1:50 AM +0000 gahaverkamp(a)lbl.gov wrote:
> Full_Name: Greg Haverkamp
> Version: 2.4.31
> OS: RHEL 6.2/OS X 10.7
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (128.3.10.46)
>
>
> When a request to a massaged suffix is made of back-ldap/slapo-rwm with a
> malformed filter, slapd crashes on the two tested platforms (RHEL 6.2/OS X
> 10.7). The last bits of the debug log and the backtrace are below:
I would suggest putting slapd under gdb and providing a backtrace.
See <http://www.openldap.org/faq/data/cache/59.html>
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years, 10 months
(ITS#7286) Malformed search filter to back-ldap/slapo-rwm crashes slapd
by gahaverkamp＠lbl.gov
Full_Name: Greg Haverkamp
Version: 2.4.31
OS: RHEL 6.2/OS X 10.7
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (128.3.10.46)
When a request to a massaged suffix is made of back-ldap/slapo-rwm with a
malformed filter, slapd crashes on the two tested platforms (RHEL 6.2/OS X
10.7). The last bits of the debug log and the backtrace are below:
[New Thread 0x7ffff640c700 (LWP 4520)]
4fcd62a8 >>> slap_listener(ldap://*:3389)
4fcd62a8 connection_get(13)
4fcd62a8 connection_get(13): got connid=1000
4fcd62a8 connection_read(13): checking for input on id=1000
ber_get_next
ldap_read: want=8, got=8
0000: 30 44 02 01 01 63 3f 04 0D...c?.
ldap_read: want=62, got=62
0000: 0a 63 6e 3d 65 78 61 6d 70 6c 65 0a 01 02 0a 01 .cn=example.....
0010: 00 02 01 00 02 01 00 01 01 00 a3 13 04 04 66 6f ..............fo
0020: 6f 20 04 0b 67 61 68 61 76 65 72 6b 61 6d 70 30 o ..gahaverkamp0
0030: 0d 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 ...objectClass
ber_get_next: tag 0x30 len 68 contents:
4fcd62a8 op tag 0x63, time 1338860200
ber_get_next
ldap_read: want=8 error=Resource temporarily unavailable
4fcd62a8 conn=1000 op=0 do_search
ber_scanf fmt ({miiiib) ber:
4fcd62a8 >>> dnPrettyNormal: <cn=example>
=> ldap_bv2dn(cn=example,0)
<= ldap_bv2dn(cn=example)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=example)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=example)=0
4fcd62a8 <<< dnPrettyNormal: <cn=example>, <cn=example>
4fcd62a8 SRCH "cn=example" 2 04fcd62a8 0 0 0
ber_scanf fmt ({mm}) ber:
4fcd62a8 filter: (?foo =gahaverkamp)
ber_scanf fmt ({M}}) ber:
4fcd62a8 attrs:4fcd62a8 objectClass4fcd62a8
4fcd62a8 ==> limits_get: conn=1000 op=0 self="[anonymous]" this="cn=example"
4fcd62a8 ==> rewrite_context_apply [depth=1] string='cn=example'
4fcd62a8 ==> rewrite_rule_apply rule='((.+),)?cn=example$' string='cn=example'
[1 pass(es)]
4fcd62a8 ==> rewrite_context_apply [depth=1] res={0,'dc=lbl,dc=gov'}
4fcd62a8 [rw] searchDN: "cn=example" -> "dc=lbl,dc=gov"
4fcd62a8 >>> dnPrettyNormal: <dc=lbl,dc=gov>
=> ldap_bv2dn(dc=lbl,dc=gov,0)
<= ldap_bv2dn(dc=lbl,dc=gov)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(dc=lbl,dc=gov)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(dc=lbl,dc=gov)=0
4fcd62a8 <<< dnPrettyNormal: <dc=lbl,dc=gov>, <dc=lbl,dc=gov>
4fcd62a8 ==> rewrite_context_apply [depth=1] string='(foo =gahaverkamp)'
4fcd62a8 ==> rewrite_context_apply [depth=1] res={0,'NULL'}
[rw] searchFilter: "(foo =gahaverkamp)" -> "(foo =gahaverkamp)"
put_filter: "(foo =gahaverkamp)"
put_filter: simple
put_simple_filter: "foo =gahaverkamp"
4fcd62a8 send_ldap_result: conn=1000 op=0 p=3
4fcd62a8 send_ldap_result: err=0 matched="" text="massaged filter parse error"
4fcd62a8 send_ldap_response: msgid=1 tag=101 err=0
ber_flush2: 41 bytes to sd 13
ldap_write: want=41, written=41
0000: 30 27 02 01 01 65 22 0a 01 00 04 00 04 1b 6d 61 0'...e".......ma
0010: 73 73 61 67 65 64 20 66 69 6c 74 65 72 20 70 61 ssaged filter pa
0020: 72 73 65 20 65 72 72 6f 72 rse error
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff640c700 (LWP 4520)]
0x0000003f6987a31c in free () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install
cyrus-sasl-gssapi-2.1.23-13.el6.x86_64 cyrus-sasl-lib-2.1.23-13.el6.x86_64
cyrus-sasl-plain-2.1.23-13.el6.x86_64 db4-4.7.25-16.el6.x86_64
glibc-2.12-1.47.el6_2.5.x86_64 keyutils-libs-1.4-3.el6.x86_64
krb5-libs-1.9-22.el6_2.1.x86_64 libcom_err-1.41.12-11.el6.x86_64
libselinux-2.0.94-5.2.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64
openssl-1.0.0-20.el6_2.1.x86_64 zlib-1.2.3-27.el6.x86_64
(gdb) bt
#0 0x0000003f6987a31c in free () from /lib64/libc.so.6
#1 0x000000000043ca3e in ava_free (op=0x7fffe8002970, ava=0x7fffe8002e50,
freeit=1) at ava.c:50
#2 0x000000000042453a in filter_free_x (op=0x7fffe8002970, f=0x7fffe8002ed0,
freeme=1) at filter.c:531
#3 0x0000000000423127 in do_search (op=0x7fffe8002970, rs=0x7ffff640b950) at
search.c:260
#4 0x0000000000420cfb in connection_operation (ctx=0x7ffff640bab0,
arg_v=0x7fffe8002970) at connection.c:1150
#5 0x00000000004214d5 in connection_read_thread (ctx=0x7ffff640bab0,
argv=<value optimized out>) at connection.c:1286
#6 0x000000000050cc30 in ldap_int_thread_pool_wrapper (xpool=0x8809a0) at
tpool.c:688
#7 0x0000003f69c077f1 in start_thread () from /lib64/libpthread.so.0
#8 0x0000003f698e592d in clone () from /lib64/libc.so.6
ldapsearch takes care of handling the bad search filter. However, the problem
arose when one of our developers miscoded the search filter (badly). A short
bit of Jython (utilizing the UnboundID ldap sdk) that can cause the crash is
here:
from com.unboundid.ldap.sdk import LDAPConnection
from com.unboundid.ldap.sdk import SearchScope
from com.unboundid.ldap.sdk import SearchResult
from com.unboundid.ldap.sdk import LDAPURL
attributes = ['objectClass']
ldap_url = "ldap://10.0.228.135:3389"
url = LDAPURL(ldap_url)
ldap_conn = LDAPConnection(url.getHost(), url.getPort())
#search_result = ldap_conn.search('ou=people,o=lawrence berkeley
laboratory,c=us', SearchScope.SUB, '(?uid = \'gahaverkamp\')', attributes)
search_result = ldap_conn.search('cn=example', SearchScope.SUB, '(foo
=gahaverkamp)', attributes)
entries = search_result.getSearchEntries()
The actual contents of the filter don't seem to matter too much, so long as
filter is bad. The original one sent by the developer resembles the commented
line in the script above.
10 years, 10 months
(ITS#7285) Mozilla NSS: default cipher suite always selected
by tim.strobell.ctr＠nrl.navy.mil
Full_Name: Tim Strobell
Version: HEAD
OS: RHEL6
URL: ftp://ftp.openldap.org/incoming/tim-strobell-2012060401.patch
Submission from: (NULL) (2001:480:20:112:210:18ff:fe19:b000)
When using NSS, the default cipher suite selection is used even when
TLSCipherSuite is explicitly specified. This behavior was introduced in the
patch provided in ITS#6790.
At tls_m.c:2221...
if ( lt->lt_ciphersuite &&
tlsm_parse_ciphers( ctx, lt->lt_ciphersuite )) {
[ error, return ]
} else if ( tlsm_parse_ciphers( ctx, "DEFAULT" ) ) {
[ error, return ]
}
tlsm_parse_ciphers returns 0 on success; the else path is always followed and
overrides the previous cipher suite selection.
10 years, 10 months
