Michael Str=C3=B6der wrote:
Howard Chu wrote:
michael@stroeder.com 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/
-
hyc＠symas.com