Michael Str=C3=B6der wrote: > Howard Chu wrote: >> [email protected] wrote: >>> + /* write out the request to the extended process */ >>> + fprintf( fp, "EXTENDED\n" ); >>> + fprintf( fp, "msgid: %ld\n", (long) op->o_msgid ); >>> + sock_print_conn( fp, op->o_conn, si ); >>> + sock_print_suffixes( fp, op->o_bd ); >>> + fprintf( fp, "oid: %s\n", op->ore_reqoid.bv_val ); >>> + if (op->ore_reqdata) { >>> + fprintf( fp, "valuelen: %lu\n", op->ore_reqdata->bv_len ); >>> + fprintf( fp, "value: %s\n", op->ore_reqdata->bv_val ); >>> + } >>> + fprintf( fp, "\n" ); >> >> This isn't safe. The reqdata is binary, not a nul-terminated C string.= I suppose you >> could hex or base64-encode it instead. >=20 > Frankly I don't understand. >=20 > I considered using base64 but I wanted to stick to what's already done = in back-sock. >=20 > See openldap/servers/slapd/back-sock/bind.c for the password value whic= h is also an > arbitrary OctetString: >=20 > /* write out the request to the bind process */ > [..] > fprintf( fp, "credlen: %lu\n", op->oq_bind.rb_cred.bv_len ); > fprintf( fp, "cred: %s\n", op->oq_bind.rb_cred.bv_val ); /* XXX */ > fprintf( fp, "\n" ); >=20 > The above should also work with null-bytes, shoudn't it?
No, it's a bug. Probably a benign bug because it's difficult for users to= =20 create passwords with embedded NULs. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
