3.0.4: binary LDAP attributes

[Nikolai Kondrashov]

On 03/23/2017 02:59 PM, Alan DeKok wrote:
>
>> 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.

Well, zero is a valid UTF-8 character, but I think I understand what you're
saying about attribute values being "printable" strings. I assume that means
they are expected to contain escapes instead.

Thanks, everyone!

Nick