[Pkg-freeradius-maintainers] Bug#1076022: Backport some security settings from upstream 3.2.5 release to mitigate BlastRADIUS
Santiago Ruano Rincón
santiagorr at riseup.net
Wed Aug 7 11:08:32 BST 2024
Hi Bernhard,
El 14/07/24 a las 16:15, Salvatore Bonaccorso escribió:
> 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?
Regarding the version in bullseye: upstream has kindly shared with me a
set of patches. I've pushed them to:
https://salsa.debian.org/debian/freeradius/-/tree/wip/debian/blastradius/bullseye.
While they build, I haven't been able to test them (yet). The
autopkgtest job fails, but that is related to a bug in Salsa CI and
systemd when tmp.mount is masked.
Bernhard, are you able to test them? I do not have any experience with
FreeRADIUS, so I could test them, but I would take me some time. Just
let me know if help is needed here.
Cheers,
-- Santiago
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-freeradius-maintainers/attachments/20240807/89a7355d/attachment.sig>
More information about the Pkg-freeradius-maintainers
mailing list