Обсуждение: Time to drop RADIUS support?
Hi,
A bit over a year ago, I wrote about a RADIUS vulnerability and a
recommended mitigation[1]. 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] 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], 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] https://www.postgresql.org/message-id/flat/CA%2BhUKGLRSPTOC_ygx4_sJjWeKOkOpWGCBCJiRq8cPNuMisuzgw%40mail.gmail.com
[2] https://datatracker.ietf.org/doc/draft-ietf-radext-deprecating-radius/
Вложения
Hi, On Fri, Jan 23, 2026 at 11:22:45PM +1300, Thomas Munro wrote: > 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. So you are saying we add a deprecation notice in the back branches and drop it in V19? If this is a severe security issue then maybe we can just remove it everywhere (ugh), or if not, I think it probably warrants at least one release cycle of deprecation. Do we have a formal deprecation timeline policy nowadays? Michael
On 2026-Jan-23, Michael Banck wrote: > So you are saying we add a deprecation notice in the back branches and > drop it in V19? If this is a severe security issue then maybe we can > just remove it everywhere (ugh), or if not, I think it probably warrants > at least one release cycle of deprecation. Do we have a formal > deprecation timeline policy nowadays? I don't think we do. 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 removing it entirely from all back branches is a good idea, without first making sure that there are no users. [*] or even just a way to document a migration to PAM-based Radius. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "I'm impressed how quickly you are fixing this obscure issue. I came from MS SQL and it would be hard for me to put into words how much of a better job you all are doing on [PostgreSQL]." Steve Midgley, http://archives.postgresql.org/pgsql-sql/2008-08/msg00000.php
=?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
On Fri, Jan 23, 2026 at 8:30 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > 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. +1. I still think a WARNING in the back branches would be a kindness, to let people know that they need to move. --Jacob
On Sat, Jan 24, 2026 at 6:50 AM Jacob Champion <jacob.champion@enterprisedb.com> wrote: > On Fri, Jan 23, 2026 at 8:30 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > 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. > > +1. Great, it sounds like we have a plan. I think the wiki might be a good place for that documentation. The details are likely to change, and I wouldn't want to have to maintain that information in-tree, so I created some PAM how-to documentation at https://wiki.postgresql.org/wiki/RADIUS after testing on Debian and FreeBSD. We could point to that from the 19 release notes and in the deprecation notice added to the documentation for 14-18, calling it "community-maintained guidance on migration to supported configurations". Do we need to keep any trace of this in the 19 docs, and if so, where? A new tombstone section?
Thomas Munro <thomas.munro@gmail.com> writes: > Great, it sounds like we have a plan. I think the wiki might be a > good place for that documentation. The details are likely to change, > and I wouldn't want to have to maintain that information in-tree, so I > created some PAM how-to documentation at > https://wiki.postgresql.org/wiki/RADIUS after testing on Debian and > FreeBSD. Ok ... > We could point to that from the 19 release notes and in the > deprecation notice added to the documentation for 14-18, calling it > "community-maintained guidance on migration to supported > configurations". Do we need to keep any trace of this in the 19 docs, > and if so, where? A new tombstone section? I think we don't want https://www.postgresql.org/docs/current/auth-radius.html to become 404, so I'd advocate keeping a short section with that SGML ID that says we no longer support RADIUS directly and gives a pointer to the wiki page. It probably doesn't belong exactly where it is today in the TOC, though, but shoved off in a corner somewhere. regards, tom lane
Hi, > 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], 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. All things considered, it sounds perfectly reasonable. +1. -- Best regards, Aleksander Alekseev