Time to drop RADIUS support?

Hi,

A bit over a year ago, I wrote about a RADIUS vulnerability and a
recommended mitigation[1]/messages/by-id/CA+hUKGLRSPTOC_ygx4_sJjWeKOkOpWGCBCJiRq8cPNuMisuzgw@mail.gmail.com. I was grateful for the reviews, but I lost
steam on those patches because:

1. Our implementation seems to have accidental (?) resilience because
it has a short hard-coded timeout. The RADIUS/UDP Considered
Harmful[0]https://www.usenix.org/conference/usenixsecurity24/presentation/goldberg people used 47 servers to get "2% of the successful runs to
finish before 240s and 16% before 300s", but we time out after 3
seconds. Assuming perfect scaling, maybe they could use 4700 servers
to get a 16% chance of success in 3s... or maybe I have the maths
wrong but it's fairly extreme anyway...

2. It seems increasingly likely that there are no users, since
RADIUS/UDP without the mitigation spews warnings from FreeRADIUS, and
Microsoft RADIUS's 2024 update (KB5040456) recommended requiring it
(though you didn't have to accept IIUC). I'm pretty sure we'd have
heard about it from users if there were any.

3. That mitigation would help, but in the end it's still leaky
obfuscation of credentials + MD5-based technology that is being
formally deprecated with a mandated replacement[2]https://datatracker.ietf.org/doc/draft-ietf-radext-deprecating-radius/, and de facto has
been for a long time.

The real recommendation of the paper was "don't use RADIUS/UDP at
all", and I don't want to expend energy writing a RADIUS/TLS client
for a hypothetical user, so I think we should just delete it all, and
stick a deprecation notice in the release branch documentation, as
attached. That'd also mean our Windows select() and non-thread-safe
UDP kludges can be VACUUMed.

AFAICS you can already do RADIUS better with PAM using a module
maintained by the FreeRADIUS project (see below for quick and dirty
demo). That way it's not our problem, follows the standards etc. The
only issue I can think of with that is that Windows and OpenBSD
probably don't have PAM. But then, recall that we are talking about
approximately zero users so I think we can still hit 100% of them this
way?

=== Example of RADIUS via PAM ===

Tell PAM how to authenticate for service postgresql in /etc/pam.d/postgresql:
#%PAM-1.0
auth required pam_radius.so require_message_authenticator
account required pam_permit.so

Tell pam_radius.so how to talk to RADIUS server in /etc/radius.conf:
# Server[:port] SharedSecret Timeout Retries
127.0.0.1 shared_secret 3 3

Tell PostgreSQL to use PAM service postgresql in pg_hba.conf:
host all all 127.0.0.1/32 pam pamservice=postgresql

=== Setting up a test server to try it out ===

Tell FreeRADIUS how to be a RADIUS server in /tmp/radiusd/radiusd.conf:
/tmp/radiusd/radiusd.conf
client default {
ipaddr = "127.0.0.1"
secret = "shared_secret"
}
modules {
files {
filename = "/tmp/radiusd/users.txt"
}
pap {
}
}
server default {
listen {
type = "auth"
ipv4addr = "127.0.0.1"
port = "1812"
}
authenticate {
Auth-Type PAP {
pap
}
}
authorize {
files
pap
}
}
log {
destination = "files"
localstatedir = "/tmp/radiusd"
logdir = "/tmp/radiusd"
file = "/tmp/radiusd/radiusd.log"
}
pidfile = "/tmp/radiusd/radiusd.pid"

Tell FreeRADIUS the passwords in /tmp/radiusd/users.txt:
testuser Cleartext-Password := "xxx"

Then run it in the foreground with "radiusd -d /tmp/radiusd -f". If
you leave out "require_message_authenticator" from
/etc/pam.d/postgresql then you'll get log messages just like when
PostgreSQL speaks RADIUS natively:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
BlastRADIUS check: Received packet without Message-Authenticator.
Setting "require_message_authenticator = false" for client default
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
UPGRADE THE CLIENT AS YOUR NETWORK IS VULNERABLE TO THE BLASTRADIUS ATTACK.
Once the client is upgraded, set "require_message_authenticator =
true" for client default
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Both client and server should ideally be set to require
Message-Authenticator. Presumably with more coffee and man pages you
could also configure it to use RADIUS/TLS instead of RADIUS/UDP, etc.

[0]: https://www.usenix.org/conference/usenixsecurity24/presentation/goldberg
[1]: /messages/by-id/CA+hUKGLRSPTOC_ygx4_sJjWeKOkOpWGCBCJiRq8cPNuMisuzgw@mail.gmail.com
[2]: https://datatracker.ietf.org/doc/draft-ietf-radext-deprecating-radius/

=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:

Would it work to add a WARNING (or something) to all back branches to
ask users to write here, so that we can confirm in the next few months
whether the protocol is completely unused or not? If we do find users,
then we could try to think of workarounds[*], but otherwise we'd just
remove it for pg19 (or pg20 at the latest) and not waste any more time
on it.

I don't think that'd prove a lot. Affected users (if any) wouldn't
necessarily be quick to adopt the latest minor releases. They're
probably not even up-to-date on their RADIUS server, or they'd have
noticed it spewing complaints.

I don't think removing it entirely from all back branches is a good
idea, without first making sure that there are no users.

Agreed, we can't pull it from the back branches. But I'm in favor of
pulling it from HEAD if we document how to use PAM-based RADIUS
instead. I agree with Thomas' argument that the cost-benefit ratio
of fixing our implementation would be poor.

regards, tom lane