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
Re: smbencrypt calculates false hash for German umlauts and other non-ASCII letters
Matthias Nagel wrote: Hi Phil, Probably a fairly trivial patch if you feel like it ;o) I had a quick glace at the source code and I found two files named smbencrypt.c. If you give me a hint, which is the correct file to start with, I will brosw the source code from that point and see what I can do. But probably not before next month. Please check src/modules/rlm_mschap/smbencrypt.c The main issue is that there is *no* character set information in the MS-CHAP calculations. The character set could be UTF-8, or any non-standard 16-bit encoding. So the calculation of the NT hash will depend on the character set... which is largely secret. This makes it very difficult to create the *correct* NT hash. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: smbencrypt calculates false hash for German umlauts and other non-ASCII letters
On 7 Sep 2013, at 16:43, Alan DeKok al...@deployingradius.com wrote: Matthias Nagel wrote: Hi Phil, Probably a fairly trivial patch if you feel like it ;o) I had a quick glace at the source code and I found two files named smbencrypt.c. If you give me a hint, which is the correct file to start with, I will brosw the source code from that point and see what I can do. But probably not before next month. Please check src/modules/rlm_mschap/smbencrypt.c The main issue is that there is *no* character set information in the MS-CHAP calculations. The character set could be UTF-8, or any non-standard 16-bit encoding. So the calculation of the NT hash will depend on the character set... which is largely secret. This makes it very difficult to create the *correct* NT hash. Can't we assume src as UTF8 for NAI (RFC4282)? Arran Cudbard-Bell a.cudba...@freeradius.org FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: smbencrypt calculates false hash for German umlauts and other non-ASCII letters
Arran Cudbard-Bell wrote: Can't we assume src as UTF8 for NAI (RFC4282)? Ha, ha, ha, ha cough. 4282 is wrong. And no one implements any of it. The MS-CHAP RFCs are silent on the subject of character encoding. The unofficial word from Microsoft is MS-CHAP uses the local encoding. Ok... what's that? hysterical laughter No one knows. And there's no way to find out. And UTF-8 uses up to 5 octets for a character. MS-CHAP requires no more than 2. There is *no* way to do the right thing. You can get close. Sometimes. Maybe. But doing the right thing always? Impossible. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Fwd: Re: smbencrypt calculates false hash for German umlauts and other non-ASCII letters
Sorry, my mail program tricked me and used the wrong destination address. -- Weitergeleitete Nachricht -- Betreff: Re: smbencrypt calculates false hash for German umlauts andother non-ASCII letters Datum: Samstag 07 September 2013, 19:13:17 Von: Matthias Nagel matthias.h.na...@gmail.com An: Alan DeKok al...@deployingradius.com Hello everybody, as it was me who came up with the issue. The password must be encoded as UTF-16 in little endian and then the MD4 is calculated. For example: Assume one uses smbencrypt from command line interface in order to calculate the hash. The linux console is set up to use en-US.utf8. Then, at first a character encoding into UTF-16 little endian is necessary, and in a second step the MD4 hash can be calculated. Matthias Am Samstag 07 September 2013, 12:10:38 schrieben Sie: Arran Cudbard-Bell wrote: Can't we assume src as UTF8 for NAI (RFC4282)? Ha, ha, ha, ha cough. 4282 is wrong. And no one implements any of it. The MS-CHAP RFCs are silent on the subject of character encoding. The unofficial word from Microsoft is MS-CHAP uses the local encoding. Ok... what's that? hysterical laughter No one knows. And there's no way to find out. And UTF-8 uses up to 5 octets for a character. MS-CHAP requires no more than 2. There is *no* way to do the right thing. You can get close. Sometimes. Maybe. But doing the right thing always? Impossible. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Matthias Nagel Parkstraße 27 76131 Karlsruhe Mobil: +49-151-15998774 e-Mail: matthias.h.na...@gmail.com ICQ: 499797758 Skype: nagmat84 - -- Matthias Nagel Parkstraße 27 76131 Karlsruhe Mobil: +49-151-15998774 e-Mail: matthias.h.na...@gmail.com ICQ: 499797758 Skype: nagmat84 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
