Re: Segmentation Fault on [pap] Normalizing SSHA1-Password from base64 encoding
Hi,
The fix still needs config changes with a bit of a hackish workaround -
read the thread til the end to get all the goodness.
I tested some of the hashes that were giving me trouble and they all
worked with the current branch version. I also read all the thread,
Glad to hear that :-)
The remaining issue occurs only when the base64-encoded SSHA password
starts with the two characters 0x or 0X. In that case, FreeRADIUS
thinks oh, a hex number, let's decode it - while the input is not a
number at all.
Doesn't lead to crashes, but auths going wrong. And, IIRC, that kind of
failed decoding heuristics only happens inside the SQL module, so if you
pull your SSHA hashes from elsewhere, it may not apply at all.
and some things were not so clear for me (sorry for the noobiness).
Could you explain your final configuration state?
The problem is that SSHA1-Password's data type triggers the
wannabe-decoding. The workaround was to define another attribute myself,
with another data type, which stops this from happening; and later
re-coding into the original attribute name explicitly in the config.
I saw the unlang:
update reply {
SSHA1-Password := 0x%{base64tohex: %{control:RESTENA-SSHA1-Password1}}
}
And the SQL syntax:
SELECT id, username, 'RESTENA-SSHA1-Password', value, op FROM
check_smtp_ssha1 WHERE username='%{SQL-User-Name}
Is these configurations obligatory? I'm using the standard radcheck
table (id,username,attribute,op,value) and query that comes with
freeradius. From what I understood, I need to create a VSA, assign my
SSHA1-Password attribute to it and convert it to hex format using the
unlang and xlat?
Without these extra configuration, the messages from authorization are now:
That's right, the RESTENA-* thing is a VSA. Not sure about the data type
right now, not in the office. I think SSHA1-Password's failing one is
octets and the VSA is string (or text?) instead. Ehm, the thread
should tell you :-)
If you have control over your database, it's obviously better to change
the attribute name inside the DB to your VSA's attribute name, and to
leave the standard queries in sql.conf untouched. In my setup, I did not
have that luxury, thus the override of attribute name to a hard-wired
RESTENA-SSHA1-Password.
[pap] login attempt with password senhasecreta
[pap] Using SSHA encryption.
[pap] User authenticated successfully
++[pap] = ok
So the Normalizing error and segmentation fault isn't happening anymore.
With only those specific 0x/0X characters triggering failure, you'd see
approx. 1 out of 16.000 hashes being affected. Depending on your
deployment size, you may simply not have seen it yet :-)
The normal non-debug log would not produce any clue that something went
wrong (aside from auth failed), as the error would be an SQL query
error - even though the query is perfectly fine; it's the
post-processing that goes wrong.
HTH,
Stefan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Segmentation Fault on [pap] Normalizing SSHA1-Password from base64 encoding
Hi, I'm getting the same errors as these messages: 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) The following hash generates the crash: 42A9cqWnI8QAyQLsy7+iZDNKkrwzYzZlMjFiMC00YWFlLTQyN2QtOTdlNC0zNjIyYTZmYjhjNDk= Thanks! -- []'s Hugo www.devin.com.br - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Segmentation Fault on [pap] Normalizing SSHA1-Password from base64 encoding
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! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Segmentation Fault on [pap] Normalizing SSHA1-Password from base64 encoding
On Fri, Sep 6, 2013 at 3:57 PM, Stefan Winter stefan.win...@restena.lu wrote:
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.
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.
That's nice to hear! Thanks! I just tested the 2.x.x branch and it's
working for me.
The fix still needs config changes with a bit of a hackish workaround -
read the thread til the end to get all the goodness.
I tested some of the hashes that were giving me trouble and they all
worked with the current branch version. I also read all the thread,
and some things were not so clear for me (sorry for the noobiness).
Could you explain your final configuration state?
I saw the unlang:
update reply {
SSHA1-Password := 0x%{base64tohex: %{control:RESTENA-SSHA1-Password1}}
}
And the SQL syntax:
SELECT id, username, 'RESTENA-SSHA1-Password', value, op FROM
check_smtp_ssha1 WHERE username='%{SQL-User-Name}
Is these configurations obligatory? I'm using the standard radcheck
table (id,username,attribute,op,value) and query that comes with
freeradius. From what I understood, I need to create a VSA, assign my
SSHA1-Password attribute to it and convert it to hex format using the
unlang and xlat?
Without these extra configuration, the messages from authorization are now:
[pap] login attempt with password senhasecreta
[pap] Using SSHA encryption.
[pap] User authenticated successfully
++[pap] = ok
So the Normalizing error and segmentation fault isn't happening anymore.
Thanks!
[]'s
Hugo
www.devin.com.br
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
