rlm_digest failing after upgrade from 2.1.12 to 2.2.5
Hi, We just updated a Debian server from wheezy to jessie The freeradius server package updated from 2.1.12+dfsg-1.2 to 2.2.5+dfsg-0.2 This particular server is used for SIP users (for debian.org itself) The users are in a text file and it is loaded like this in radiusd.conf: modules { $INCLUDE modules/attr_filter $INCLUDE modules/digest passwd rtc_users { filename = /var/local/rtc-passwords.freerad format = "*User-Name:Digest-HA1:" hashsize = 1000 ignorenislike = no allowmultiplekeys = no } } Since the upgrade, the server is complaining: Auth: [digest] Cleartext-Password or Digest-HA1 is required for authentication. When the server is started or given HUP, it doesn't give any hints that anything is wrong: Wed Oct 21 07:51:05 2015 : Info: Received HUP signal. Wed Oct 21 07:51:05 2015 : Info: HUP - Re-reading configuration files Wed Oct 21 07:51:05 2015 : Info: HUP - loading modules Wed Oct 21 07:51:05 2015 : Info: Module: Reloaded module "attr_filter.access_reject" Wed Oct 21 07:51:05 2015 : Info: Module: Reloaded module "rtc_users" Wed Oct 21 07:51:05 2015 : Info: Loaded virtual server <default> Wed Oct 21 07:51:05 2015 : Info: Loaded virtual server rtc.debian.org I looked at the changelog, it only mentions passwd in one place and digest is not mentioned anywhere: FreeRADIUS 2.2.0 Mon 10 Sep 2012 12:00:00 CEST, urgency=medium Feature improvements * 100% configuration file compatible with 2.1.x. The only fix needed is to disallow "hashsize=0" for rlm_passwd The freeradius-client library is being used, it is the same version before and after the upgrade, 1.1.6. Can anybody give any feedback on this or suggest the best way to troubleshoot the issue? Regards, Daniel
Can anybody give any feedback on this or suggest the best way to troubleshoot the issue?
As is customary on the list, a debug output of such a request would be most helpful :-) Run /usr/sbin/freeradius -fxx -l stdout and then capture an authentication request. Post the entire output (from the beginning) here. Folks appreciate that more than having to make a stab in the dark. :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 21/10/15 10:23, Stefan Paetow wrote:
Can anybody give any feedback on this or suggest the best way to troubleshoot the issue?
As is customary on the list, a debug output of such a request would be most helpful :-)
Run /usr/sbin/freeradius -fxx -l stdout and then capture an authentication request. Post the entire output (from the beginning) here. Folks appreciate that more than having to make a stab in the dark.
We tried that, we can see freeradius is authorizing the requests libfreeradius-client is logging the following: rc_check_reply: received invalid reply digest from RADIUS server and giving the response -2 (BADRESP_RC) to the application code Still trying to work out why this is happening. Have any digest algorithms or other things changed between 2.1.x and 2.2.5? Regards, Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWKIbEAAoJEOm1uwJp1aqDl5UP/2/ZrkoIqgp0qhQIluLIHmKU huUmDn81R38cCM7AISxg8pMxYtkMVLF73gOlydt7qm9j+3J/7tFwKfrGYjHnrS0B 3uRIJZlluHcuQcyex5YhxxPK/RN41Fs8EA7HsT5BZ/CcsBp9z41PXW1VYyFnUdtW 140oqFsJbPQmoeekN+7rECurV9DeOJXVqr0ENXOOWAu5fxYF+W9gK3vsFmkym1ld igvGTr8m9ZHeZx2Zm1ptfg6pXEd6eoa8pcZ5o168QHzajsMkBhwefly1FU1u2Hi/ Cb5YU71s4Pcrqu78XH6KVCv5TlYaLGdmll0WENL2Syyl+5XyhzdagMvzyebTA51W hqMKFjGaDIF0Xrc1S/f/Wm0Ma82g8n7cFUn+5s6ijcRatiMV6ODlJQimrgRTV95T 9aR3imgynRORME9jb0ldOpjLDPtq15I++UBFrqRSXveMIe1tDQDBO/WFijbU1DNf f1io5m1lfWkIzHm1sf6PDfj0RiPr+K4VvudO8Qk4ZL3edFAiq8aqe6KR8SRsEn2z nxlTDi4mzog+KlWq8YLRSxjsvoAq3zJFkZGGz6v0pAAYCTJu+SZ7hQNt8BS7PEBb 4Eqb/fhWBNsgcPI1kQAe2/U7UZJ9LP4C/Op97H3WZ1j8FZAfmQP0d7GTZ1oegA+j VcKcMwzrvfVV6QExvvE1 =dItO -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 22/10/15 08:48, Daniel Pocock wrote:
On 21/10/15 10:23, Stefan Paetow wrote:
Can anybody give any feedback on this or suggest the best way to troubleshoot the issue?
As is customary on the list, a debug output of such a request would be most helpful :-)
Run /usr/sbin/freeradius -fxx -l stdout and then capture an authentication request. Post the entire output (from the beginning) here. Folks appreciate that more than having to make a stab in the dark.
We tried that, we can see freeradius is authorizing the requests
libfreeradius-client is logging the following:
rc_check_reply: received invalid reply digest from RADIUS server
and giving the response -2 (BADRESP_RC) to the application code
Still trying to work out why this is happening. Have any digest algorithms or other things changed between 2.1.x and 2.2.5?
I looked at the packets with wireshark, the digest strings appear to be 16 bytes in request and response freeradius-client is hard coded to md5 I disabled the check in the libfreeradius-client code and everything else appears to work (commenting out the return BADRESP_RC): if (memcmp ((char *) reply_digest, (char *) calc_digest, AUTH_VECTOR_LEN) != 0) { #ifdef RADIUS_116 /* the original Livingston radiusd v1.16 seems to have a bug in digest calculation with accounting requests, authentication request are ok. i looked at the code but couldn't find any bugs. any help to get this kludge out are welcome. preferably i want to reproduce the calculation bug here to be compatible to stock Livingston radiusd v1.16. -lf, 03/14/96 */ if (auth->code == PW_ACCOUNTING_RESPONSE) return OK_RC; #endif rc_log(LOG_ERR, "rc_check_reply: received invalid reply digest from RADIUS server, ignoring, patched 2015-10-22"); //return BADRESP_RC; } return OK_RC; -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWKI6RAAoJEOm1uwJp1aqDMrUP/igzj6VjMQVzAllv1HyxlNIB os4GnSFhIZaf2/bdBXyzh/YX4RRpemip3B8NQYiFCjE8j8KlUsFk+NK9Uucx5ekd wabckALNS8btxTLFzNwXX8ryfuJC8VU+qxV3b6+Z0d3tlpEgPdJbzCC7sjrv81K2 aDUH7XsrOWb3rJZ1De9/iiXaaipqy5K3933wbbNa25BclIbqhEYdjyg7oSPPczwX 4nCYUhdKL9ZSibzQYwS7iYX5oCAyoQqdyvq9vF560mwkLl0Q9TfXuAvlATjHILqc xBb/7Z+TjbZEv2JNHhjBLI0LQHVdzIx2v7gj+ZRmrQFiBHcYXkM8qP5SRUDYL5hR /VnpAPeli1j54Ads/NcX4PJyXN5H6yDmogOFROlc8PBaHBFpglFSnMRnMDCXxd78 vtLZdjJnD6z2jw7yXQRRwvNumclZBFR0KXEbTNAoB12B176jyUhv0xMVlJYDII0N AHAaSC53DLTbpo2DGYZVo4N1I1VfNlYKBQb6/HoxNYNtjRUibfFKAwJCqGrT+M80 bEh4UIiibIOHFEDytnzUyJk97X1+azldB7YNZg1ucq9b29Y4Qewf6XnOXbYFcVxr la1rVPaBh1nGq0YA4HomDKjVQEvxk7MU0lpy4l2HR8SfXTjwaFr9ZinHTT8e5NH+ +uaaegLoNVuOfGcetxWR =MVkX -----END PGP SIGNATURE-----
On Oct 22, 2015, at 3:21 AM, Daniel Pocock <daniel@pocock.pro> wrote:
We tried that, we can see freeradius is authorizing the requests
libfreeradius-client is logging the following:
rc_check_reply: received invalid reply digest from RADIUS server
So the shared secret is wrong.
I disabled the check in the libfreeradius-client code and everything else appears to work (commenting out the return BADRESP_RC):
Which means anyone can forge replies to authentication packets. Don't do that. Fix the shared secret. Alan DeKok.
On 22/10/15 17:07, Alan DeKok wrote:
On Oct 22, 2015, at 3:21 AM, Daniel Pocock <daniel@pocock.pro> wrote:
We tried that, we can see freeradius is authorizing the requests
libfreeradius-client is logging the following:
rc_check_reply: received invalid reply digest from RADIUS server
So the shared secret is wrong.
I disabled the check in the libfreeradius-client code and everything else appears to work (commenting out the return BADRESP_RC):
Which means anyone can forge replies to authentication packets.
Don't do that. Fix the shared secret.
I'm not suggesting that this change be merged like a pull request The shared secret was not changed when upgrading the system from Debian wheezy to jessie. We compared the client and server configs and the secret appears to be the same in both. It had all been working fine for quite some time. If nobody has seen anything like this before, I'll try adding some more logging code or running it in a debugger. Regards, Daniel
On Oct 22, 2015, at 11:25 AM, Daniel Pocock <daniel@pocock.pro> wrote:
The shared secret was not changed when upgrading the system from Debian wheezy to jessie. We compared the client and server configs and the secret appears to be the same in both. It had all been working fine for quite some time. If nobody has seen anything like this before, I'll try adding some more logging code or running it in a debugger.
<shrug> a) the shared secret is wrong on the client b) the shared secret is wrong on the server c) the client calculates the packet signature incorrectly d) the server calculates the packet signature incorrectly Pick one. You can always run radclient from the client machine, too. That would give you another test. Alan DeKok.
On 22/10/15 17:49, Alan DeKok wrote:
On Oct 22, 2015, at 11:25 AM, Daniel Pocock <daniel@pocock.pro> wrote:
The shared secret was not changed when upgrading the system from Debian wheezy to jessie. We compared the client and server configs and the secret appears to be the same in both. It had all been working fine for quite some time. If nobody has seen anything like this before, I'll try adding some more logging code or running it in a debugger.
<shrug>
a) the shared secret is wrong on the client
b) the shared secret is wrong on the server
c) the client calculates the packet signature incorrectly
d) the server calculates the packet signature incorrectly
Pick one.
You can always run radclient from the client machine, too. That would give you another test.
Some more observations: - we had the password in the radius-servers file. If we put the password on the authserver line in the radius-config file instead, then everything works again. E.g. we change from: authserver some-server to authserver some-server:1812:<secret> - I also tried using radcli instead of freeradius-client. radcli logs a syslog error about not being able to read the radius-servers file Nothing had been changed in these files, the permissions were fine for the process to read them too. I haven't had time to step through it with a debugger or strace to see what goes wrong when it tries to access the radius-servers file. It is good that radcli warns about the real problem earlier on, as the errors from freeradius-client come much too late.
participants (3)
-
Alan DeKok -
Daniel Pocock -
Stefan Paetow