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

[Arran Cudbard-Bell]

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

> 
> On 16 Jul 2013, at 08:58, Stefan Winter <stefan.winter at restena.lu> wrote:
> 
>> Hi,
>> 
>> here's yet another thing which caused spurious authentication
>> failures; luckily I was accidently in debug mode looking for
>> something else when I found the cause for some failed auth:
>> 
>> +++- entering policy redundant {...}
>> [sql-imap-hash]         expand: %{User-Name} -> pgloden
>> [sql-imap-hash] sql_set_user escaped user --> 'pgloden'
>> rlm_sql (sql-imap-hash): Reserving sql socket id: 7
>> [sql-imap-hash]         expand: (SELECT id, username, attribute, value, op FROM check_imap_ssha1 WHERE username='%{SQL-User-Name}') -> (SELECT id, username, attribute, value, op FROM check_imap_ssha1 WHERE username='pgloden')
>> rlm_sql_mysql: query:  (SELECT id, username, attribute, value, op FROM check_imap_ssha1 WHERE username='pgloden')
>> rlm_sql: Failed to create the pair: Non-hex characters at QX
>> rlm_sql (sql-imap-hash): Error getting data from database
>> [sql-imap-hash] SQL query error; rejecting user
>> 
>> The query works just fine and returns a base64-encoded SSHA1
>> hash of a user's password. The base64 blob happens to start
>> with the two characters "0X" (and then continues with QX,
>> which is in the error message).
>> 
>> It seems like the query response parser tries to be overly
>> clever and thinks that anything starting with 0X is a hex
>> number and needs decoding. This, of course, fails. Needsless
>> to say that the schema doesn't suggest an integer at all, it's
>> a varchar(168).
>> 
>> The workaround right now for us is to set the hashed password, 
>> see if it happens to start with 0X, and if so, try with a
>> different salt. 
> 
> 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.
> 
> 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.
> 

*What

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