3.0.4: binary LDAP attributes

[Arran Cudbard-Bell]

> On Mar 24, 2017, at 5:13 AM, Nikolai Kondrashov <Nikolai.Kondrashov at redhat.com> wrote:
> 
> 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.

It's an ongoing battle.  In v4 more things should be binary safe.  We've even overloaded the fmt specifiers for our logging functions so that they can print binary strings, and auto-escape them.

Using talloc has helped with this a lot, as talloc chunk headers contain the length of the buffer.

-Arran
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20170324/c614c350/attachment.sig>