Re: git: 4826396e5d15 - main - security/vuxml: correct last SA's affected range

On 2023-12-12 17:14:02 (+0800), Felix Palmen wrote:
> * Felix Palmen <zirias@freebsd.org> [20231207 18:48]:
>> * Philip Paeps <philip@FreeBSD.org> [20231207 04:52]:
>>>     FreeBSD-SA-23:17.pf only affects the kernel, not userland.  The 
>>> first
>>>     patch level of the kernel without the vulnerability is 13.2_4, 
>>> not
>>>     13.2_7.
>>
>> Please revert this commit. The first sentence of the message is 
>> correct,
>> the second one is wrong. The fixed kernel has version 
>> 13.2-RELEASE-p7.
>
> The more time passes the less important this will be, but I'm still
> convinced it is wrong and might be dangerous to someone only relying 
> on
> periodic security reports.
>
> I double-checked multiple times, and I see no way how a kernel could
> ever be built with a different version than the one listed in
> sys/conf/newvers.sh. If there *is* a way, please explain how this 
> could
> ever work (and how to ever avoid massive confusion, even for people 
> just
> building their custom kernel).
>
> So given that, the version was bumped to -p4 in
> https://cgit.freebsd.org/src/commit/?id=d20ece445acfc5d29ca096b38e30e4c0cb0b0d95
> on 2023-10-03.
>
> After that, there were no changes to the kernel on releng/13.2 (so its
> version stayed at -p4 when using freebsd-update), *until* commit
> https://cgit.freebsd.org/src/commit/?id=45e256e24c976a55dc856907a57564cbc30cfb60
> on 2023-12-05, fixing this very issue.
>
> I rest my case, there's no way a kernel with version 13.2-RELEASE-p4
> could ever include that fix. Therefore, please correct this, so people
> looking at periodic are properly warned.

vuxml cannot accurately encode the different expectations of 
freebsd-update and kernels built from source.

The issue described by FreeBSD-SA-23:17.pf only affects the pf kernel 
module, not the rest of the kernel.  Consequently, freebsd-update only 
rebuilt pf.ko.  kernel was not rebuilt.

There is no 100% correct way to document this category of 
vulnerabilities in vuxml.  There are three options:

- <package>FreeBSD</package> with the version reported by 
freebsd-version: this incorrectly presents the vulnerability as 
affecting userland.

- <package>FreeBSD-kernel</package> with the version reported by 
freebsd-version: this is how I originally documented the vulnerability.  
Since the kernel was not rebuilt (only pf.ko), systems comparing the 
output of uname -k to the versions in the vuxml document cannot see that 
the system was upgraded.

- <package>FreeBSD-kernel</package> with the version reported by uname 
-k: this is how it is currently documented.  Users who have not upgraded 
anything will not realise they are affected, because uname -k has been 
at -p4 since October.  (As you correctly point out.)

Fundamentally, we cannot completely accurately document vulnerabilities 
that affect individual kernel modules in vuxml.  Perhaps "pkg audit" 
could be extended to look at more things than only "freebsd-version" and 
"uname -k", but there would still be edge cases.

The security-officer team is trying to come up with a way to forcibly 
rebuild the kernel for this category of vulnerabilities.  This is not a 
great solution either though.  It requires users to reboot the system 
whereas (in theory, in many/most cases), unloading and reloading the 
kernel module would address the vulnerability.

The good news is that pkgbase will solve this problem to some extent.  
Kernel modules are distributed in the FreeBSD-kernel package.  While 
"pkg audit" won't be able to determine if the correct module is loaded, 
at least it will be able to see that the correct package has been 
installed.

Philip

-- 
Philip Paeps
Senior Reality Engineer
Alternative Enterprises