openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#5010) broken ber_encode_oid/ber_decode_oid()
by h.b.furuseth＠usit.uio.no 11 Jun '07

11 Jun '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: http://folk.uio.no/hbf/OpenLDAP/oid-encdec.txt Submission from: (NULL) (129.240.202.105) Submitted by: hallvard The 40*X+Y rule for first 2 components is decoded wrong, it should be X = val < 80 ? val/40 : 2 # X = 0, 1 or 2 Y = val - 40*X # Y is unlimited when X==2, <40 otherwise See X.690 8.19.4: ... (X*40) + Y: NOTE - This packing of the first two object identifier components recognizes that only three values are allocated from the root node, and at most 39 subsequent values from nodes reached by X = 0 and X = 1. 40*X+Y can take more than one octet. The functions allow buffer overruns. ber_decode_oid() if the oid has many small components. ber_encode_oid() for negative input (which becomes a large ulong), or if sizeof(long) == 8. The latter can just as easily be avoided by producing the bytes backwards and then reversing. They do not check much for invalid input or too large values. Possibly they ought to be a bit paranoid about that since they are used for certificates, I don't know. E.g. check that the BER encoding has "fewest possible octets" (X.690 8.19.2), i.e. no initial 0x80 in subidentifiers. ber_encode_oid() seems a bit strange about which errors it accepts and which ones it rejects. E.g. garbage after first 2 components is OK. The "assert(foo != NULL)"s are after "der = foo->bv_val":-) I enclose untested new versions. Will test and commit when I have time if someone says OK, but it depends e.g. on how paranoid the routines should or should not be. Or if they should trust the ber values to end with \0, for that matter. Finally, libldap/tls.c does not check if ber_decode_oid() fails.

1 0

Re: (ITS#5009) ldapsearch -C not in manpage
by dustin＠puryear-it.com 11 Jun '07

11 Jun '07

Thinking about this further, it looks like the manpage is really deferring to 'ldapsearch --help' since that is where the meat of the documentation is. There is some potential confusion here I think. What if the manpage just refers the reader to 'ldapsearch --help' for complete information? -- Puryear Information Technology, LLC Baton Rouge, LA * 225-706-8414 http://www.puryear-it.com Author: "Best Practices for Managing Linux and UNIX Servers" "Spam Fighting and Email Security in the 21st Century" Download your free copies: http://www.puryear-it.com/pubs/ebooks/

1 0

Re: (ITS#5009) ldapsearch -C not in manpage
by dustin＠puryear-it.com 11 Jun '07

11 Jun '07

By the way, I did verify that -C does work. It simply isn't in the manpage. Also, a quick grep of the binary: [root@samba openldap]# strings /usr/bin/ldapsearch | grep -- -C -C chase referrals (anonymously) This is a low priority documentation bug only. The binary works fine. -- Puryear Information Technology, LLC Baton Rouge, LA * 225-706-8414 http://www.puryear-it.com Author: "Best Practices for Managing Linux and UNIX Servers" "Spam Fighting and Email Security in the 21st Century" Download your free copies: http://www.puryear-it.com/pubs/ebooks/

1 0

(ITS#5009) ldapsearch -C not in manpage
by dustin＠puryear-it.com 11 Jun '07

11 Jun '07

Full_Name: Dustin Puryear Version: 2.213-7 OS: CentOS 4.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.242.176.166) The -C flag is not in the ldapsearch manpage. # rpm -q -a | grep openldap openldap-2.2.13-7.4E openldap-devel-2.2.13-7.4E openldap-servers-2.2.13-7.4E openldap-clients-2.2.13-7.4E # # man ldapsearch | grep -- -C # Alias info is there: # man ldapsearch | grep -- -a [-s base|one|sub] [-a never|always|search|find] [-l timelimit] ldapsearch is a shell-accessible interface to the ldap_search(3) -a never|always|search|find audio:< file:///tmp/ldapsearch-audio-a19924 jpegPhoto:< file:///tmp/ldapsearch-jpegPhoto-a19924 # # man ldapsearch | tail The OpenLDAP Project <http://www.openldap.org/> ACKNOWLEDGEMENTS OpenLDAP is developed and maintained by The OpenLDAP Project (http://www.openldap.org/). OpenLDAP is derived from University of Michigan LDAP 3.3 Release. OpenLDAP 2.2.13 2004/06/10 LDAPSEARCH(1) # # cat /etc/redhat-release CentOS release 4.3 (Final) #

1 0

Re: (ITS#5005) test017 fails
by ando＠sys-net.it 11 Jun '07

11 Jun '07

dieter(a)dkluenter.de wrote: > the patch fails, this is the patch reject file: That's probably because you cut'n'pasted from the email, where the tabs were probably replaced by whitespaces. I'll apply that fix if anyone confirms that cookie is legal at all. Cheers, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5005) test017 fails
by dieter＠dkluenter.de 10 Jun '07

10 Jun '07

Quanah Gibson-Mount <quanah(a)zimbra.com> writes: > --On June 8, 2007 6:43:50 PM +0000 dieter(a)dkluenter.de wrote: > >> Full_Name: Dieter Kluenter >> Version: HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.142.196.121) >> >> >> here the output of test017 logfiles >> >> ---slapd.1.log---------------- >> ber_scanf fmt (}) ber: >> <= get_ctrls: n=1 rc=2 err="Sync control : cookie parsing error" >> send_ldap_result: conn=7 op=1 p=3 >> send_ldap_result: err=2 matched="" text="Sync control : cookie parsing >> error" send_ldap_response: msgid=2 tag=101 err=2 > > Hm, is this possibly related to the fix for ITS#4977? If you revert > that checkin for syncprov.c today, does the test pass? > > > <http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/syncprov.c.…> Unfortunately no chance, still the same error. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#5005) test017 fails
by dieter＠dkluenter.de 10 Jun '07

10 Jun '07

Pierangelo Masarati <ando(a)sys-net.it> writes: > dieter(a)dkluenter.de wrote: > > The problem is in slap_parse_sync_cookie(); when no cookie is passed, a > string containing "rid=001" is parsed. The parser expects it to end > with a comma. If passing "rid=001" is correct, the fix is trivial: > instead of checking for (*next != ','), check for (*next && *next != ','). > > Index: servers/slapd/ldapsync.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/ldapsync.c,v > retrieving revision 1.42 > diff -u -r1.42 ldapsync.c > --- servers/slapd/ldapsync.c 18 May 2007 12:46:52 -0000 1.42 > +++ servers/slapd/ldapsync.c 9 Jun 2007 09:42:24 -0000 > @@ -180,7 +180,10 @@ > if ( !strncmp( next, "rid=", STRLENOF("rid=") )) { > rid_ptr = next; > cookie->rid = strtoul( &rid_ptr[ STRLENOF( > "rid=" ) ], &next, 10 ); > - if ( next == rid_ptr || next > end || *next != > ',' ) { > + if ( next == rid_ptr > + || next > end > + || ( *next && *next != ',' ) ) > + { > return -1; > } > if ( *next == ',' ) { > @@ -194,7 +197,10 @@ > if ( !strncmp( next, "sid=", STRLENOF("sid=") )) { > rid_ptr = next; > cookie->sid = strtoul( &rid_ptr[ STRLENOF( > "sid=" ) ], &next, 16 ); > - if ( next == rid_ptr || next > end || *next != > ',' ) { > + if ( next == rid_ptr > + || next > end > + || ( *next && *next != ',' ) ) > + { > return -1; > } > if ( *next == ',' ) { > > I'm not committing this fix because I'm not sure it doesn't break > anything else. the patch fails, this is the patch reject file: ---ldapsync.c.rej ------------------------------- *************** *** 180,186 **** if ( !strncmp( next, "rid=", STRLENOF("rid=") )) { rid_ptr = next; cookie->rid = strtoul( &rid_ptr[ STRLENOF( "rid=" ) ], &next, 10 ); - if ( next == rid_ptr || next > end || *next != ',' ) { return -1; } if ( *next == ',' ) { --- 180,189 ---- if ( !strncmp( next, "rid=", STRLENOF("rid=") )) { rid_ptr = next; cookie->rid = strtoul( &rid_ptr[ STRLENOF( "rid=" ) ], &next, 10 ); + if ( next == rid_ptr + || next > end + || ( *next && *next != ',' ) ) + { return -1; } if ( *next == ',' ) { *************** *** 194,200 **** if ( !strncmp( next, "sid=", STRLENOF("sid=") )) { rid_ptr = next; cookie->sid = strtoul( &rid_ptr[ STRLENOF( "sid=" ) ]. &next, 16 ); - if ( next == rid_ptr || next > end || *next != ',' ) { return -1; } if ( *next == ',' ) { --- 197,206 ---- if ( !strncmp( next, "sid=", STRLENOF("sid=") )) { rid_ptr = next; cookie->sid = strtoul( &rid_ptr[ STRLENOF( "sid=" ) ]. &next, 16 ); + if ( next == rid_ptr + || next > end + || ( *next && *next != ',' ) ) + { return -1; } if ( *next == ',' ) { -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#4629) slapd failure on HP-UX 11.23/IA 64-bit
by h.b.furuseth＠usit.uio.no 10 Jun '07

10 Jun '07

Fixed in cvs (RE23 and HEAD) with a somewhat different patch. It should be more comprehensive than the old one, but testing on various systems is welcome anyway. -- Regards, Hallvard

1 0

Re: (ITS#4936) default modulepath
by ando＠sys-net.it 10 Jun '07

10 Jun '07

> No, they are installed in $(moduledir), which depends on LDAP_LIBEXECDIR > and --with-subdir. So, put that in some C variable or #define. Yes, I figured that out. I'll fix this later. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4936) default modulepath
by h.b.furuseth＠usit.uio.no 10 Jun '07

10 Jun '07

I wrote: > Use LDAP_LIBEXECDIR/openldap/, that's where modules get installed. > Try with ./configure --enable-overlays=mod --enable-monitor=mod. No, they are installed in $(moduledir), which depends on LDAP_LIBEXECDIR and --with-subdir. So, put that in some C variable or #define. -- Regards, Hallvard

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