[Pkg-freeradius-maintainers] Bug#1076022: Backport some security settings from upstream 3.2.5 release to mitigate BlastRADIUS

[Herwin Weststrate]

On Tue, Jul 09, 2024 at 11:44:58PM +0200, Bernhard Schmidt wrote:
> Control: tags -1 help security
> 
> Am 09.07.24 um 18:15 schrieb Herwin Weststrate:
> > Package: freeradius
> > Version: 3.2.1+dfsg-4+deb12u1
> > 
> > FreeRADIUS 3.2.5 has just been released, which includes some security
> > fixes for BlastRADIUS: a vulnerability with a name and a website[0] and
> > a logo (hadn't seen one of those in a while).
> > 
> > The FreeRADIUS security page[1] (scroll to "2024.07.09", there is no
> > anchor to link directly to the relevant article) describes some new
> > configuration options to resolve everything. Since this will be the
> > first thing people read, it would be nice to have those backported to
> > the Debian packages.
> > 
> > At first glance, it looks like this requires just two commits[2] [3] to
> > be cherry-picked, but there may be some hidden dependencies in previous
> > commits.
> 
> > [2] https://github.com/FreeRADIUS/freeradius-server/commit/0947439f2569d2b8c2b4949be24250263934e260
> > [3] https://github.com/FreeRADIUS/freeradius-server/commit/6616be90346beb6050446bd00c8ed5bca1b8ef29
> 
> I haven't looked closer yet, but the patches do not apply at all
> 
> Given that the freeradius codebase is really complicated I'm not entirely
> sure whether we can do this (_I_ can't), or ask the security team for a
> newer upstream version in stable.

I looked a bit deeper into it: there was a lot more needed than just
these two commits. Pretty much every commit of July 8 was relevant.

I've created a new git repo where I imported the extracted Debian
package, added the upstream repository as a new remote, and git
cherry-picked every commit of that day except for the changelogs and the
CentOS CI updates. The conflicts were all related to missing code that
has been added in recent upstream versions and pretty easy to fix. The
result is this 2500 line behemoth of `git log -p`. I tested it with the
user `bob` enabled (the default test user of FreeRADIUS) and setting
`require_message_authenticator = auto` and using a different machine to
send requests to it. The `auto` settings looks to be working: if I start
with an `Access-Request` with no `Message-Authenticator` attribute, the
logging of FreeRADIUS shows this client is vulnerable and further
checking will be disabled. After a restart of the server and sending an
`Access-Request` with the `Message-Authenticator` attribute the client
will have checking enabled, and sending a next request without the
attribute will result in the package being dropped. Replies of the
server now always include a `Message-Authenticator` attribute, which
they did not have before (with the default config). A simple
authentication with 802.1X (PEAP) looked like it's still working as
well.

I have not yet tested the proxy settings, it takes a while to set that
up and I would first like to know if there is a chance that this patch
set will be accepted, if it gets rejected right away for whatever reason
I'd rather save myself the trouble.

All the commits have been cherry-picked in order from the upstream
changes, so a code review can compare these commits side by side.

-- 
Herwin Weststrate
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeradius_debian_blastradius.diff
Type: text/x-diff
Size: 99426 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-freeradius-maintainers/attachments/20240712/e08daea6/attachment-0001.diff>