Date: Tue, 12 Dec 2023 17:34:08 +0800 From: Philip Paeps <philip@freebsd.org> To: Felix Palmen <zirias@freebsd.org> Cc: ports-committers@freebsd.org, dev-commits-ports-all@freebsd.org, dev-commits-ports-main@freebsd.org Subject: Re: git: 4826396e5d15 - main - security/vuxml: correct last SA's affected range Message-ID: <17D0B34D-59E6-4B4F-9642-FE7FA6111A19@freebsd.org> In-Reply-To: <5ykuv4fnes6axn2l7mkuxksknt2b5oqkkuixuunndvgr5zg6yr@h7bxl6ntwkg2> References: <202312070452.3B74qCJr077470@gitrepo.freebsd.org> <4aoxukh3ddhkq3qmo4qi7vpeqo3wpxc6nivrlve67hr7oszr2m@3wydgx5pc7be> <5ykuv4fnes6axn2l7mkuxksknt2b5oqkkuixuunndvgr5zg6yr@h7bxl6ntwkg2>
next in thread | previous in thread | raw e-mail | index | archive | help
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=3Dd20ece445acfc5d29ca096b38e30e= 4c0cb0b0d95 > 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=3D45e256e24c976a55dc856907a5756= 4cbc30cfb60 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17D0B34D-59E6-4B4F-9642-FE7FA6111A19>