Segmentation Fault on "[pap] Normalizing SSHA1-Password from base64 encoding"

[Stefan Winter]

Hi,

> http://lists.freeradius.org/pipermail/freeradius-devel/2013-May/008046.html
> http://lists.freeradius.org/pipermail/freeradius-users/2013-May/066440.html
>
> I also did everything that Stefan Winter did - gdb live server,
> valgrind, look at the source, compare with 3.0 - and got the same
> results. In the -devel thread Alan DeKok says there won't be any
> patches or development on the 2.2.x branch anymore, and I tested with
> 3.0 with success.
>
> So I ask: is there any way to backport the fix to 2.2.x branch? I
> don't know C very well but if it's not so hard, I might try talking to
> people who knows how to code and create a unnoficial patch. I saw that
> the base64 is now using a brave new approach on 3.0.
>
> And also, if keeping this bug forever in the 2.2.x branch, what is, in
> your opinions, the best way to store the encrypted passwords? I'm
> using SSHA-Passwords attribute, salted with the "uuidgen" command. And
> I was thinking, if I use a salt with only 16 characters instead of
> 32+, is there any chance for this bug to happen? It'll be easier for
> me to fix the salts instead of the code. I can't migrate to 3.0 right
> now because the system is in production state.
>
> (Please, don't say Cleartext-Passwords are the solution :P)

You should read the (entire!) thread on -devel titled

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

during which at some point the 2.x.x branch code got fixes for the bulk
of the issue. This will be in 2.2.1; but you can safely grab current
branch, it's running stable on my production systems for a long time now.

The fix still needs config changes with a bit of a hackish workaround -
read the thread til the end to get all the goodness.

Greetings,

Stefan Winter
>
> The following hash generates the crash:
>
> 42A9cqWnI8QAyQLsy7+iZDNKkrwzYzZlMjFiMC00YWFlLTQyN2QtOTdlNC0zNjIyYTZmYjhjNDk=
>
> Thanks!
>