3.0.4: binary LDAP attributes

[Alan DeKok]

> On Mar 23, 2017, at 5:23 AM, Nikolai Kondrashov <Nikolai.Kondrashov at redhat.com> wrote:
> 
> On 12/09/2014 01:51 PM, Nikolai Kondrashov wrote:
>> Our (Red Hat) QA was testing the effect of this entry in 3.0.4 ChangeLog:
>> 
>>    * Modify pairparsevalue to deal with embedded NULLs better,
>>      and use the binary versions of attribute values in rlm_ldap.
>> 
>> They have noticed that binary LDAP values get truncated on embedded zero
>> characters (\0) in RADIUS replies, in radiusReplyMessage in particular.
>> I.e. for
>> 
>>    radiusReplyMessage:: cmVwbHkgd2l0aCBhAGI=
>> 
>> The response output by radtest was
>> 
>>    Reply-Message = 'reply with a'
>> 
>> The network capture also showed that RADIUS reply packets contained truncated
>> values.
> 
> We still see the above behavior in v3.0.13.
> 
> Please excuse me, if you explained it before, but is this intended,
> or is this a bug?

  The underlying issue is how strings are dealt with.  The various LDAP APIs and rlm_ldap take char* and length pointers, so that works.

  The underlying issue is in src/main/map.c, map_afrom_attr_str().  It takes a char* pointer which contains operator and value.  e.g. ":= bob".  That gets parsed into separate fields, but the length of the underlying string is not used.

  I'm not sure why that's done for rlm_ldap, as the operators are already in the "map" config of raddbs/mods-enabled/ldap.

  So the short answer is that the values in LDAP are *printable* strings, not *raw* strings.  This likely goes back to the origin of the server.

  i.e. if you want embedded NULs, double quotes, etc... you've got to escape them.

  And on top of that, Reply-Message is usually a UTF-8 string.  So putting embedded zeros into a printable string will confuse a lot more products than just FreeRADIUS.

  i.e. don't do it.

  Alan DeKok.