[Pkg-freeradius-maintainers] Bug#1076022: Additional patch for bullseye's FreeRADIUS (was: Backport some security settings from upstream 3.2.5 release to mitigate BlastRADIUS)

[Alan DeKok]

On Aug 23, 2024, at 7:53 AM, Bernhard Schmidt <berni at debian.org> wrote:
> Unfortunately I'm still lacking time, but today I had two unexpected
> consequences.
> 
> A clients.conf entry spanning large subnets was upgraded automatically
> from require_message_authenticator auto -> yes due to the first package
> being received. Consequently messages from another Radius client within
> the same clients.conf entry was dropped silently.

  Yes, clients which aren't /32 should likely be left as `auto`, which really means `no`.

> So far as expected, but I would have assumed FreeRADIUS to log an error
> when a request without Message-Authenticator attribute comes in and it
> is (auto-)configured to expect one. But I did not see anything. Is this
> correct?

  It logs it in debug mode, but not in normal mode.  I suppose that could be changed, but it would have to be rate-limited.

> Another thing to watch out, although I would not want it to be in the
> official changelog/news, Checkpoint Firewalls are known to be broken by
> FreeRADIUS returning a Message-Authenticator attribute, see
> https://support.checkpoint.com/results/sk/sk42184 . Apparently there is
> an internal workaround available, but only to paying users.

  There's a documented work-around.

https://support.checkpoint.com/results/sk/sk182516

  I can only put this down to complete incompetence.  The Message-Authenticator attribute has been defined for about 25 years.  There is *zero* reason to drop packets which contain Message-Authenticator.

  The whole idea of dropping packets which contain unknown attributes is stupid.  After running into this issue, I've updated the "fixing RADIUS security" RFC:

https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius-03#name-unknown-attributes

> I could not find a quick way to disable FreeRADIUS always _sending_ the
> Message-Authenticator header.

  It can't be disabled.  We're not going to make 1,000,000 networks insecure simply because one vendor hasn't updated their RADIUS implementation in 25 years.

  There is a work-around for the checkpoint issue, so additional configuration changes for FreeRADIUS aren't a good idea.

  Alan DeKok.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://alioth-lists.debian.net/pipermail/pkg-freeradius-maintainers/attachments/20240823/619d18ae/attachment.sig>