3.0.4: binary LDAP attributes
Nikolai.Kondrashov at redhat.com
Fri Mar 24 10:13:07 CET 2017
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
>> 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.
More information about the Freeradius-Users