Re: FreeBSD-kernel-13.4_1 is vulnerable

On 2024-12-03 00:29:22 (+0800), Dan Langille wrote:
> In this reply, I have cc'd philip@ - we have discussed this issue over 
> the years.
>
> On Fri, Nov 29, 2024, at 4:05 AM, Jos Chrispijn wrote:
>> Not sure if I oversee an update, but still get this message
>>
>> Checking for security vulnerabilities in base (userland & kernel):
>> Database fetched: 2024-11-27T23:30+01:00
>> FreeBSD-kernel-13.4_1 is vulnerable:
>>   FreeBSD -- Unbounded allocation in ctl(4) CAM Target Layer
>>   CVE: CVE-2024-39281
>>   WWW: 
>> https://vuxml.FreeBSD.org/freebsd/8caa5d60-a174-11ef-9a62-002590c1f29c.html
>>
>> Understand that for FreeBSD 14 this issue has been solved.
>> Can you tell me when a fix will be released for 13.4?
>
> I have the same issue with FreeBSD 14.1-RELEASE-p5 - the problem is 
> not (in this case) an unpatched system. It is a false positive. The 
> vuxml database seems to relate only to kernel vulns, and is not aware 
> that sometimes a vuln affects userland.  In this case, the userland is 
> vuln (and patched) - pkg-base-audit is unaware of that.
>
> To me, it is important to fix the problem because false positives 
> develop into alert fatigue and cause unnecessary work.
>
> [16:16 r730-01 dvl ~] % sudo 
> /usr/local/etc/periodic/security/405.pkg-base-audit
>
> Checking for security vulnerabilities in base (userland & kernel):
> Host system:
> vulnxml file up-to-date
> FreeBSD-kernel-14.1_5 is vulnerable:
>   FreeBSD -- Unbounded allocation in ctl(4) CAM Target Layer
>   CVE: CVE-2024-39281
>   WWW: 
> https://vuxml.FreeBSD.org/freebsd/8caa5d60-a174-11ef-9a62-002590c1f29c.html 
> <https://vuxml.freebsd.org/freebsd/8caa5d60-a174-11ef-9a62-002590c1f29c.html>
>
> [16:17 r730-01 dvl ~] % pkg which 
> /usr/local/etc/periodic/security/405.pkg-base-audit
> /usr/local/etc/periodic/security/405.pkg-base-audit was installed by 
> package pkg-1.21.3
>
> The problem is the kernel version and user version differ:
>
> [16:17 r730-01 dvl ~] % freebsd-version -u
> 14.1-RELEASE-p6
> [16:17 r730-01 dvl ~] %
>
> I believe the problem is with the 405.pkg-base-audit which is looking 
> only at the kernel version:
>
> [16:18 r730-01 dvl ~] % freebsd-version -k
> 14.1-RELEASE-p5
>
> ... not knowing that the vuln is in the userland, not the kernel.
>
> My wild idea here:
>
> * indicate with each vuln: userland or kernel?
> * when checking for a vuln, consult the above new flag and check the 
> appropriate value
>
> Phillip: is my idea wildly offbase?

You're not wrong.  But the reasoning is incomplete.

The issue at hand is a vulnerability in a kernel module that is not part 
of GENERIC.  The freebsd-update build machinery only rebuilds the bits 
that are actually vulnerable.  In this case: only the vulnerable kernel 
module.  Nothing changed in the kernel, so freebsd-update doesn't ship a 
new kernel.

405.pkg-base-audit can't know if you've unloaded/reloaded the vulnerable 
module because modules are not versioned -- at least not in a way that 
is useful to userland.  There is nothing that 405.pkg-base-audit to look 
at.

We discussed this issue again during yesterday's secteam fortnightly 
call.

Very long-term, freebsd-update will go away and be replaced by pkgbase.

Meanwhile, we do need a long-term solution because freebsd-update will 
still be with us until the end of stable/15's support lifetime (i.e. 
several years).

We plan to remove the witchcraft in the freebsd-update build system that 
prevents shipping a new kernel binary when only a module is updated.

The downside is that freebsd-update will ship a new kernel even if only 
a module not included in GENERIC is vulnerable.  We'll make a note of 
that in the workarounds / mitigations section of the advisory texts.

On the whole, false negatives are a lot better than false positives 
here.  We'd rather people boot into a new kernel even if their old one 
wasn't strictly vulnerable, than people get alert fatigue from false 
positives they can't silence except in their monitoring.

Unfortunately, we won't be able to get a freebsd-update build patch 
working before the end of the year.  We don't want to release something 
just before the upcoming end-of-year holidays in many parts of the 
world.  We'll try to have this done early in January.

Philip