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

Arran Cudbard-Bell a.cudbardb at freeradius.org
Tue Jul 16 15:35:06 CEST 2013


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

> 
>> It is also very gentle on the source; looking at lib/valuepair.c, four
>> lines of code change would do wonders:
>> 
>> For the odd-number-of-characters around line 1100:
>> 
>> if ((strlen(cp) & 0x01) != 0) {
>>     radlog(L_INFO, "The input superficially looks like it's
>> hex-encoded, but it's not. Interpreting as literal octet stream.");
>>     break;
>> }
>> 
>> For the 0x prefix immediately after:
>> 
>> if (sscanf(cp, "%02x", &tmp) != 1) {
>> radlog(L_INFO, "The input superfially looks like it's hex-encoded, but
>> it's not (character sequence %c%c is not in the hexadecimal alphabet).
>> Interpreting as literal octet stream.", cp[0], cp[1]);
>> break;
>> }
>> 
>> That solves the problem as good as it gets
> 
> Or you can define a local string attribute which you write the value to,
> and use the base64 xlats to correctly 
> 
> I agree with your points, but it's a non-trivial behaviour change. 
> Thinking about it more, although it's very unlikely hex and plaintext 
> could get conflated with base64, it's still possible, and adding more 
> implicit conversions makes it worse.
> 
> I'll let Alan decide about the firmness of hex decoding, but there is an
> easier solution for you in 2.2.1.
> 
> Define a local string type attribute to hold the base64 encoded value.
> 
> update control {
> 	SSHA1-Password = "%{base64tohex:SSHA1-Password-Base64}"
> }
> 
> SSHA1-Password will then hold the raw octet value of the hash. Unfortunately
> I believe that rlm_pap has it's own normalization logic, 
> so may still attempt to decode the raw octets as hex or base64 *sigh*. 

actually, no, because rlm_pap knows the expected raw length of the hash it can be absolutely certain about which encoding scheme it's in.

The above is an immediate solution to the problem without requiring code changes.

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



More information about the Freeradius-Devel mailing list