Bug 245878 - security/vuxml ipfw invalid mbuf handling creates false positive with base-audit
Summary: security/vuxml ipfw invalid mbuf handling creates false positive with base-audit
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Ports Security Team
Depends on:
Reported: 2020-04-24 14:23 UTC by Dan Langille
Modified: 2020-10-15 01:00 UTC (History)
7 users (show)

See Also:
bugzilla: maintainer-feedback? (ports-secteam)


Note You need to log in before you can comment on or make changes to this bug.
Description Dan Langille freebsd_committer 2020-04-24 14:23:16 UTC
re https://lists.freebsd.org/pipermail/svn-ports-all/2020-April/249659.html

The FreeBSD-SA-20:10.ipfw entry in vuxml is causing false positives for security/base-audit

To reproduce:

freebsd-update fetch install
pkg install base-audit
add security_status_baseaudit_enable="YES" to /etc/periodic.conf
pkg audit -F

$ freebsd-version -uk

$ /usr/local/etc/periodic/security/405.pkg-base-audit

Checking for security vulnerabilities in base (userland & kernel):
Host system:
Database fetched: Wed Apr 22 11:30:00 UTC 2020
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

1 problem(s) in 1 installed package(s) found.
0 problem(s) in 0 installed package(s) found.
Comment 1 Dan Langille freebsd_committer 2020-04-24 14:24:49 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.
Comment 2 PauAmma freebsd_triage 2020-04-24 16:52:41 UTC
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
Comment 3 Dan Langille freebsd_committer 2020-05-01 14:48:35 UTC
It has been suggested that if something in the kernel changes, a new kernel is shipped.

What is involved in achieving that solution?
Comment 4 Jochen Neumeister freebsd_committer 2020-05-23 11:59:05 UTC
(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?
Comment 5 Dan Langille freebsd_committer 2020-05-23 12:06:08 UTC
ports-secteam@FreeBSD.org is not sufficient?
Comment 6 Dan Langille freebsd_committer 2020-05-23 12:07:09 UTC
(In reply to Dan Langille from comment #5)

Also, gordon@FreeBSD.org is on this ticket (see CC list).
Comment 7 Jochen Neumeister freebsd_committer 2020-05-23 12:08:36 UTC
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.
Comment 8 Jochen Neumeister freebsd_committer 2020-05-23 12:09:34 UTC
(In reply to Dan Langille from comment #6)

I added him a few minutes ago :-)
Comment 9 Philip Paeps freebsd_committer 2020-07-10 06:05:47 UTC
Is this still a problem?
Comment 10 PauAmma freebsd_triage 2020-07-10 10:49:49 UTC
(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.
Comment 11 Philip Paeps freebsd_committer 2020-07-10 10:53:41 UTC
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?
Comment 12 PauAmma freebsd_triage 2020-07-10 11:03:01 UTC
(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.)
Comment 13 Dan Langille freebsd_committer 2020-07-10 12:21:51 UTC
This specific issue no longer exist.

I agree with comment #10: this will recur.
Comment 14 Dan Langille freebsd_committer 2020-09-17 22:41:41 UTC
This situtation has arised again with the latest set of patches:

see https://lists.freebsd.org/pipermail/freebsd-stable/2020-September/092699.html
Comment 15 Philip Paeps freebsd_committer 2020-09-17 23:25:52 UTC
(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.
Comment 16 Dan Langille freebsd_committer 2020-09-17 23:38:07 UTC
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."
Comment 17 Ed Maste freebsd_committer 2020-09-19 15:52:00 UTC
(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.
Comment 18 Philip Paeps freebsd_committer 2020-09-20 00:08:55 UTC
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 -->

<!-- affects only amd64 -->
  <name>FreeBSD-kernel (amd64)</name>

<!-- affects only amd64 and aarch64 -->
  <name>FreeBSD-kernel (amd64, aarch64)</name>

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.
Comment 19 PauAmma freebsd_triage 2020-09-20 05:42:34 UTC
(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.
Comment 20 Dan Langille freebsd_committer 2020-10-14 15:49:26 UTC
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.
Comment 21 PauAmma freebsd_triage 2020-10-14 20:57:19 UTC
(In reply to Dan Langille from comment #20)

100% agreed. (Assuming you meant "the more likely".)
Comment 22 Philip Paeps freebsd_committer 2020-10-15 01:00:58 UTC
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).