Page MenuHomeVyOS Platform
Create Task
Maniphest T7285

CVE-2024-3596 (BlastRADIUS) mitigations for pam_radius
Open, HighPublic
Actions

Description

The July 2024 vulnerability discovered in the RADIUS protocol has already been patched in the upstream pam_radius 3.0.0 release (https://github.com/FreeRADIUS/pam_radius/issues/96), however the version provided both by Debian 12 upstream (2.0.0; trixie and sid both have the 3.0.0 release) and the version included in VyOS (1.5.0-cl3u7, https://github.com/vyos/vyos-1x/blob/1d419bc2b56a487527dd120d3f39d420fcb615b3/debian/control#L44C25-L44C36) have not yet applied the mitigation.

Related Resources:
FreeRADIUS Article: https://www.freeradius.org/vul_notifications/2024/07/09/blastradius.html
Debian Security Tracker (only calls out freeradius server as affected, but the trixie changelog mentions the vulnerability in the libpam-radius-auth package as well): https://security-tracker.debian.org/tracker/CVE-2024-3596

Details

Version
-
Is it a breaking change?
Perfectly compatible
Issue type
Security vulnerability

Related Objects

Event Timeline

xeluior created this task.Tue, Mar 25, 6:53 PM
xeluior triaged this task as Normal priority.
xeluior created this object in space S1 VyOS Public.
pasik subscribed.Tue, Mar 25, 7:25 PM
xeluior added a comment.Tue, Mar 25, 8:12 PM

I have drafted https://github.com/vyos/libpam-radius-auth/pull/9 with the relevant commits cherry-picked from the upstream FreeRADIUS repo. I haven't been able to test the build yet due to some (probably) unrelated issues with apt in a Debian container.

dmbaturin added projects: VyOS 1.4 Sagitta (1.4.2), VyOS 1.5 Circinus.Tue, Mar 25, 10:04 PM
dmbaturin changed Is it a breaking change? from Unspecified (possibly destroys the router) to Perfectly compatible.
Viacheslav raised the priority of this task from Normal to High.Wed, Mar 26, 7:45 AM
xeluior added a comment.Mon, Mar 31, 6:42 PM

The above linked PR is ready for review by a maintainer. I've tried to cherry-pick only the most relevant commits from the upstream. The build was tested in the vyos-build container (as modified in https://vyos.dev/T7300) after each commit and the overall authentication flow was tested once as described in the PR.

I have not tested how this change behaves when presented with a server that does not send the Message-Authenticator attribute, but with the upstream change of require_message_authenticator being enabled by default, it is likely that anyone using such a server may be unable to login.

dmbaturin subscribed.Tue, Apr 1, 1:06 AM

I was looking into backporting it myself lately, at a glance your approach seems correct. I'll look deeper into it.

I have not tested how this change behaves when presented with a server that does not send the Message-Authenticator attribute, but with the upstream change of require_message_authenticator being enabled by default, it is likely that anyone using such a server may be unable to login.

That's my concern as well. The official position seems to be that clients should refuse to work with such servers. But I'm sure people will be very unhappy if they can't log in after an image upgrade. I have a feeling that it may be better left disabled by default, considering that the vulnerability is rather difficult to exploit and requires active MitM, and if someone has an attacker capable of active MitM in their network, they are already deep in trouble. In fact, if they are logged into a router, that probably means they don't even need this vulnerability for lateral movement, since being able to log in to one router in a network that uses RADIUS often means they can log into them all.

Maybe we will want to first release it as a hotfix package and gather feedback.