openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#9175) ldapsearch segfault
by lhaley＠meditech.com 21 Feb '20

21 Feb '20

--0000000000003b4d37059f1c0189 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable footnote: In my first followup, I intended to write "as I am quite UNaccustomed to working with the data" Cheers On Fri, Feb 21, 2020 at 3:27 PM Lexi Haley <lhaley(a)meditech.com> wrote: > FOUND THE ISSUE! So - in GDB , while paused in the "{mM}" processing tha= t > ber_scanf does (called from ldap_get_attribute_ber), I kept seeing the > variable arguments list not properly setting off --- and sure enough, > digging in memory, on the stack was 0x100000000 ... which was the cause = of > the eventual segfault. > > Well, backtracking to the ber_scanf call itself, I see a zero 0 which > isn't cast to the ber_len_t type, and as such, will only occupy 4 bytes a= s > a sizeof int - instead of (( on my system 8, for sizeof (ber_len_t). So = - > the solution was just to cast the argument. So that the cookie.off =3D > va_arg( ap, ber_len_t ); will unpack only bytes we've intentionally sent = it > -- not garbage left over. > > So - the change suggested is: > > > diff --git a/libraries/libldap/getattr.c b/libraries/libldap/getattr.c > index 31784d765..0300ea574 100644 > --- a/libraries/libldap/getattr.c > +++ b/libraries/libldap/getattr.c > @@ -147,7 +147,7 @@ ldap_get_attribute_ber( LDAP *ld, LDAPMessage *entry, > BerElement *ber, > > /* skip sequence, snarf attribute type */ > tag =3D ber_scanf( ber, vals ? "{mM}" : "{mx}", attr, val= s, > - &siz, 0 ); > + &siz, (ber_len_t)0 ); > if( tag =3D=3D LBER_ERROR ) { > rc =3D ld->ld_errno =3D LDAP_DECODING_ERROR; > } > > > I hope you can take this haphazard issue submit, and do whatever is right > with it - to get this patch considered. Thanks! > > > > On Fri, Feb 21, 2020 at 1:06 PM Lexi Haley <lhaley(a)meditech.com> wrote: > >> continuing notes - as I am quite accustomed to working with the data >> structures and processes for LDAP - my hacky fudge was just that - and a= lso >> useless. By bailing out at that point, ldapsearch doesn't list the >> tag=3Dvalue results. I am continuing to dig around ... >> >> Lexi >> >> On Thu, Feb 20, 2020 at 3:09 PM <openldap-its(a)openldap.org> wrote: >> >>> >>> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** >>> >>> Thanks for your report to the OpenLDAP Issue Tracking System. Your >>> report has been assigned the tracking number ITS#9175. >>> >>> One of our support engineers will look at your report in due course. >>> Note that this may take some time because our support engineers >>> are volunteers. They only work on OpenLDAP when they have spare >>> time. >>> >>> If you need to provide additional information in regards to your >>> issue report, you may do so by replying to this message. Note that >>> any mail sent to openldap-its(a)openldap.org with (ITS#9175) >>> in the subject will automatically be attached to the issue report. >>> >>> mailto:openldap-its@openldap.org?subject=3D(ITS#9175) >>> >>> You may follow the progress of this report by loading the following >>> URL in a web browser: >>> http://www.OpenLDAP.org/its/index.cgi?findid=3D9175 >>> >>> Please remember to retain your issue tracking number (ITS#9175) >>> on any further messages you send to us regarding this report. If >>> you don't then you'll just waste our time and yours because we >>> won't be able to properly track the report. >>> >>> Please note that the Issue Tracking System is not intended to >>> be used to seek help in the proper use of OpenLDAP Software. >>> Such requests will be closed. >>> >>> OpenLDAP Software is user supported. >>> http://www.OpenLDAP.org/support/ >>> >>> -------------- >>> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >>> >>> >> >> -- >> >> Lexi Haley (she/her/hers) >> >> Computer Scientist, System Tools, Advanced Technology Division >> >> Medical Information Technology, Inc. >> >> Office: 781-774-5156 | Mobile: 508-713-2499 >> >> lhaley(a)meditech.com >> >> MEDITECH Circle, Westwood, MA 02090 >> >> Main: 781-821-3000 | Fax: 781-821-2199 >> > > > -- > > Lexi Haley (she/her/hers) > > Computer Scientist, System Tools, Advanced Technology Division > > Medical Information Technology, Inc. > > Office: 781-774-5156 | Mobile: 508-713-2499 > > lhaley(a)meditech.com > > MEDITECH Circle, Westwood, MA 02090 > > Main: 781-821-3000 | Fax: 781-821-2199 > --=20 Lexi Haley (she/her/hers) Computer Scientist, System Tools, Advanced Technology Division Medical Information Technology, Inc. Office: 781-774-5156 | Mobile: 508-713-2499 lhaley(a)meditech.com MEDITECH Circle, Westwood, MA 02090 Main: 781-821-3000 | Fax: 781-821-2199 --=20 <https://ehr.meditech.com/expanse>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =20 <https://www.linkedin.com/company/meditech>=C2=A0 =20 <https://twitter.com/MEDITECH>=C2=A0=C2=A0 <https://www.facebook.com/Medite= chEHR> Subscribe=20 <https://info.meditech.com/get-great-meditech-content?hsCtaTracking=3D86429= 9ec-5abf-4004-9c6d-2d051794101f%7Cc911be42-538a-4a48-8dca-a6d4001c6326>=20 to receive emails from MEDITECH or to change email preferences. --0000000000003b4d37059f1c0189 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">footnote:=C2=A0 In my first followup, I intended to write= =C2=A0 "<span style=3D"color:rgb(0,0,0)">as I am quite UNaccustomed to= working with the data"</span><div>Cheers</div></div><br><div class=3D= "gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 21, 2020 at= 3:27 PM Lexi Haley <<a href=3D"mailto:lhaley@meditech.com">lhaley@medit= ech.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"= margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef= t:1ex"><div dir=3D"ltr">FOUND THE ISSUE!=C2=A0 So - in GDB , while paused i= n the "{mM}" processing that ber_scanf does (called from=C2=A0lda= p_get_attribute_ber), I kept seeing the variable arguments list not properl= y setting off --- and sure enough, digging in memory, on the stack was 0x10= 0000000 ...=C2=A0 which was the cause of the eventual segfault.<div><br></d= iv><div>Well, backtracking to the ber_scanf call itself, I see a zero 0 whi= ch isn't cast to the ber_len_t type, and as such, will only occupy 4 by= tes as a sizeof=C2=A0int - instead of (( on my system 8, for sizeof (ber_le= n_t).=C2=A0 So - the solution was just=C2=A0to cast the argument.=C2=A0 So = that the=C2=A0cookie.off =3D va_arg( ap, ber_len_t ); will unpack only byte= s we've intentionally sent it -- not garbage left over.</div><div><br><= /div><div>So - the change suggested is:</div><div><br></div><div><br></div>= <div><font face=3D"monospace">diff --git a/libraries/libldap/getattr.c b/li= braries/libldap/getattr.c<br>index 31784d765..0300ea574 100644<br>--- a/lib= raries/libldap/getattr.c<br>+++ b/libraries/libldap/getattr.c<br>@@ -147,7 = +147,7 @@ ldap_get_attribute_ber( LDAP *ld, LDAPMessage *entry, BerElement = *ber,<br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* ski= p sequence, snarf attribute type */<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 tag =3D ber_scanf( ber, vals ? "{mM}" : &quo= t;{mx}", attr, vals,<br>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &siz, 0 );<br>+ =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &siz, (ber_len= _t)0 );<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if( tag = =3D=3D LBER_ERROR ) {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rc =3D ld->ld_errno =3D LDAP_DECODING= _ERROR;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }</font>= <br></div><div><br></div><div><br></div><div>I hope you can take this hapha= zard issue submit, and do whatever is right with it - to get this patch con= sidered.=C2=A0 Thanks!</div><div><br></div><div><br></div></div><br><div cl= ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 21, 2= 020 at 1:06 PM Lexi Haley <<a href=3D"mailto:lhaley@meditech.com" target= =3D"_blank">lhaley(a)meditech.com</a>> wrote:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"><div dir=3D"ltr">continuing notes - as I a= m quite accustomed to working with the data structures and processes for LD= AP - my hacky fudge was just that - and also useless.=C2=A0 By bailing out = at that point, ldapsearch doesn't list the tag=3Dvalue results.=C2=A0 I= am continuing to dig around ...<div><br></div><div>Lexi</div></div><br><di= v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 2= 0, 2020 at 3:09 PM <<a href=3D"mailto:openldap-its@openldap.org" target= =3D"_blank">openldap-its(a)openldap.org</a>> wrote:<br></div><blockquote c= lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli= d rgb(204,204,204);padding-left:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#9175.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org" target=3D"_bl= ank">openldap-its(a)openldap.org</a> with (ITS#9175)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org" target=3D"_blank">openldap-its(a)openldap.org</a>?subject=3D(ITS#9175)<b= r> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D917= 5" rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c= gi?findid=3D9175</a><br> <br> Please remember to retain your issue tracking number (ITS#9175)<br> on any further messages you send to us regarding this report.=C2=A0 If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" re= l=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= ><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><p dir=3D"ltr= " style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom= :0pt"><span style=3D"font-size:13pt;font-family:Verdana;color:rgb(0,0,0);fo= nt-weight:700;vertical-align:baseline;white-space:pre-wrap">Lexi Haley </sp= an><span style=3D"color:rgb(102,102,102);font-family:Verdana;font-size:13.3= 333px;white-space:pre-wrap">(she/her/hers)</span></p><p dir=3D"ltr" style= =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,102);ver= tical-align:baseline;white-space:pre-wrap">Computer Scientist, System Tools= , Advanced Technology Division</span></p><p dir=3D"ltr" style=3D"color:rgb(= 80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"= font-size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align:ba= seline;white-space:pre-wrap">Medical Information Technology, Inc.</span></p= ><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt= ;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;color= :rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Office: 781= -774-5156 | Mobile: 508-713-2499</span></p><p style=3D"color:rgb(80,0,80);l= ine-height:1.38;margin-top:0pt;margin-bottom:0pt"><font face=3D"Verdana"><s= pan style=3D"font-size:13.3333px;white-space:pre-wrap"><a href=3D"mailto:lh= aley(a)meditech.com" target=3D"_blank">lhaley(a)meditech.com</a></span></font><= /p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0= pt;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;col= or:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">MEDITECH = Circle, Westwood, MA 02090</span></p><p dir=3D"ltr" style=3D"color:rgb(80,0= ,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font= -size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align:baseli= ne;white-space:pre-wrap">Main: 781-821-3000 | Fax: 781-821-2199</span></p><= /div></div></div></div></div></div> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= ><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><p dir=3D"ltr= " style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom= :0pt"><span style=3D"font-size:13pt;font-family:Verdana;color:rgb(0,0,0);fo= nt-weight:700;vertical-align:baseline;white-space:pre-wrap">Lexi Haley </sp= an><span style=3D"color:rgb(102,102,102);font-family:Verdana;font-size:13.3= 333px;white-space:pre-wrap">(she/her/hers)</span></p><p dir=3D"ltr" style= =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,102);ver= tical-align:baseline;white-space:pre-wrap">Computer Scientist, System Tools= , Advanced Technology Division</span></p><p dir=3D"ltr" style=3D"color:rgb(= 80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"= font-size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align:ba= seline;white-space:pre-wrap">Medical Information Technology, Inc.</span></p= ><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt= ;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;color= :rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Office: 781= -774-5156 | Mobile: 508-713-2499</span></p><p style=3D"color:rgb(80,0,80);l= ine-height:1.38;margin-top:0pt;margin-bottom:0pt"><font face=3D"Verdana"><s= pan style=3D"font-size:13.3333px;white-space:pre-wrap"><a href=3D"mailto:lh= aley(a)meditech.com" target=3D"_blank">lhaley(a)meditech.com</a></span></font><= /p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0= pt;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;col= or:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">MEDITECH = Circle, Westwood, MA 02090</span></p><p dir=3D"ltr" style=3D"color:rgb(80,0= ,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font= -size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align:baseli= ne;white-space:pre-wrap">Main: 781-821-3000 | Fax: 781-821-2199</span></p><= /div></div></div></div></div></div> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div= dir=3D"ltr"><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;ma= rgin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:13pt;font-family:V= erdana;color:rgb(0,0,0);font-weight:700;vertical-align:baseline;white-space= :pre-wrap">Lexi Haley </span><span style=3D"color:rgb(102,102,102);font-fam= ily:Verdana;font-size:13.3333px;white-space:pre-wrap">(she/her/hers)</span>= </p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:= 0pt;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;co= lor:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Computer= Scientist, System Tools, Advanced Technology Division</span></p><p dir=3D"= ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bot= tom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,10= 2,102);vertical-align:baseline;white-space:pre-wrap">Medical Information Te= chnology, Inc.</span></p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-he= ight:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:10pt;f= ont-family:Verdana;color:rgb(102,102,102);vertical-align:baseline;white-spa= ce:pre-wrap">Office: 781-774-5156 | Mobile: 508-713-2499</span></p><p style= =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= font face=3D"Verdana"><span style=3D"font-size:13.3333px;white-space:pre-wr= ap"><a href=3D"mailto:lhaley@meditech.com" target=3D"_blank">lhaley@meditec= h.com</a></span></font></p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-= height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:10pt= ;font-family:Verdana;color:rgb(102,102,102);vertical-align:baseline;white-s= pace:pre-wrap">MEDITECH Circle, Westwood, MA 02090</span></p><p dir=3D"ltr"= style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:= 0pt"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,10= 2);vertical-align:baseline;white-space:pre-wrap">Main: 781-821-3000 | Fax: = 781-821-2199</span></p></div></div></div></div></div></div> <br> <a href=3D"https://ehr.meditech.com/expanse" target=3D"_blank"><img src=3D"= https://home.meditech.com/en/d/home/images/meditechemailsignaturelogo2018ex= panse.jpg"></a><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"ht= tps://www.linkedin.com/company/meditech" target=3D"_blank"><img src=3D"http= s://home.meditech.com/en/d/home/images/emailsignaturelinkedin20pixels.gif" = style=3D"font-size:1.3em"></a><span style=3D"font-size:1.3em">=C2=A0 </span= ><a href=3D"https://twitter.com/MEDITECH" target=3D"_blank"><img src=3D"htt= ps://home.meditech.com/en/d/home/images/emailsignaturetwitter20pixels.gif" = style=3D"font-size:1.3em"></a><span style=3D"font-size:1.3em">=C2=A0=C2=A0<= /span><a href=3D"https://www.facebook.com/MeditechEHR" target=3D"_blank"><i= mg src=3D"https://home.meditech.com/en/d/home/images/emailsignaturefacebook= 20pixels.gif" style=3D"font-size:1.3em"></a></div><div><div><a href=3D"http= s://info.meditech.com/get-great-meditech-content?hsCtaTracking=3D864299ec-5= abf-4004-9c6d-2d051794101f%7Cc911be42-538a-4a48-8dca-a6d4001c6326" target= =3D"_blank"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(17,= 85,204);vertical-align:baseline;white-space:pre-wrap">Subscribe</span></a><= span style=3D"font-size:10pt;font-family:Verdana;vertical-align:baseline;wh= ite-space:pre-wrap"> </span><span style=3D"font-size:10pt;font-family:Verda= na;color:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">to = receive emails from MEDITECH or to change email preferences.</span></div></= div> --0000000000003b4d37059f1c0189--

1 0

Re: (ITS#9175) ldapsearch segfault
by lhaley＠meditech.com 21 Feb '20

21 Feb '20

--00000000000062d6a8059f1bda34 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FOUND THE ISSUE! So - in GDB , while paused in the "{mM}" processing that ber_scanf does (called from ldap_get_attribute_ber), I kept seeing the variable arguments list not properly setting off --- and sure enough, digging in memory, on the stack was 0x100000000 ... which was the cause of the eventual segfault. Well, backtracking to the ber_scanf call itself, I see a zero 0 which isn't cast to the ber_len_t type, and as such, will only occupy 4 bytes as a sizeof int - instead of (( on my system 8, for sizeof (ber_len_t). So - the solution was just to cast the argument. So that the cookie.off =3D va_arg( ap, ber_len_t ); will unpack only bytes we've intentionally sent it -- not garbage left over. So - the change suggested is: diff --git a/libraries/libldap/getattr.c b/libraries/libldap/getattr.c index 31784d765..0300ea574 100644 --- a/libraries/libldap/getattr.c +++ b/libraries/libldap/getattr.c @@ -147,7 +147,7 @@ ldap_get_attribute_ber( LDAP *ld, LDAPMessage *entry, BerElement *ber, /* skip sequence, snarf attribute type */ tag =3D ber_scanf( ber, vals ? "{mM}" : "{mx}", attr, vals, - &siz, 0 ); + &siz, (ber_len_t)0 ); if( tag =3D=3D LBER_ERROR ) { rc =3D ld->ld_errno =3D LDAP_DECODING_ERROR; } I hope you can take this haphazard issue submit, and do whatever is right with it - to get this patch considered. Thanks! On Fri, Feb 21, 2020 at 1:06 PM Lexi Haley <lhaley(a)meditech.com> wrote: > continuing notes - as I am quite accustomed to working with the data > structures and processes for LDAP - my hacky fudge was just that - and al= so > useless. By bailing out at that point, ldapsearch doesn't list the > tag=3Dvalue results. I am continuing to dig around ... > > Lexi > > On Thu, Feb 20, 2020 at 3:09 PM <openldap-its(a)openldap.org> wrote: > >> >> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** >> >> Thanks for your report to the OpenLDAP Issue Tracking System. Your >> report has been assigned the tracking number ITS#9175. >> >> One of our support engineers will look at your report in due course. >> Note that this may take some time because our support engineers >> are volunteers. They only work on OpenLDAP when they have spare >> time. >> >> If you need to provide additional information in regards to your >> issue report, you may do so by replying to this message. Note that >> any mail sent to openldap-its(a)openldap.org with (ITS#9175) >> in the subject will automatically be attached to the issue report. >> >> mailto:openldap-its@openldap.org?subject=3D(ITS#9175) >> >> You may follow the progress of this report by loading the following >> URL in a web browser: >> http://www.OpenLDAP.org/its/index.cgi?findid=3D9175 >> >> Please remember to retain your issue tracking number (ITS#9175) >> on any further messages you send to us regarding this report. If >> you don't then you'll just waste our time and yours because we >> won't be able to properly track the report. >> >> Please note that the Issue Tracking System is not intended to >> be used to seek help in the proper use of OpenLDAP Software. >> Such requests will be closed. >> >> OpenLDAP Software is user supported. >> http://www.OpenLDAP.org/support/ >> >> -------------- >> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >> >> > > -- > > Lexi Haley (she/her/hers) > > Computer Scientist, System Tools, Advanced Technology Division > > Medical Information Technology, Inc. > > Office: 781-774-5156 | Mobile: 508-713-2499 > > lhaley(a)meditech.com > > MEDITECH Circle, Westwood, MA 02090 > > Main: 781-821-3000 | Fax: 781-821-2199 > --=20 Lexi Haley (she/her/hers) Computer Scientist, System Tools, Advanced Technology Division Medical Information Technology, Inc. Office: 781-774-5156 | Mobile: 508-713-2499 lhaley(a)meditech.com MEDITECH Circle, Westwood, MA 02090 Main: 781-821-3000 | Fax: 781-821-2199 --=20 <https://ehr.meditech.com/expanse>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =20 <https://www.linkedin.com/company/meditech>=C2=A0 =20 <https://twitter.com/MEDITECH>=C2=A0=C2=A0 <https://www.facebook.com/Medite= chEHR> Subscribe=20 <https://info.meditech.com/get-great-meditech-content?hsCtaTracking=3D86429= 9ec-5abf-4004-9c6d-2d051794101f%7Cc911be42-538a-4a48-8dca-a6d4001c6326>=20 to receive emails from MEDITECH or to change email preferences. --00000000000062d6a8059f1bda34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">FOUND THE ISSUE!=C2=A0 So - in GDB , while paused in the &= quot;{mM}" processing that ber_scanf does (called from=C2=A0ldap_get_a= ttribute_ber), I kept seeing the variable arguments list not properly setti= ng off --- and sure enough, digging in memory, on the stack was 0x100000000= ...=C2=A0 which was the cause of the eventual segfault.<div><br></div><div= >Well, backtracking to the ber_scanf call itself, I see a zero 0 which isn&= #39;t cast to the ber_len_t type, and as such, will only occupy 4 bytes as = a sizeof=C2=A0int - instead of (( on my system 8, for sizeof (ber_len_t).= =C2=A0 So - the solution was just=C2=A0to cast the argument.=C2=A0 So that = the=C2=A0cookie.off =3D va_arg( ap, ber_len_t ); will unpack only bytes we&= #39;ve intentionally sent it -- not garbage left over.</div><div><br></div>= <div>So - the change suggested is:</div><div><br></div><div><br></div><div>= <font face=3D"monospace">diff --git a/libraries/libldap/getattr.c b/librari= es/libldap/getattr.c<br>index 31784d765..0300ea574 100644<br>--- a/librarie= s/libldap/getattr.c<br>+++ b/libraries/libldap/getattr.c<br>@@ -147,7 +147,= 7 @@ ldap_get_attribute_ber( LDAP *ld, LDAPMessage *entry, BerElement *ber,= <br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* skip seq= uence, snarf attribute type */<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 tag =3D ber_scanf( ber, vals ? "{mM}" : "{mx}= ", attr, vals,<br>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 &siz, 0 );<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &siz, (ber_len_t)0 );= <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if( tag =3D=3D = LBER_ERROR ) {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 rc =3D ld->ld_errno =3D LDAP_DECODING_ERROR;= <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }</font><br></d= iv><div><br></div><div><br></div><div>I hope you can take this haphazard is= sue submit, and do whatever is right with it - to get this patch considered= .=C2=A0 Thanks!</div><div><br></div><div><br></div></div><br><div class=3D"= gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 21, 2020 at = 1:06 PM Lexi Haley <<a href=3D"mailto:lhaley@meditech.com">lhaley@medite= ch.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m= argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left= :1ex"><div dir=3D"ltr">continuing notes - as I am quite accustomed to worki= ng with the data structures and processes for LDAP - my hacky fudge was jus= t that - and also useless.=C2=A0 By bailing out at that point, ldapsearch d= oesn't list the tag=3Dvalue results.=C2=A0 I am continuing to dig aroun= d ...<div><br></div><div>Lexi</div></div><br><div class=3D"gmail_quote"><di= v dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 20, 2020 at 3:09 PM <<a h= ref=3D"mailto:openldap-its@openldap.org" target=3D"_blank">openldap-its@ope= nldap.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#9175.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org" target=3D"_bl= ank">openldap-its(a)openldap.org</a> with (ITS#9175)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org" target=3D"_blank">openldap-its(a)openldap.org</a>?subject=3D(ITS#9175)<b= r> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D917= 5" rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c= gi?findid=3D9175</a><br> <br> Please remember to retain your issue tracking number (ITS#9175)<br> on any further messages you send to us regarding this report.=C2=A0 If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" re= l=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= ><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><p dir=3D"ltr= " style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom= :0pt"><span style=3D"font-size:13pt;font-family:Verdana;color:rgb(0,0,0);fo= nt-weight:700;vertical-align:baseline;white-space:pre-wrap">Lexi Haley </sp= an><span style=3D"color:rgb(102,102,102);font-family:Verdana;font-size:13.3= 333px;white-space:pre-wrap">(she/her/hers)</span></p><p dir=3D"ltr" style= =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,102);ver= tical-align:baseline;white-space:pre-wrap">Computer Scientist, System Tools= , Advanced Technology Division</span></p><p dir=3D"ltr" style=3D"color:rgb(= 80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"= font-size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align:ba= seline;white-space:pre-wrap">Medical Information Technology, Inc.</span></p= ><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt= ;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;color= :rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Office: 781= -774-5156 | Mobile: 508-713-2499</span></p><p style=3D"color:rgb(80,0,80);l= ine-height:1.38;margin-top:0pt;margin-bottom:0pt"><font face=3D"Verdana"><s= pan style=3D"font-size:13.3333px;white-space:pre-wrap"><a href=3D"mailto:lh= aley(a)meditech.com" target=3D"_blank">lhaley(a)meditech.com</a></span></font><= /p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0= pt;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;col= or:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">MEDITECH = Circle, Westwood, MA 02090</span></p><p dir=3D"ltr" style=3D"color:rgb(80,0= ,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font= -size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align:baseli= ne;white-space:pre-wrap">Main: 781-821-3000 | Fax: 781-821-2199</span></p><= /div></div></div></div></div></div> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div= dir=3D"ltr"><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;ma= rgin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:13pt;font-family:V= erdana;color:rgb(0,0,0);font-weight:700;vertical-align:baseline;white-space= :pre-wrap">Lexi Haley </span><span style=3D"color:rgb(102,102,102);font-fam= ily:Verdana;font-size:13.3333px;white-space:pre-wrap">(she/her/hers)</span>= </p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:= 0pt;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;co= lor:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Computer= Scientist, System Tools, Advanced Technology Division</span></p><p dir=3D"= ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bot= tom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,10= 2,102);vertical-align:baseline;white-space:pre-wrap">Medical Information Te= chnology, Inc.</span></p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-he= ight:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:10pt;f= ont-family:Verdana;color:rgb(102,102,102);vertical-align:baseline;white-spa= ce:pre-wrap">Office: 781-774-5156 | Mobile: 508-713-2499</span></p><p style= =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= font face=3D"Verdana"><span style=3D"font-size:13.3333px;white-space:pre-wr= ap"><a href=3D"mailto:lhaley@meditech.com" target=3D"_blank">lhaley@meditec= h.com</a></span></font></p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-= height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:10pt= ;font-family:Verdana;color:rgb(102,102,102);vertical-align:baseline;white-s= pace:pre-wrap">MEDITECH Circle, Westwood, MA 02090</span></p><p dir=3D"ltr"= style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:= 0pt"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,10= 2);vertical-align:baseline;white-space:pre-wrap">Main: 781-821-3000 | Fax: = 781-821-2199</span></p></div></div></div></div></div></div> <br> <a href=3D"https://ehr.meditech.com/expanse" target=3D"_blank"><img src=3D"= https://home.meditech.com/en/d/home/images/meditechemailsignaturelogo2018ex= panse.jpg"></a><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"ht= tps://www.linkedin.com/company/meditech" target=3D"_blank"><img src=3D"http= s://home.meditech.com/en/d/home/images/emailsignaturelinkedin20pixels.gif" = style=3D"font-size:1.3em"></a><span style=3D"font-size:1.3em">=C2=A0 </span= ><a href=3D"https://twitter.com/MEDITECH" target=3D"_blank"><img src=3D"htt= ps://home.meditech.com/en/d/home/images/emailsignaturetwitter20pixels.gif" = style=3D"font-size:1.3em"></a><span style=3D"font-size:1.3em">=C2=A0=C2=A0<= /span><a href=3D"https://www.facebook.com/MeditechEHR" target=3D"_blank"><i= mg src=3D"https://home.meditech.com/en/d/home/images/emailsignaturefacebook= 20pixels.gif" style=3D"font-size:1.3em"></a></div><div><div><a href=3D"http= s://info.meditech.com/get-great-meditech-content?hsCtaTracking=3D864299ec-5= abf-4004-9c6d-2d051794101f%7Cc911be42-538a-4a48-8dca-a6d4001c6326" target= =3D"_blank"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(17,= 85,204);vertical-align:baseline;white-space:pre-wrap">Subscribe</span></a><= span style=3D"font-size:10pt;font-family:Verdana;vertical-align:baseline;wh= ite-space:pre-wrap"> </span><span style=3D"font-size:10pt;font-family:Verda= na;color:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">to = receive emails from MEDITECH or to change email preferences.</span></div></= div> --00000000000062d6a8059f1bda34--

1 0

Re: (ITS#9175) ldapsearch segfault
by lhaley＠meditech.com 21 Feb '20

21 Feb '20

--000000000000ecfe33059f19e40d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable continuing notes - as I am quite accustomed to working with the data structures and processes for LDAP - my hacky fudge was just that - and also useless. By bailing out at that point, ldapsearch doesn't list the tag=3Dvalue results. I am continuing to dig around ... Lexi On Thu, Feb 20, 2020 at 3:09 PM <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#9175. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#9175) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=3D(ITS#9175) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=3D9175 > > Please remember to retain your issue tracking number (ITS#9175) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --=20 Lexi Haley (she/her/hers) Computer Scientist, System Tools, Advanced Technology Division Medical Information Technology, Inc. Office: 781-774-5156 | Mobile: 508-713-2499 lhaley(a)meditech.com MEDITECH Circle, Westwood, MA 02090 Main: 781-821-3000 | Fax: 781-821-2199 --=20 <https://ehr.meditech.com/expanse>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =20 <https://www.linkedin.com/company/meditech>=C2=A0 =20 <https://twitter.com/MEDITECH>=C2=A0=C2=A0 <https://www.facebook.com/Medite= chEHR> Subscribe=20 <https://info.meditech.com/get-great-meditech-content?hsCtaTracking=3D86429= 9ec-5abf-4004-9c6d-2d051794101f%7Cc911be42-538a-4a48-8dca-a6d4001c6326>=20 to receive emails from MEDITECH or to change email preferences. --000000000000ecfe33059f19e40d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">continuing notes - as I am quite accustomed to working wit= h the data structures and processes for LDAP - my hacky fudge was just that= - and also useless.=C2=A0 By bailing out at that point, ldapsearch doesn&#= 39;t list the tag=3Dvalue results.=C2=A0 I am continuing to dig around ...<= div><br></div><div>Lexi</div></div><br><div class=3D"gmail_quote"><div dir= =3D"ltr" class=3D"gmail_attr">On Thu, Feb 20, 2020 at 3:09 PM <<a href= =3D"mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a>> wro= te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#9175.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org" target=3D"_bl= ank">openldap-its(a)openldap.org</a> with (ITS#9175)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org" target=3D"_blank">openldap-its(a)openldap.org</a>?subject=3D(ITS#9175)<b= r> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D917= 5" rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c= gi?findid=3D9175</a><br> <br> Please remember to retain your issue tracking number (ITS#9175)<br> on any further messages you send to us regarding this report.=C2=A0 If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" re= l=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div= dir=3D"ltr"><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;ma= rgin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:13pt;font-family:V= erdana;color:rgb(0,0,0);font-weight:700;vertical-align:baseline;white-space= :pre-wrap">Lexi Haley </span><span style=3D"color:rgb(102,102,102);font-fam= ily:Verdana;font-size:13.3333px;white-space:pre-wrap">(she/her/hers)</span>= </p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:= 0pt;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;co= lor:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Computer= Scientist, System Tools, Advanced Technology Division</span></p><p dir=3D"= ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bot= tom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,10= 2,102);vertical-align:baseline;white-space:pre-wrap">Medical Information Te= chnology, Inc.</span></p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-he= ight:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:10pt;f= ont-family:Verdana;color:rgb(102,102,102);vertical-align:baseline;white-spa= ce:pre-wrap">Office: 781-774-5156 | Mobile: 508-713-2499</span></p><p style= =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= font face=3D"Verdana"><span style=3D"font-size:13.3333px;white-space:pre-wr= ap"><a href=3D"mailto:lhaley@meditech.com" target=3D"_blank">lhaley@meditec= h.com</a></span></font></p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-= height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:10pt= ;font-family:Verdana;color:rgb(102,102,102);vertical-align:baseline;white-s= pace:pre-wrap">MEDITECH Circle, Westwood, MA 02090</span></p><p dir=3D"ltr"= style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:= 0pt"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,10= 2);vertical-align:baseline;white-space:pre-wrap">Main: 781-821-3000 | Fax: = 781-821-2199</span></p></div></div></div></div></div></div> <br> <a href=3D"https://ehr.meditech.com/expanse" target=3D"_blank"><img src=3D"= https://home.meditech.com/en/d/home/images/meditechemailsignaturelogo2018ex= panse.jpg"></a><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"ht= tps://www.linkedin.com/company/meditech" target=3D"_blank"><img src=3D"http= s://home.meditech.com/en/d/home/images/emailsignaturelinkedin20pixels.gif" = style=3D"font-size:1.3em"></a><span style=3D"font-size:1.3em">=C2=A0 </span= ><a href=3D"https://twitter.com/MEDITECH" target=3D"_blank"><img src=3D"htt= ps://home.meditech.com/en/d/home/images/emailsignaturetwitter20pixels.gif" = style=3D"font-size:1.3em"></a><span style=3D"font-size:1.3em">=C2=A0=C2=A0<= /span><a href=3D"https://www.facebook.com/MeditechEHR" target=3D"_blank"><i= mg src=3D"https://home.meditech.com/en/d/home/images/emailsignaturefacebook= 20pixels.gif" style=3D"font-size:1.3em"></a></div><div><div><a href=3D"http= s://info.meditech.com/get-great-meditech-content?hsCtaTracking=3D864299ec-5= abf-4004-9c6d-2d051794101f%7Cc911be42-538a-4a48-8dca-a6d4001c6326" target= =3D"_blank"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(17,= 85,204);vertical-align:baseline;white-space:pre-wrap">Subscribe</span></a><= span style=3D"font-size:10pt;font-family:Verdana;vertical-align:baseline;wh= ite-space:pre-wrap"> </span><span style=3D"font-size:10pt;font-family:Verda= na;color:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">to = receive emails from MEDITECH or to change email preferences.</span></div></= div> --000000000000ecfe33059f19e40d--

1 0

Re: (ITS#9171) slapd with ppolicy and pwdAccountLockedTime crashes
by ondra＠mistotebe.net 21 Feb '20

21 Feb '20

On Mon, Feb 17, 2020 at 02:17:32PM +0000, tokos(a)ipp.cas.cz wrote: > Hi Ondrej, > > I uploaded my configuration here(ftp.openldap.org/incoming) : Hi Stanislav, thanks for the information, I have been able to reproduce the issue and pushed a fix to master (commit 140b676bc1bd786f9fd1e7b047981e84b57cb354). Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

RE: Re: (ITS#9017) Improving performance of commit sync in Windows
by kriszyp＠gmail.com 20 Feb '20

20 Feb '20

1 0

Re: (ITS#9017) Improving performance of commit sync in Windows
by hyc＠symas.com 20 Feb '20

20 Feb '20

Howard Chu wrote: > There should be an off64_t type instead. > But it looks to me like only the env->me_size field could ever overflow, > and using size_t for that should be fine. The other uses are for the meta page, which is always either offset 0 or > offset 4096 (with 4KB pagesize), and the lockfile, which is always smaller than 2GB. Ignore that, I was looking at the 0.9 branch when I wrote that. -- -- 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#9017) Improving performance of commit sync in Windows
by hyc＠symas.com 20 Feb '20

20 Feb '20

kriszyp(a)gmail.com wrote: > However, in trying to test the mdb.master branch code with our application/server (we were previously using the 0.9 branch), there was a regression causing it > to crash pretty much any time we attempted to write to a db that was larger than 2GB. After some considerable testing and investigation (which is why it took a > while to get this finished), it seems the cause is the use of the off_t type for file pointer/positions, which appears to be a 32-bit signed integer compiling > on Windows. This overflows for dbs over 2GB and causes references that crash the process. Replacing all the off_t types with size_t (unsigned 64-bit), fixed > this issue. I am not sure if this is the right replacement type. I think this could also be addressed with compiler option for changing the file offset type > size, but that seems like a hazardous hoop to jump through. But the third commit, replacing the off_t with size_t definitely fixed the problem in our application. There should be an off64_t type instead. But it looks to me like only the env->me_size field could ever overflow, and using size_t for that should be fine. The other uses are for the meta page, which is always either offset 0 or offset 4096 (with 4KB pagesize), and the lockfile, which is always smaller than 2GB. > > https://github.com/LMDB/lmdb/commit/45cf4b6ede38565cfab1c40d0d77961a0cb22b9… -- -- 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: RE: Re: (ITS#9017) Improving performance of commit sync in Windows
by kriszyp＠gmail.com 20 Feb '20

20 Feb '20

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta ht= tp-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta name= =3DGenerator content=3D"Microsoft Word 15 (filtered medium)"><style></style></head><body lang=3DEN-CA link=3Dblue vlink=3D"#954F72"><div cla= ss=3DWordSection1><p class=3DMsoNormal>Here is a pull request for these win= dows upgrades (I know it won=E2=80=99t be applied directly in GitHub, but s= eems a convenient host for the patches):</p><p class=3DMsoNormal><a href=3D= "https://github.com/LMDB/lmdb/pull/18"><span style=3D'color:#954F72'>https:= //github.com/LMDB/lmdb/pull/18</span></a><o:p></o:p></p><p class=3DMsoNorma= l><o:p> </o:p></p><p class=3DMsoNormal>The first commit is basically t= he changes mentioned in this thread for improving sync performance by using= write-through writes instead FlushFileBuffers/FlushViewOfFile, reapplied t= o the mdb.master branch, with conflicts resolved.</p><p class=3DMsoNormal><= a href=3D"https://github.com/LMDB/lmdb/commit/204d1710d7a34eff142f2654d7678= 182e1b9e054.patch"><span style=3D'color:#954F72'>https://github.com/LMDB/lm= db/commit/204d1710d7a34eff142f2654d7678182e1b9e054.patch</span></a></p><p c= lass=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>The second commi= t adds support for an option for opening map files by providing the mapsize= as the file size (MaximumSize) to NtCreateSection (which also improves per= formance and prevents freezing caused by file growth). I implemented this a= s a compiler preprocessor define, as requested. However, I would note that = I would still prefer this to be a runtime option. When bundling LMDB in a n= ode package, there is no way to parameterize the compiler options (that I k= now of) for distribution, and it would be nice to have this an option for d= ifferent users of the node package.</p><p class=3DMsoNormal><a href=3D"http= s://github.com/LMDB/lmdb/commit/6f94bb1da1812c1ddb68e33448c9cd381674b02d.pa= tch"><span style=3D'color:#954F72'>https://github.com/LMDB/lmdb/commit/6f94= bb1da1812c1ddb68e33448c9cd381674b02d.patch</span></a></p><p class=3DMsoNorm= al><o:p> </o:p></p><p class=3DMsoNormal>However, in trying to test the= mdb.master branch code with our application/server (we were previously usi= ng the 0.9 branch), there was a regression causing it to crash pretty much = any time we attempted to write to a db that was larger than 2GB. After some= considerable testing and investigation (which is why it took a while to ge= t this finished), it seems the cause is the use of the off_t type for file = pointer/positions, which appears to be a 32-bit signed integer compiling on= Windows. This overflows for dbs over 2GB and causes references that crash = the process. Replacing all the off_t types with size_t (unsigned 64-bit), f= ixed this issue. I am not sure if this is the right replacement type. I thi= nk this could also be addressed with compiler option for changing the file = offset type size, but that seems like a hazardous hoop to jump through. But= the third commit, replacing the off_t with size_t definitely fixed the pro= blem in our application.</p><p class=3DMsoNormal><a href=3D"https://github.= com/LMDB/lmdb/commit/45cf4b6ede38565cfab1c40d0d77961a0cb22b9e.patch"><span = style=3D'color:#954F72'>https://github.com/LMDB/lmdb/commit/45cf4b6ede38565= cfab1c40d0d77961a0cb22b9e.patch</span></a></p><p class=3DMsoNormal><o:p>&nb= sp;</o:p></p><p class=3DMsoNormal>With these three commits we are seeing so= lid stability and performance on Windows with the master branch. Thanks for= considering this!</p><p class=3DMsoNormal><o:p> </o:p></p><p class=3D= MsoNormal>Thanks,<br>Kris</p><p class=3DMsoNormal><o:p> </o:p></p><div= style=3D'mso-element:para-border-div;border:none;border-top:solid #E1E1E1 = 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal style=3D'border:none;= padding:0cm'><b>From: </b><a href=3D"mailto:kriszyp@gmail.com">kriszyp@gmai= l.com</a><br><b>Sent: </b>February 18, 2020 1:06 PM<br><b>To: </b><a href= =3D"mailto:hyc@symas.com">Howard Chu</a><br><b>Cc: </b><a href=3D"mailto:op= enldap-its(a)openldap.org">openldap-its(a)OpenLDAP.org</a><br><b>Subject: </b>R= E: Re: (ITS#9017) Improving performance of commit sync in Windows</p></div>= <p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Looking into= the APIs, I would guess that CreateFileMapping=E2=80=99s dwMaximumSizeHigh= and dwMaximumSizeLow arguments are mapped to NtCreateSection=E2=80=99s Max= imumSize argument (4<sup>th</sup> argument). In LMDB=E2=80=99s 0.9 CreateFi= leMapping call, the size is provided (since it is required), whereas NtCrea= teSection has MaximumSize as optional, and in LMDB (mdb.master), it is not = provided. Passing the size in (with MaximumSize argument) to NtCreateSectio= n seems to result in the same behavior as CreateFileMapping of preallocatin= g a file size equivalent to the max/mapping size, rather than dynamically g= rowing.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3D= MsoNormal>It is challenging to readily test for the performance issues; it = took a fair bit of effort and load testing to trigger the long-duration per= formance/freezing issues we had seen before on Azure. However, in some more= isolated tests, providing a MaximumSize to NtCreateSection does seem to pe= rform better than leaving it unspecified (specifically the system CPU usage= seems to about be about twice as much with dynamic growth than fixed file = size), and the performance seems about the same as CreateFileMapping. And I= think we both had suspected that it was likely due to the overhead or inef= ficiencies in how Windows was dynamically growing the (size of the) mapped = file, and having Windows used a predefined fixed file size, whether through= NtCreateSection or CreateFileMapping, probably would prevent these slowdow= n issues.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class= =3DMsoNormal>But, whether we use NtCreateSection or CreateFileMapping, we a= re still faced with the same trade-off of whether to use dynamic Windows-co= ntrolled file growth (convenient since the map size can be set arbitrarily = large), or using pre-specified file size (to avoid the slowing/freezing tha= t seems to sometimes result from dynamic Windows growth). So I assume it wo= uld still be reasonable to offer a compile time option, so users could opt-= in to using a fixed file size (provide the MaximumSize to NtCreateSection)?= Fortunately this would be a trivial addition, just a few lines of code to = use the preprocessor switch to supply this argument.<o:p></o:p></p><p class= =3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><a href=3D"http://un= documented.ntinternals.net/index.html?page=3DUserMode%2FUndocumented%20Func= tions%2FNT%20Objects%2FSection%2FNtMapViewOfSection.html">http://undocument= ed.ntinternals.net/index.html?page=3DUserMode%2FUndocumented%20Functions%2F= NT%20Objects%2FSection%2FNtMapViewOfSection.html</a><o:p></o:p></p><p class= =3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Thanks,<br>Kris<o:p>= </o:p></p><p class=3DMsoNormal><o:p> </o:p></p><div style=3D'border:no= ne;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMso= Normal><b>From: </b><a href=3D"mailto:hyc@symas.com">Howard Chu</a><br><b>S= ent: </b>February 18, 2020 8:15 AM<br><b>To: </b><a href=3D"mailto:kriszyp@= gmail.com">Kris Zyp</a><br><b>Cc: </b><a href=3D"mailto:openldap-its@openld= ap.org">openldap-its(a)OpenLDAP.org</a><br><b>Subject: </b>Re: (ITS#9017) Imp= roving performance of commit sync in Windows<o:p></o:p></p></div><p class= =3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Kris Zyp wrote:<o:p>= </o:p></p><p class=3DMsoNormal>> Yes, I will work on upgrading this patc= h to 1.0.<o:p></o:p></p><p class=3DMsoNormal>> <o:p></o:p></p><p class= =3DMsoNormal>> However, I believe in order to realize optimal Windows pe= rformance without regression/slow-downs, I will also need to disable the us= e of NTDLL (and use direct<o:p></o:p></p><p class=3DMsoNormal>> CreateFi= leMapping memory maps instead), as mentioned  http://www.openldap.org/= lists/openldap-bugs/201902/msg00009.html. You had mentioned in that thread = that<o:p></o:p></p><p class=3DMsoNormal>> the NTDLL code wasn't destined= for release, is that still the case (it is still in the mdb.master branch)= ? If you are intending to release (1.0) with the<o:p></o:p></p><p class=3DM= soNormal>> NTDLL-based memory maps (which is understandable, can certain= ly be an easier path for Windows users getting started), I will also need t= o add the compiler<o:p></o:p></p><p class=3DMsoNormal>> option to disabl= e it. Anyway, I will work on creating a PR with both these patches.<o:p></o= :p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Might= be interesting to investigate why the behavior with NTDLL is so much slowe= r on Azure. Since<o:p></o:p></p><p class=3DMsoNormal>the Win32 APIs are imp= lemented on top of the NT APIs, you would expect them to perform identicall= y.<o:p></o:p></p><p class=3DMsoNormal>Perhaps there's some additional flag = that the Win32 API is passing to NT that is needed on Azure.<o:p></o:p></p>= <p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>> <o:p></= o:p></p><p class=3DMsoNormal>> Thanks,<o:p></o:p></p><p class=3DMsoNorma= l>> Kris<o:p></o:p></p><p class=3DMsoNormal>> <o:p></o:p></p><p class= =3DMsoNormal>> On Mon, Feb 17, 2020 at 8:14 AM Howard Chu <hyc(a)symas.= com <mailto:hyc@symas.com>> wrote:<o:p></o:p></p><p class=3DMsoNor= mal>> <o:p></o:p></p><p class=3DMsoNormal>>     K= ris Zyp wrote:<o:p></o:p></p><p class=3DMsoNormal>>   &nb= sp; > Sorry to keep pestering, but just pinging about this patch again, = as I still think this fix could benefit windows users. And at this point, I= think I can<o:p></o:p></p><p class=3DMsoNormal>>   &nbsp= ; say we<o:p></o:p></p><p class=3DMsoNormal>>     &g= t; have tested it pretty well, running on our servers for almost a year :).= <o:p></o:p></p><p class=3DMsoNormal>> <o:p></o:p></p><p class=3DMsoNorma= l>>     Looks like this patch is against the 0.9 rel= ease branch. I hit a bunch of conflicts<o:p></o:p></p><p class=3DMsoNormal>= >     trying to apply it to mdb.master. We'll be sto= pping work on 0.9 soon, and getting<o:p></o:p></p><p class=3DMsoNormal>>=      LMDB 1.0 out the door finally, so can you please v= erify that your changes will work<o:p></o:p></p><p class=3DMsoNormal>>&n= bsp;    on mdb.master as well?<o:p></o:p></p><p class=3DMsoN= ormal>> <o:p></o:p></p><p class=3DMsoNormal>>    = > Thanks,<o:p></o:p></p><p class=3DMsoNormal>>   &nbs= p; > Kris<o:p></o:p></p><p class=3DMsoNormal>>   &nbsp= ; ><o:p></o:p></p><p class=3DMsoNormal>>     >= On Wed, Sep 18, 2019 at 12:56 PM Kris Zyp <kriszyp(a)gmail.com <mailto= :kriszyp@gmail.com> <mailto:kriszyp@gmail.com <mailto:kriszyp@gmai= l.com>>> wrote:<o:p></o:p></p><p class=3DMsoNormal>> &nbsp= ;   ><o:p></o:p></p><p class=3DMsoNormal>>  &nbsp= ;  >     Checking on this again, is this still a pos= sibility for merging into LMDB? This fix is still working great (improved p= erformance) on our systems.<o:p></o:p></p><p class=3DMsoNormal>> &n= bsp;   >     Thanks,<o:p></o:p></p><p class=3DM= soNormal>>     >     Kris<o:p></o:= p></p><p class=3DMsoNormal>>     ><o:p></o:p></p>= <p class=3DMsoNormal>>     >     O= n Mon, Jun 17, 2019 at 1:04 PM Kris Zyp <kriszyp(a)gmail.com <mailto:kr= iszyp(a)gmail.com> <mailto:kriszyp@gmail.com <mailto:kriszyp@gmail.c= om>>> wrote:<o:p></o:p></p><p class=3DMsoNormal>>  &n= bsp;  ><o:p></o:p></p><p class=3DMsoNormal>>   &n= bsp; >         Is this still being considered/r= eviewed? Let me know if there are any other changes you would like me to ma= ke. This patch has continued to yield<o:p></o:p></p><p class=3DMsoNormal>&g= t;     >         significan= t and reliable performance improvements for us, and seems like it would be = nice for this to be available for other Windows users.<o:p></o:p></p><p cla= ss=3DMsoNormal>>     ><o:p></o:p></p><p class=3DM= soNormal>>     >        &nbsp= ;On Fri, May 3, 2019 at 3:52 PM Kris Zyp <kriszyp(a)gmail.com <mailto:k= riszyp(a)gmail.com> <mailto:kriszyp@gmail.com <mailto:kriszyp@gmail.= com>>> wrote:<o:p></o:p></p><p class=3DMsoNormal>>  &= nbsp;  ><o:p></o:p></p><p class=3DMsoNormal>>   &= nbsp; >             For the sake of p= utting this in the email thread (other code discussion in GitHub), here is = the latest squashed commit of the proposed patch (with<o:p></o:p></p><p cla= ss=3DMsoNormal>>     >       =      the on-demand, retained overlapped array to reduce re-= malloc and opening event handles):<o:p></o:p></p><p class=3DMsoNormal>>&= nbsp;    >            &nbsp= ;https://github.com/kriszyp/node-lmdb/commit/726a9156662c703bf3d453aab75ee2= 22072b990f<o:p></o:p></p><p class=3DMsoNormal>>     = ><o:p></o:p></p><p class=3DMsoNormal>> <o:p></o:p></p><p class=3DMsoN= ormal>> <o:p></o:p></p><p class=3DMsoNormal>>    = -- <o:p></o:p></p><p class=3DMsoNormal>>      = -- Howard Chu<o:p></o:p></p><p class=3DMsoNormal>>   &nb= sp;   CTO, Symas Corp.           http://= www.symas.com<o:p></o:p></p><p class=3DMsoNormal>>   &nbs= p;   Director, Highland Sun     http://highlandsun.com/= hyc/<o:p></o:p></p><p class=3DMsoNormal>>      = Chief Architect, OpenLDAP  http://www.openldap.org/project/<o:p></o:p= ></p><p class=3DMsoNormal>> <o:p></o:p></p><p class=3DMsoNormal><o:p>&nb= sp;</o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal= >-- <o:p></o:p></p><p class=3DMsoNormal>  -- Howard Chu<o:p></o:p= ></p><p class=3DMsoNormal>  CTO, Symas Corp.    &n= bsp;      http://www.symas.com<o:p></o:p></p><p cl= ass=3DMsoNormal>  Director, Highland Sun     http:= //highlandsun.com/hyc/<o:p></o:p></p><p class=3DMsoNormal>  Chief Arch= itect, OpenLDAP  http://www.openldap.org/project/<o:p></o:p></p><p cla= ss=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><o:p> </o:p><= /p></div></body></html>=

1 0

(ITS#9176) libldap support for TLSv1.3 Encrypted SNI
by ryan＠openldap.org 20 Feb '20

20 Feb '20

Full_Name: Ryan Tandy Version: master OS: Debian URL: Submission from: (NULL) (70.66.128.207) Submitted by: ryan ldap.google.com requires clients to support SNI and sends back an intentionally invalid certificate if it is not used. Affects libldap with both OpenSSL and GnuTLS. (Might want a separate ITS for each fix.) With OpenSSL: $ ./clients/tools/ldapsearch -H ldaps://ldap.google.com -x -d1 ldap_url_parse_ext(ldaps://ldap.google.com) ldap_create ldap_url_parse_ext(ldaps://ldap.google.com:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ldap.google.com:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 216.239.32.58:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS read server hello TLS trace: SSL_connect:TLSv1.3 read encrypted extensions TLS trace: SSL_connect:SSLv3/TLS read server certificate request TLS certificate verification: depth: 0, err: 18, subject: /OU=No SNI provided; please fix your client./CN=invalid2.invalid, issuer: /OU=No SNI provided; please fix your client./CN=invalid2.invalid TLS certificate verification: Error, self signed certificate TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in error TLS: can't connect: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) With GnuTLS: $ ./clients/tools/ldapsearch -H ldaps://ldap.google.com -x -d1 ldap_url_parse_ext(ldaps://ldap.google.com) ldap_create ldap_url_parse_ext(ldaps://ldap.google.com:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ldap.google.com:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 216.239.32.58:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS: peer cert untrusted or revoked (0x42) TLS: can't connect: (unknown error code). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) When the client does not support SNI, this server sends back a dummy certificate: OU = "No SNI provided; please fix your client.", CN = invalid2.invalid which obviously does not validate. The same behaviour can be seen with "openssl s_client -noservername" or "gnutls-cli --disable-sni". For GnuTLS, we have to call gnutls_server_name_set(3) to enable SNI. The documentation notes that it should only be called with a DNS name, not with an IP address. I guess there's a corresponding call for OpenSSL. With GnuTLS, users can work around it for the short term by disabling TLSv1.3 via priority string, i.e.: LDAPTLS_CIPHER_SUITE='NORMAL:!VERS-TLS1.3' ./clients/tools/ldapsearch -H ldaps://ldap.google.com -x Not sure if the same can be done with OpenSSL.

1 0

(ITS#9175) ldapsearch segfault
by lhaley＠meditech.com 20 Feb '20

20 Feb '20

Full_Name: Lexi Haley Version: 02/20/2020 trunk commit 299fb490a27e7b0e5a60464e33f5ea04d00f0f7c OS: CYGWIN on Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.206.3.188) Using clients/tools/ldapsearch to interact with my company's active directory, and I receive a segfault, in libraries/liblbver/decode.c . the 'gist' of the command I executed was: ldapsearch.exe -h companyADserver -b cn=users,dc=company,dc=com -s sub '(cn=z*)' cn the gdb backtrace is (omitting all the (arg=val) items for brevity: #0 ber_get_stringbvl (...) at decode.c:445 #1 0x0000000100435781 in ber_scanf (...) at decode.c:820 #2 0x000000010041a605 in ldap_get_attribute_ber (...) at getattr.c:149 #3 0x0000000100401d93 in print_entry (...) at ldapsearch.c:1758 #5 0x000000010043bfd7 in main (...) at ldapsearch.c:1510 and digging around - here is what I see going on. in decode.c, during the ber_get_stringbvl function, the passed in b (aka cookie from caller), has the following values: {choice = BvOff, option = 0, siz = 1, off = 4294967296, result = 0x800055410} notice that off is 0x100000000 - a likely ridiculous (and thus a possible MAGIC) value. examining in ber_scanf, looking at the memory for the va_args - i.e. examining ap - I see (sure enough) 0x100000000... As a hacky temporary workaround - I added to my ber_get_stringbvl , before even pulling the tag: } res; + if (b->off == 0x100000000) + return LBER_DEFAULT; tag = ber_skip_tag( ber, &bv.bv_len ); I did try rewinding my source back to OPENLDAP_REL_ENG_2_4_40 (2014) and then to OPENLDAP_REL_ENG_2_4_30 (2012) - and both compilations still yielded the segfault error I described above. I'm afraid I do not know much about ldap or active directory - so I easily might be omitting something relevant, and/or completely missing the mark in different ways. Feel free to ask me for more information, and/or suggest what I might try out. Thanks, Lexi

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs