On Mon, Oct 22, 2018 at 09:01:21AM +0200, Martijn van Duren wrote:
> I found another bug while testing ldap(1) to M$ AD.
> Attributes like objectGUID are encoded as OCTET STRING, but are binary
> data, which are not UTF-8 strings.
> When looking at RFC4511 I found the following:
> 4.1.5. Attribute Value
> A field of type AttributeValue is an OCTET STRING containing an
> encoded attribute value. The attribute value is encoded according to
> the LDAP-specific encoding definition of its corresponding syntax.
>
> So we should not blindly utoa on an OCTET STRING.
>
> Diff below alleviates the problems when comparing the output of
> ldapsearch from OpenLDAP, but is probably horribly wrong.
>
But it makes sense, if we cannot trust it to be UTF-8 than it
shouldn't be assumed. aldap comes from ypldap(8), so the same problem
exists there. Could it eventually affect authentication credentials
that include UTF-8?
> Note that because of the current assumptions some values aren't printed
> at all, because they contain NUL-characters in the string. The patch
> below does not address this issue.
>
What do you mean with this or could you give an example? I use vis(1)
to print the attribute values, or base64 in LDIF mode, and it detects
"SAFE-STRINGs" (no \0 etc.) that can be printed without encoding.
Reyk
> martijn@
>
> Index: aldap.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/ldap/aldap.c,v
> retrieving revision 1.5
> diff -u -p -r1.5 aldap.c
> --- aldap.c 12 Aug 2018 22:04:09 -0000 1.5
> +++ aldap.c 22 Oct 2018 06:54:22 -0000
> @@ -860,7 +860,9 @@ aldap_get_stringset(struct ber_element *
> a = a->be_next, i++) {
>
> ber_get_string(a, &s);
> - ret[i] = utoa(s);
> + if ((ret[i] = calloc(a->be_len + 1, 1)) == NULL)
> + continue;
> + memcpy(ret[i], s, a->be_len);
> }
> ret[i + 1] = NULL;
>
>
--
