FreeRad crashing (RHEL 9.4, jut patched
Hi team, Is anyone else experiencing FreeRad core dumping on RHEL 9.4 with the latest patch? Tum history info 59 gives: Packages Altered: Upgrade freeradius-3.0.21-40.el9_4.x86_64 @rhel-9-for-x86_64-appstream-rpms Upgraded freeradius-3.0.21-39.el9_3.x86_64 @@System Upgrade freeradius-ldap-3.0.21-40.el9_4.x86_64 @rhel-9-for-x86_64-appstream-rpms Upgraded freeradius-ldap-3.0.21-39.el9_3.x86_64 @@System This appears to be related to status_check = status-server set in proxies (commenting it out seems to cause less/no crashes). With these lines commented out it runs fine, with these present service dies after ~5+ mins of running (running radiusd -X waiting for it to die again, its taking its time...) Change from v39 -> v40 appears to be related to BlastRADIUS vulnerability. Is there any issue with the fix for Blast + status_server checks? Thanks, Jim Potter Jisc
Hi Jim, Yes, and thanks for reporting this. I saw this on AlmaLinux 9.4 with freeradius-ldap-3.0.21-40.el9_4.x86_64. I haven't gotten as far as you with the debugging yet, had to downgrade. The instances that were not crashing are not serving as a proxies. The instances that were crashing did so after a minute to two minutes and do have "status_check = status-server" in proxy.conf. I have two outlier instances that are proxying but not using status_check (for reasons). Thanks Gary Studwell UCAR/NCAR On Fri, Aug 16, 2024 at 4:09 AM James Potter via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
Hi team,
Is anyone else experiencing FreeRad core dumping on RHEL 9.4 with the latest patch?
Tum history info 59 gives: Packages Altered: Upgrade freeradius-3.0.21-40.el9_4.x86_64 @rhel-9-for-x86_64-appstream-rpms Upgraded freeradius-3.0.21-39.el9_3.x86_64 @@System Upgrade freeradius-ldap-3.0.21-40.el9_4.x86_64 @rhel-9-for-x86_64-appstream-rpms Upgraded freeradius-ldap-3.0.21-39.el9_3.x86_64 @@System
This appears to be related to status_check = status-server set in proxies (commenting it out seems to cause less/no crashes). With these lines commented out it runs fine, with these present service dies after ~5+ mins of running (running radiusd -X waiting for it to die again, its taking its time...)
Change from v39 -> v40 appears to be related to BlastRADIUS vulnerability. Is there any issue with the fix for Blast + status_server checks?
Thanks,
Jim Potter Jisc
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Aug 2, 2024, at 4:52 AM, James Potter via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Is anyone else experiencing FreeRad core dumping on RHEL 9.4 with the latest patch?
Tum history info 59 gives: Packages Altered: Upgrade freeradius-3.0.21-40.el9_4.x86_64 @rhel-9-for-x86_64-appstream-rpms Upgraded freeradius-3.0.21-39.el9_3.x86_64 @@System Upgrade freeradius-ldap-3.0.21-40.el9_4.x86_64 @rhel-9-for-x86_64-appstream-rpms Upgraded freeradius-ldap-3.0.21-39.el9_3.x86_64 @@System
This appears to be related to status_check = status-server set in proxies (commenting it out seems to cause less/no crashes). With these lines commented out it runs fine, with these present service dies after ~5+ mins of running (running radiusd -X waiting for it to die again, its taking its time...)
Change from v39 -> v40 appears to be related to BlastRADIUS vulnerability. Is there any issue with the fix for Blast + status_server checks?
If you're running 3.0.21 plus patches, you should either use 3.0.27 from our official repos, or ask RedHat to fix their packages. i.e. 3.0.21 is 4 years old, and we have released new versions of FreeRADIUS since then with many fixes. We don't re-release "patched" versions of old software. I presume you're paying RedHat for support. The solution is then to ask that they provide you with fixes. The current patches they provide are *not* the official 3.0.21, and RedHat has likely added patches which break the server. So in the end, this looks like a RedHat problem, and not a FreeRADIUS problem. Alan DeKok.
Hi, FYI - The core dump comes from a Status-Server request not being handled correctly. FR v3.2.6 will fix it (confirmed by Alan D in the Devel list), so I would venture to guess that the FR folks will also roll a next version of 3.0.x for that? If so, switch to that... it tends to take RedHat a while to update (backport) fixes. :-) Stefan Paetow Federated Roaming Technical Specialist eduroam(UK), Jisc email/teams: stefan.paetow@jisc.ac.uk gpg: 0x3FCE5142 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: 4 Portwall Lane, Bristol, BS1 6NB Tel: 020 3697 5800. On 16/08/2024, 11:08, "Freeradius-Users on behalf of James Potter via Freeradius-Users" <freeradius-users-bounces+stefan.paetow=jisc.ac.uk@lists.freeradius.org <mailto:jisc.ac.uk@lists.freeradius.org> on behalf of freeradius-users@lists.freeradius.org <mailto:freeradius-users@lists.freeradius.org>> wrote: Hi team, Is anyone else experiencing FreeRad core dumping on RHEL 9.4 with the latest patch? Tum history info 59 gives: Packages Altered: Upgrade freeradius-3.0.21-40.el9_4.x86_64 @rhel-9-for-x86_64-appstream-rpms Upgraded freeradius-3.0.21-39.el9_3.x86_64 @@System Upgrade freeradius-ldap-3.0.21-40.el9_4.x86_64 @rhel-9-for-x86_64-appstream-rpms Upgraded freeradius-ldap-3.0.21-39.el9_3.x86_64 @@System This appears to be related to status_check = status-server set in proxies (commenting it out seems to cause less/no crashes). With these lines commented out it runs fine, with these present service dies after ~5+ mins of running (running radiusd -X waiting for it to die again, its taking its time...) Change from v39 -> v40 appears to be related to BlastRADIUS vulnerability. Is there any issue with the fix for Blast + status_server checks? Thanks, Jim Potter Jisc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <http://www.freeradius.org/list/users.html>
participants (4)
-
Alan DeKok -
Gary Studwell -
James Potter -
Stefan Paetow