Bug 245878
| Summary: | security/vuxml ipfw invalid mbuf handling creates false positive with base-audit | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Dan Langille <dvl> |
| Component: | Individual Port(s) | Assignee: | Ports Security Team <ports-secteam> |
| Status: | Closed FIXED | ||
| Severity: | Affects Many People | CC: | allanjude, dvl, emaste, gordon, joneum, pauamma, philip |
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(ports-secteam) |
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Dan Langille
2020-04-24 14:23:16 UTC
This PR is lodged against vuxml only because that is where the entry reside. The issue is that the fix for the vuln did not issue a new kernel. The current situation is continued false positives for base-audit until a new kernel is released. I'm also affected by this bug. Checking for security vulnerabilities in base (userland & kernel): Fetching vuln.xml.bz2: .......... done FreeBSD-kernel-12.1_3 is vulnerable: FreeBSD -- ipfw invalid mbuf handling CVE: CVE-2019-15874 CVE: CVE-2019-5614 WWW: https://vuxml.FreeBSD.org/freebsd/33edcc56-83f2-11ea-92ab-00163e433440.html This despite: % freebsd-version -kru 12.1-RELEASE-p3 12.1-RELEASE-p3 12.1-RELEASE-p4 It has been suggested that if something in the kernel changes, a new kernel is shipped. What is involved in achieving that solution? (In reply to Dan Langille from comment #3) > On Tue, Apr 21, 2020, at 2:29 PM, Gordon Tetlow wrote: > Author: gordon (src committer) so i think, its a good point to ping gordon? ports-secteam@FreeBSD.org is not sufficient? (In reply to Dan Langille from comment #5) Also, gordon@FreeBSD.org is on this ticket (see CC list). if I understand this correctly, it is a problem with the FreeBSD version. This update comes from a src committer. Ports-secteam is responsible for the security of the ports and cannot really help with src releases. (In reply to Dan Langille from comment #6) I added him a few minutes ago :-) Is this still a problem? (In reply to Philip Paeps from comment #9) This specific instance isn't, at least for me, since (IIRC) 12.1-RELEASE-p5, as that bumped both kernel and userland patchlevels. However, I think the root problem (different -p<n> for kernel and userland making it unclear whether the vulnerability is present and causing false positives to err on the side of caution) is still lying in wait for a chance to happen again. It's unclear to me whether Dan Langille's suggestion in comment 3 (a process change) is the solution, or whether a change in base-audit is instead (at the risk of causing false negatives instead, which may be worse)*. Either way, I would leave this open, perhaps with a more current summary like "Differences in kernel and userland output for freebsd-version -kru cause false positives in base-audit" and reclassified into base/(mumble). *: Alternatively, the format of the vuxml database could be changed to allow stating explicitly which of the kernel version or the userland version should be tested, but I'm unclear about both its backward compatibility and the consequences for ports vulnerability testing, so I'm reluctant to push that option forward. Changing the state from New to Open. The kernel's -pX will only change if an update is shipped that affects the kernel. `freebsd-version -k` will show the version of the *installed* kernel, `uname -r` will show the version of the *running* kernel. Perhaps base-audit is confused about installed/running? (In reply to Philip Paeps from comment #11) Or I could have got the -k and -r freebsd-version flags mixed up. (Anyway, the problem also happens when -k and -r output is the same, see my comment #2.) This specific issue no longer exist. I agree with comment #10: this will recur. This situtation has arised again with the latest set of patches: see https://lists.freebsd.org/pipermail/freebsd-stable/2020-September/092699.html (Opening this again.) Is this only happening on i386? This is very strange. I thought the freebsd-update builds updated the kernel to the same version everywhere. It could be that the reported issues affect only amd64 and therefore an i386 kernel was not produced? [dan@gelt:~] $ sudo /usr/local/etc/periodic/security/405.pkg-base-audit Checking for security vulnerabilities in base (userland & kernel): Host system: Database fetched: Wed Sep 16 07:06:52 UTC 2020 FreeBSD-kernel-12.1_9 is vulnerable: FreeBSD -- bhyve SVM guest escape CVE: CVE-2020-7467 WWW: https://vuxml.FreeBSD.org/freebsd/e73c688b-f7e6-11ea-88f8-901b0ef719ab.html "A number of AMD virtualization instructions operate on host physical addresses, are not subject to nested page table translation, and guest use of these instructions was not trapped." FreeBSD-kernel-12.1_9 is vulnerable: FreeBSD -- bhyve privilege escalation via VMCS access CVE: CVE-2020-24718 WWW: https://vuxml.FreeBSD.org/freebsd/2c5b9cd7-f7e6-11ea-88f8-901b0ef719ab.html "AMD and Intel CPUs support hardware virtualization using specialized data structures that control various aspects of guest operation." FreeBSD-kernel-12.1_9 is vulnerable: FreeBSD -- ure device driver susceptible to packet-in-packet attack CVE: CVE-2020-7464 WWW: https://vuxml.FreeBSD.org/freebsd/bb53af7b-f7e4-11ea-88f8-901b0ef719ab.html "A programming error in the ure(4) device driver caused some Realtek USB Ethernet interfaces to incorrectly report packets with more than 2048 bytes in a single USB transfer as having a length of only 2048 bytes." (In reply to Philip Paeps from comment #15) This will happen when there are kernel changes that do not affect the kernel itself (i.e., affected code is entirely within kernel modules), or the change is machine-dependent and does not affect all architectures. This will become more of a problem as we start producing updates for arm64. Two suggestions came up when we chatted about this yesterday: 1. Distribute a VERSION file with the kernel 2. Always rebuild the kernel Both of these suggestions have downsides though. The first would silence base-audit but if a vulnerable platform hasn't been rebooted, the system would still be vulnerable. The second would require a reboot even on systems that aren't vulnerable. The real problem is that base-audit doesn't know whether the FreeBSD-kernel package for a specific platform is affected. We could encode this information in vuxml though. E.g.: <!-- affects all platforms --> <package> <name>FreeBSD-kernel</name> </package> <!-- affects only amd64 --> <package> <name>FreeBSD-kernel (amd64)</name> </package> <!-- affects only amd64 and aarch64 --> <package> <name>FreeBSD-kernel (amd64, aarch64)</name> </package> This solution would require base-audit to become smarter about parsing the package name. We could also add a <platform/> tag or something. But I have no idea how the vuxml format is specified and how different parsers would react to such a change. (In reply to Philip Paeps from comment #18) Your second suggestion (which to me sounds like comment #3) feels better than your first to me. Rebooting occasionally when not needed sounds better than alert fatigue, which can lead to ignoring alerts and therefore not updating or rebooting a system that *is* vulnerable. Also, it seems to me that the initial issue (about the ipfw module) could only be solved by adding a modules patchlevel to the current kernel and userland ones. It's different from the current problem (different kernel patchlevels between architectures) which may require adding a mention of the architecture to the parsable vuxml file as you indicated. What group needs to decide this? The longer it takes to decide upon a solution which removes false positives, the less likely we are to leave users vulnerable to a real issue due to alert fatigue. (In reply to Dan Langille from comment #20) 100% agreed. (Assuming you meant "the more likely".) The security team can decide to rebuild the kernel for all platforms even if only a subset is affected. I can put that on the agenda for our next fortnightly meeting. base-audit is not part of the FreeBSD base system. Any decisions about it would be on its author(s). (In reply to Philip Paeps from comment #22) Did anything come from that meeting regarding this issue? FYI, this is day 57d of a false positive. No. Nothing came of it. (In reply to Philip Paeps from comment #24) I will disable the security alert on this i386 box. I can't wait until either another vuln is fixed or the box is upgraded to 12.2 Alert fatigue is real. I understand. I'll bring up the suggestion to rebuild kernels for unaffected platforms again for the next batch of advisories that affect one platform. I don't believe there is anything else I can do at this stage. The circle is completed. I opened a security/base-audit PR and it is being suggested that the vuxml entry is wrong. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251790 |