BlastRADIUS mitigation

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