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

[Salvatore Bonaccorso]

Hi Bernhard,

[
On Sat, Jul 13, 2024 at 12:28:34AM +0200, Bernhard Schmidt wrote:
> Am 12.07.24 um 13:34 schrieb Herwin Weststrate:
> 
> Dear Herwin,
> 
> > > > 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).
> 
> [...]
> 
> > > 
> > > 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.
> 
> Thanks a lot for checking this out.
> 
> > 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.
> 
> I'm open to it, but ultimatively it's up to the security team to decide. We
> can either go for this 100k patch cherry-picked from upstream, or ask for
> 3.2.5 in stable. Or ignore it, which is in my opinion still on the table (I
> don't consider BlastRADIUS that bad, but it has a website and a logo so ...)
> 
> @Security Team: What do you think? Herwin did a spectacular job here already
> and I can also offer to get it some life testing in a production
> environment, but in the end we would have to jump into very cold waters.

I do not think this warrants a DSA, but I see one option, OTOH. How
about trying to rebase freeradius to 3.2.5 in the next bookworm point
release in august? Then while the issue will not warrant a DSA, we
still get the implemented mitigations in a future point release of
bookworm.

The same obviously could be done as well via a security update, I
agree with you assessment that it's not that urgent and so such an
update can be batched n the point release and additionally be exposed
to the public via the proposed-upates queues.

Another story is bullseye, that one is affected as well but a backport
there is even harder. For now I have marked it as well no-dsa in the
security-tracker, but maybe it should be <ignored> with mentioning
that backporting patches is too intrusive?

Regards,
Salvatore