Re: BlastRADIUS mitigation

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BlastRADIUS mitigation
Date: 2024-08-06 06:28:18
Message-ID: ZrHCgiQxhjIFP4p1@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 05, 2024 at 05:41:21PM +0300, Heikki Linnakangas wrote:
> On 05/08/2024 15:43, Thomas Munro wrote:
>> 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?
>
> Seems reasonable. It probably wouldn't be hard to backport common/hmac.h
> either, perhaps in a limited fashion with just md5 support.

It's a bit more than just backporting hmac.h and hmac.c.
hmac_openssl.c only depends on OpenSSL to do its business, but the
non-OpenSSL fallback implementation depends also on the cryptohash
fallbacks for SHA-NNN and MD5. So you would also need the parts
related to cryptohash.c, sha{1,2}.c, etc. Not really complex as these
could be dropped as-is into the stable branches of 12 and 13, but not
that straight-forward either as we had the bad idea to use the
fallback MD5 implementation even if linking to OpenSSL in v12 and v13,
meaning that you may need some tweaks to avoid API conflicts.

Requiring OpenSSL and its HMAC APIs to do the job is much safer for a
stable branch, IMO.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vitaly Davydov 2024-08-06 06:41:12 Fsync (flush) all inserted WAL records
Previous Message Amul Sul 2024-08-06 05:57:08 Re: pg_verifybackup: TAR format backup verification