Hi, (This discussion started on the security@ list, but was deemed suitable for the -hackers@ list.)
PostgreSQL supports RADIUS authentication[1]. It's probably not widely used, and generally any security technology based on MD5 alone should by now be considered weak and obsolete, but there are a few reports of users. Recently, a paper was published[2] showing successful attacks on a range of RADIUS clients, though no mention of PostgreSQL. It's not just an MD5 collision search, it's a more specific cryptographic weakness in the protocol that allows messages to be forged in quite practical amounts of CPU time. We might be quite lucky though: our hard-coded RADIUS_TIMEOUT = 3s doesn't seem to be enough time, based on my non-crypto-expert reading of the paper at least. Even if we assume that is true, FreeRADIUS 3.2.5 has recently[3] started spewing scary warnings when PostgreSQL sends requests to it by default, and advising administrators to adjust the relevant setting further to just drop unsigned messages. I assume the commercial RADIUS implementations will do something like that too, based on comments about the intended direction and expectations of clients in an in-development RFC[4]. The attached patch-set adds a basic TAP test for RADIUS authentication, and then adds a Message-Authenticator attribute to all outgoing requests (an HMAC-MD5 signature for the whole message that was already defined by the RFCs but marked optional and often omitted), and also *optionally* requires a Message-Authenticator to appear in responses from the RADIUS server, and verifies it if present. With the change, FreeRADIUS 3.2.5 is happy to talk to PostgreSQL again. The response requirement can be enabled by radiusrequirema=1 in pg_hba.conf. For example, Debian stable is currently shipping FreeRADIUS 3.2.1 which doesn't yet send the MA in its responses, but FreeBSD and Debian "testing" have started shipping FreeRADIUS 3.2.5 which is how I noticed all this. So it doesn't seem quite right to require it by default, yet? It's quite easy to test this locally, if you have FreeRADIUS installed on any Unixoid system. See the TAP test for some minimal configuration files required to try it out. I had originally developed the TAP test as part of a larger project[5] really about something else, which is why it has Michael listed as a reviewer already, and this version incorporates some new improvements he recommended (thanks!). I've created this new thread and new minimal test just to deal with the BlastRADIUS mitigation topic. We might also consider just dropping RADIUS support in 18, if we don't get patches to bring it up to date with modern RADIUS recommendations beyond the mitigation (deprecating UDP, adding TLS, probably more things). Such patches would ideally be written by someone with a more direct interest in the protocol (ie I am not volunteering). But even if we decide to drop it instead. I think we'd still want the change I'm proposing here for released branches. Since PostgreSQL v12 and v13 don't have the modern "common/hmac.h" API, I came up with a cheap kludge: locally #define those interfaces to point directly to the OpenSSL HMAC API, or just give up and drop Message-Authenticator support if you didn't build with OpenSSL support (in practice everyone does). Better ideas? [1] https://www.postgresql.org/docs/current/auth-radius.html [2] https://www.blastradius.fail/ [3] https://github.com/FreeRADIUS/freeradius-server/commit/6616be90346beb6050446bd00c8ed5bca1b8ef29 [4] https://datatracker.ietf.org/doc/draft-ietf-radext-deprecating-radius/ [5] https://www.postgresql.org/message-id/flat/CA%2BhUKGKxNoVjkMCksnj6z3BwiS3y2v6LN6z7_CisLK%2Brv%2B0V4g%40mail.gmail.com
v1-0001-Add-simple-test-for-RADIUS-authentication.patch
Description: Binary data
v1-0002-ci-Enable-RADIUS-tests.patch
Description: Binary data
v1-0003-Mitigation-for-BlastRADIUS.patch
Description: Binary data
v1-0004-Teach-007_radius-test-about-Message-Authenticator.patch
Description: Binary data
v1-0005-XXX-BlastRADIUS-back-patch-kludge-for-12-and-13.patch
Description: Binary data
