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

Stefan Winter stefan.winter at
Fri Sep 6 20:57:47 CEST 2013


> 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.


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

More information about the Freeradius-Users mailing list