2.x.x (and earier?): yet another decoding SSHA issue

[Arran Cudbard-Bell]

On 16 Jul 2013, at 11:33, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:

> 
> On 16 Jul 2013, at 11:04, Stefan Winter <stefan.winter at restena.lu> wrote:
> 
>> Hi,
>> 
>>> At a guess, i'd say the attribute you were creating was of type
>> OCTETS, in which case the above is the correct behaviour. Can you double
>> check that the type of the attribute is string, and not octets.
>> 
>> It's SSHA1-Password. Yes, it is octets, as defined in
>> dictionary.freeradius.internal.
>> 
>>> Nearly all string to value conversions (all drivers produce values as strings) go through pairparsevalue. String attributes will *not* be treated as hex strings by pairparsevalue, only raw attributes are.
>>> 
>>> Looking at src/lib/valuepair.c (pairparsevalue), writing to a destination attribute of type octets would describe exactly when you're experiencing.
>> 
>> I certainly wouldn't call it "correct". All other values for
>> SSHA1-Password which don't incidentally start with an 0X get parsed and
>> used correctly.
>> 
>> Looking at the code, it's much more so that lib/valuepair.c's case
>> PW_TYPE_OCTETS does a (poor) heuristics on the first two bytes of the
>> incoming blob.
> 
> It's a binary attribute, it's expected. There are many places where I 
> disagree with how the server operates, but assigning a string value 
> starting with 0x to a binary attribute and it erroring out when it finds
> non-hexits is fine IMHO.
> 
> Accepted, this is a pretty odd case. I can't think of many other places
> where attributes can contain values in multiple formats. Other than that
> awful WiMAX combo IP attribute.
> 
>> If it finds a 0x then it thinks it needs to decode.
>> Otherwise, it just returns vp.
>> 
>> What are you suggesting to make SSHA1-Password work deterministically?
>> 
>> * Should I change the dictionary.freeradius.internal away from octets to
>> string?
> 
> No.
> 
>> * Or encode the already base64-encoded SSHA hashes inside a hex encoding
>> to make the heuristics happy?
> 
> Yes. Or convert the encoding to hex, either will work.
> 
>> * Or should the heuristics maybe become a little more clever to *try* to
>> hex-decode things which start with 0x, but just return the value as-is
>> if that failed?
> 
> We could do that, but the majority of cases where you're assigning a 
> string value to an attribute of type of octets and the value starts with 0x
> you do want to do a hex to binary value conversion.

That said. The base64 heuristics would include a check for characters in the
allowed range. So for consistency you'd expect something similar for hex 
strings.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team