Bug 241931 - security/vuxml: Add November FreeBSD Security Advisories SA-19:25 and SA-19:26
Summary: security/vuxml: Add November FreeBSD Security Advisories SA-19:25 and SA-19:26
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Dave Cottlehuber
URL:
Keywords: needs-patch
Depends on:
Blocks:
 
Reported: 2019-11-12 23:24 UTC by Miroslav Lachman
Modified: 2019-12-06 12:12 UTC (History)
5 users (show)

See Also:
joneum: maintainer-feedback+


Attachments
FreeBSD SA entries (3.40 KB, patch)
2019-11-12 23:24 UTC, Miroslav Lachman
no flags Details | Diff
pass make validate (3.85 KB, patch)
2019-11-21 19:16 UTC, Dave Cottlehuber
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Miroslav Lachman 2019-11-12 23:24:02 UTC
Created attachment 209119 [details]
FreeBSD SA entries

Add new FreeBSD SA entries in to vuln.xml

Port security/base-audit depends on SA entries in vuln.xml. Pleases commit this soon.
Comment 1 Dave Cottlehuber freebsd_committer 2019-11-21 19:16:00 UTC
Created attachment 209326 [details]
pass make validate

Miroslav this patch doesn't apply cleanly to the tree, and doesn't pass `make validate` in a couple of places.

I attached a tweaked version, can you confirm the FreeBSD-kernel version details are what you wanted, and confirm?

feel free to ping me on IRC if you want for a quick turnaround.
Comment 2 Miroslav Lachman 2019-11-21 23:43:52 UTC
(In reply to Dave Cottlehuber from comment #1)
I am sorry for errors in my patch. It was fast converted from plain text to XML by my shellscript. I should pay better attention and check it for errors like this.
I will improve my shellscript and run 'make validate' next time.

Also I was not sure if 'Intel CPU Microcode Update' (SA-19:26.mcu) should be named as 'FreeBSD-kernel' or just 'FreeBSD', because it is not fix for FreeBSD kernel part. I am not the right person to decide it. :)

Other than that everything seems good to me. You can commit your fixed version.

Thank you for your time.
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2019-11-25 00:55:11 UTC
^Triage: Leave ports-secteam (maintainer) CC'd
Comment 4 Jochen Neumeister freebsd_committer 2019-11-25 09:27:03 UTC
When "make validate" is okay, Approved from ports-secteam (joneum)
Comment 5 Dave Cottlehuber freebsd_committer 2019-11-25 21:45:43 UTC
Many thanks Miroslav for your contribution!
Comment 6 commit-hook freebsd_committer 2019-11-25 21:45:48 UTC
A commit references this bug:

Author: dch
Date: Mon Nov 25 21:45:07 UTC 2019
New revision: 518430
URL: https://svnweb.freebsd.org/changeset/ports/518430

Log:
  security/vuxml: add FreeBSD kernel entries for recent Intel CVEs

  PR:		241931
  Submitted by:	Miroslav Lachman <000.fbsd@quip.cz>
  Reviewed by:	dch
  Approved by:	joneum (ports-secteam)
  Security:	CVE-2019-11135
  Security:	CVE-2019-11139
  Security:	CVE-2018-12126
  Security:	CVE-2018-12127
  Security:	CVE-2018-12130
  Security:	CVE-2018-11091
  Security:	CVE-2017-5715
  Security:	CVE-2018-12207
  Sponsored by:	SkunkWerks, GmbH

Changes:
  head/security/vuxml/vuln.xml
Comment 7 Ben Woods freebsd_committer 2019-12-01 00:12:26 UTC
Hi Miroslav and Dave,

I think there are a couple of issues with this VuXML entry:

1. They report your system as being vulnerable if your kernel is 12.0 and less than patch level -p12. Whilst this works on amd64, the latest patch level on i386 is -p10, so it is impossible to get the system to report as not being vulnerable. This was reported by Dan Langille on Twitter [1].

2. I could be wrong, but I don't think this vulnerability is related to the kernel or base system at all. The first entry [2] mentions that the sysutils/devcpu-data port needs to be at 1.26 in order to remediate this - perhaps this entry should be related to the port version? Interestingly, if the port is not installed it is likely the machine is vulnerable... so that is not quite correct either.

[1] https://twitter.com/DLangille/status/1200808567617523715?s=20
[2] http://www.vuxml.org/freebsd/fbe10a8a-05a1-11ea-9dfa-f8b156ac3ff9.html
[3] http://www.vuxml.org/freebsd/edc0bf7e-05a1-11ea-9dfa-f8b156ac3ff9.html
Comment 8 Ben Woods freebsd_committer 2019-12-01 00:16:49 UTC
# freebsd-update fetch
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 12.0-RELEASE from update4.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 12.0-RELEASE-p12.

# freebsd-version -ku
12.0-RELEASE-p10
12.0-RELEASE-p12

# uname -a
FreeBSD test-12i386 12.0-RELEASE-p10 FreeBSD 12.0-RELEASE-p10 GENERIC  i386


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

Checking for security vulnerabilities in base (userland & kernel):
Database fetched: Sun Dec  1 07:59:46 AWST 2019
FreeBSD-kernel-12.0_10 is vulnerable:
FreeBSD -- Machine Check Exception on Page Size Change
CVE: CVE-2018-12207
WWW: https://vuxml.FreeBSD.org/freebsd/edc0bf7e-05a1-11ea-9dfa-f8b156ac3ff9.html

FreeBSD-kernel-12.0_10 is vulnerable:
FreeBSD -- Intel CPU Microcode Update
CVE: CVE-2017-5715
CVE: CVE-2018-11091
CVE: CVE-2018-12130
CVE: CVE-2018-12127
CVE: CVE-2018-12126
CVE: CVE-2019-11139
CVE: CVE-2019-11135
WWW: https://vuxml.FreeBSD.org/freebsd/fbe10a8a-05a1-11ea-9dfa-f8b156ac3ff9.html

2 problem(s) in 1 installed package(s) found.
0 problem(s) in 0 installed package(s) found.
Comment 9 Miroslav Lachman 2019-12-01 09:35:15 UTC
(In reply to Ben Woods from comment #8)
Yes, you are correct but the problem is in the original Security Advisory [0]. As it is not vulnerability in base nor kernel there are no way to detect / report it 100% correctly. Even if package devcpu-data is installed the machine can still be vulnerable. This issue is HW issue.
In vuxml we can 
1) report it for a short time just by detecting version of FreeBSD and do not report it for newer versions
2) or do not report issues like this at all (remove it from vuxml)

Vuxml always requires some version comparison, base OS, or package version, but this issue is not related to OS / pkg version.

[0] https://www.freebsd.org/security/advisories/FreeBSD-SA-19:26.mcu.asc
Comment 10 Dan Langille freebsd_committer 2019-12-01 14:12:56 UTC
If the purpose of a vuxml entry is to raise action on the system owner, what action should be taken?

If there is no action to be taken, what purpose does the vuxml entry serve?

At present I have this issue and I do not know how to clear it.

[dan@gelt:~] $ 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-12.0_10 is vulnerable:
FreeBSD -- Machine Check Exception on Page Size Change
CVE: CVE-2018-12207
WWW: https://vuxml.FreeBSD.org/freebsd/edc0bf7e-05a1-11ea-9dfa-f8b156ac3ff9.html

FreeBSD-kernel-12.0_10 is vulnerable:
FreeBSD -- Intel CPU Microcode Update
CVE: CVE-2017-5715
CVE: CVE-2018-11091
CVE: CVE-2018-12130
CVE: CVE-2018-12127
CVE: CVE-2018-12126
CVE: CVE-2019-11139
CVE: CVE-2019-11135
WWW: https://vuxml.FreeBSD.org/freebsd/fbe10a8a-05a1-11ea-9dfa-f8b156ac3ff9.html

2 problem(s) in 1 installed package(s) found.
vulnxml file up-to-date
0 problem(s) in 0 installed package(s) found.
[dan@gelt:~] $
Comment 11 Miroslav Lachman 2019-12-01 21:06:26 UTC
(In reply to Dan Langille from comment #10)
What version are you running? (uname -srmi)
Even if we are not talking about SA 19:26, your version seems to be 12.0-p10 which is vulnerable to SA 16:25, fixed in 12.0-p12

Your system (kernel) was detected as FreeBSD-kernel-12.0_10 which is lower than fixed FreeBSD-kernel-12.0_12

If there is some difference between i386 and amd64 systems, then
SA 19:25 https://www.freebsd.org/security/advisories/FreeBSD-SA-19:25.mcepsc.asc
does not mentioned it.
"Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility"

And vuxml entries does not differentiate between architectures.

If arch should be included in to version check, then virtual package name must be expanded from FreeBSD-kernel to FreeBSD-kernel-i386, FreeBSD-kernel-amd64 and so on.

PS: you can run 
sh -x /usr/local/etc/periodic/security/405.pkg-base-audit
to see what is going on under the hood of 405.pkg-base-audit
It is very simple conversion from 'freebsd-version -k' which does not contain arch identification, to virtual package name in a format like FreeBSD-kernel-12.0_12 which can be compared to data from vuxml.
Comment 12 Dan Langille freebsd_committer 2019-12-01 21:15:29 UTC
(In reply to Miroslav Lachman from comment #11)

What version are you running? 

$ uname -srmi
FreeBSD 12.0-RELEASE-p10 i386 GENERIC


[dan@gelt:~] $ sh -x /usr/local/etc/periodic/security/405.pkg-base-audit
+ [ -r /etc/defaults/periodic.conf ]
+ . /etc/defaults/periodic.conf
+ periodic_conf_files='/etc/periodic.conf /etc/periodic.conf.local'
+ local_periodic=/usr/local/etc/periodic
+ anticongestion_sleeptime=3600
+ daily_output=root
+ daily_show_success=YES
+ daily_show_info=YES
+ daily_show_badconfig=NO
+ daily_clean_disks_enable=NO
+ daily_clean_disks_files='[#,]* .#* a.out *.core *.CKP .emacs_[0-9]*'
+ daily_clean_disks_days=3
+ daily_clean_disks_verbose=YES
+ daily_clean_tmps_enable=NO
+ daily_clean_tmps_dirs=/tmp
+ daily_clean_tmps_days=3
+ daily_clean_tmps_ignore='.X*-lock .X11-unix .ICE-unix .font-unix .XIM-unix'
+ daily_clean_tmps_ignore='.X*-lock .X11-unix .ICE-unix .font-unix .XIM-unix quota.user quota.group .snap'
+ daily_clean_tmps_ignore='.X*-lock .X11-unix .ICE-unix .font-unix .XIM-unix quota.user quota.group .snap .sujournal'
+ daily_clean_tmps_verbose=YES
+ daily_clean_preserve_enable=YES
+ daily_clean_preserve_days=7
+ daily_clean_preserve_verbose=YES
+ daily_clean_msgs_enable=YES
+ daily_clean_msgs_days=''
+ daily_clean_rwho_enable=YES
+ daily_clean_rwho_days=7
+ daily_clean_rwho_verbose=YES
+ daily_clean_hoststat_enable=YES
+ daily_backup_passwd_enable=YES
+ daily_backup_aliases_enable=YES
+ daily_calendar_enable=NO
+ daily_accounting_enable=YES
+ daily_accounting_compress=NO
+ daily_accounting_flags=-q
+ daily_accounting_save=3
+ daily_news_expire_enable=YES
+ daily_status_disks_enable=YES
+ daily_status_disks_df_flags='-l -h'
+ daily_status_graid_enable=NO
+ daily_status_zfs_enable=NO
+ daily_status_zfs_zpool_list_enable=YES
+ daily_status_gmirror_enable=NO
+ daily_status_graid3_enable=NO
+ daily_status_gstripe_enable=NO
+ daily_status_gconcat_enable=NO
+ daily_status_mfi_enable=NO
+ daily_status_network_enable=YES
+ daily_status_network_usedns=YES
+ daily_status_network_netstat_flags=-d
+ daily_status_uptime_enable=YES
+ daily_status_mailq_enable=YES
+ daily_status_mailq_shorten=NO
+ daily_status_include_submit_mailq=YES
+ daily_status_security_enable=YES
+ daily_status_security_inline=NO
+ daily_status_security_output=root
+ daily_status_mail_rejects_enable=YES
+ daily_status_mail_rejects_logs=3
+ daily_status_mail_rejects_shorten=NO
+ daily_ntpd_leapfile_enable=YES
+ daily_status_ntpd_enable=NO
+ daily_queuerun_enable=YES
+ daily_submit_queuerun=YES
+ daily_status_world_kernel=YES
+ daily_scrub_zfs_enable=NO
+ daily_scrub_zfs_pools=''
+ daily_scrub_zfs_default_threshold=35
+ daily_local=/etc/daily.local
+ weekly_output=root
+ weekly_show_success=YES
+ weekly_show_info=YES
+ weekly_show_badconfig=NO
+ weekly_locate_enable=YES
+ weekly_whatis_enable=YES
+ weekly_noid_enable=NO
+ weekly_noid_dirs=/
+ weekly_status_security_enable=YES
+ weekly_status_security_inline=NO
+ weekly_status_security_output=root
+ weekly_local=/etc/weekly.local
+ monthly_output=root
+ monthly_show_success=YES
+ monthly_show_info=YES
+ monthly_show_badconfig=NO
+ monthly_accounting_enable=YES
+ monthly_status_security_enable=YES
+ monthly_status_security_inline=NO
+ monthly_status_security_output=root
+ monthly_local=/etc/monthly.local
+ security_show_success=YES
+ security_show_info=YES
+ security_show_badconfig=NO
+ security_status_logdir=/var/log
+ security_status_diff_flags='-b -u'
+ security_status_chksetuid_enable=YES
+ security_status_chksetuid_period=daily
+ security_status_neggrpperm_enable=YES
+ security_status_neggrpperm_period=daily
+ security_status_chkmounts_enable=YES
+ security_status_chkmounts_period=daily
+ security_status_noamd=NO
+ security_status_chkuid0_enable=YES
+ security_status_chkuid0_period=daily
+ security_status_passwdless_enable=YES
+ security_status_passwdless_period=daily
+ security_status_logincheck_enable=YES
+ security_status_logincheck_period=daily
+ security_status_ipfwdenied_enable=YES
+ security_status_ipfwdenied_period=daily
+ security_status_ipfdenied_enable=YES
+ security_status_ipfdenied_period=daily
+ security_status_pfdenied_enable=YES
+ security_status_pfdenied_period=daily
+ security_status_ipfwlimit_enable=YES
+ security_status_ipfwlimit_period=daily
+ security_status_ipf6denied_enable=YES
+ security_status_ipf6denied_period=daily
+ security_status_kernelmsg_enable=YES
+ security_status_kernelmsg_period=daily
+ security_status_loginfail_enable=YES
+ security_status_loginfail_period=daily
+ security_status_tcpwrap_enable=YES
+ security_status_tcpwrap_period=daily
+ [ -z '' ]
+ source_periodic_confs_defined=yes
+ source_periodic_confs
+ local i sourced_files
+ sourced_files=:/etc/periodic.conf:
+ [ -r /etc/periodic.conf ]
+ . /etc/periodic.conf
+ daily_clean_hoststat_enable=NO
+ daily_status_mail_rejects_enable=NO
+ daily_status_include_submit_mailq=NO
+ daily_submit_queuerun=NO
+ daily_status_gmirror_enable=YES
+ daily_status_smart_devices='/dev/ada1 /dev/ada0'
+ monthly_statistics_enable=YES
+ monthly_statistics_report_devices=YES
+ monthly_statistics_report_ports=YES
+ security_status_baseaudit_enable=YES
+ pkg_jails='*'
+ sourced_files=:/etc/periodic.conf::/etc/periodic.conf.local:
+ [ -r /etc/periodic.conf.local ]
+ : YES
+ : daily
+ : NO
+ :
+ : 19376.html bareos bin check_mqttwarn check_snmp_pkgvuln.tar curator-Makefile curator-distinfo curator-pkg-descr db-specific.conf freebsddiary.org.tar.gz globals.sql mail ntp.conf.pure supfiles tmp traffic
+ : 2
+ pkgcmd=/usr/local/sbin/pkg
+ /usr/local/sbin/pkg config PKG_DBDIR
+ PKG_DBDIR=/var/db/pkg
+ auditfile=/var/db/pkg/vuln.xml
+ security_daily_compat_var security_status_baseaudit_enable
+ local 'var=security_status_baseaudit_enable' dailyvar value
+ dailyvar=daily_status_security_baseaudit_enable
+ periodvar=security_status_baseaudit_period
+ eval 'value="$daily_status_security_baseaudit_enable"'
+ value=''
+ [ -z '' ]
+ return
+ security_daily_compat_var security_status_baseaudit_quiet
+ local 'var=security_status_baseaudit_quiet' dailyvar value
+ dailyvar=daily_status_security_baseaudit_quiet
+ periodvar=security_status_baseaudit_quietperiod
+ eval 'value="$daily_status_security_baseaudit_quiet"'
+ value=''
+ [ -z '' ]
+ return
+ security_daily_compat_var security_status_baseaudit_chroots
+ local 'var=security_status_baseaudit_chroots' dailyvar value
+ dailyvar=daily_status_security_baseaudit_chroots
+ periodvar=security_status_baseaudit_chrootsperiod
+ eval 'value="$daily_status_security_baseaudit_chroots"'
+ value=''
+ [ -z '' ]
+ return
+ security_daily_compat_var security_status_baseaudit_jails
+ local 'var=security_status_baseaudit_jails' dailyvar value
+ dailyvar=daily_status_security_baseaudit_jails
+ periodvar=security_status_baseaudit_jailsperiod
+ eval 'value="$daily_status_security_baseaudit_jails"'
+ value=''
+ [ -z '' ]
+ return
+ security_daily_compat_var security_status_baseaudit_exipiry
+ local 'var=security_status_baseaudit_exipiry' dailyvar value
+ dailyvar=daily_status_security_baseaudit_exipiry
+ periodvar=security_status_baseaudit_exipiryperiod
+ eval 'value="$daily_status_security_baseaudit_exipiry"'
+ value=''
+ [ -z '' ]
+ return
+ rc=0
+ check_yesno_period security_status_baseaudit_enable
+ local 'var=security_status_baseaudit_enable' periodvar value period
+ eval 'value="$security_status_baseaudit_enable"'
+ value=YES
+ periodvar=security_status_baseaudit_period
+ eval 'period="$security_status_baseaudit_period"'
+ period=daily
+ return 0
+ echo

+ echo 'Checking for security vulnerabilities in base (userland & kernel):'
Checking for security vulnerabilities in base (userland & kernel):
+ /usr/local/sbin/pkg -N
+ q=''
+ audit_base_all
+ local rc
+ local last_rc
+ local jails
+ [ -n '' -o -n '*' ]
+ echo 'Host system:'
Host system:
+ audit_base '' ''
+ local 'pkgargs='
+ local 'basedir='
+ local rc
+ local then
+ local now
+ local usrlv
+ local krnlv
+ local strlen
+ local chrootv
+ local jailv
+ local jid
+ echo ''
+ egrep ^-c
+ [ -n '' ]
+ echo ''
+ egrep ^-j
+ [ -n '' ]
+ freebsd-version -u
+ sed 's,^,FreeBSD-,;s,-RELEASE-p,_,;s,-RELEASE$,,'
+ usrlv=FreeBSD-12.0_12
+ stat -f %m /var/db/pkg/vuln.xml
+ then=1574965428
+ date +%s
+ now=1575234836
+ [ 0 -ne 0 -o 172800 -le 270008 ]
+ anticongestion
+ [ -n '' ]
+ [ -f '' ]
+ f=-F
+ echo ''
+ egrep '^-[cj]'
+ sysctl -n security.jail.jailed
+ [ -z '' -a 0 '=' 0 ]
+ freebsd-version -k
+ sed 's,^,FreeBSD-kernel-,;s,-RELEASE-p,_,;s,-RELEASE$,,'
+ krnlv=FreeBSD-kernel-12.0_10
+ /usr/local/sbin/pkg audit -F FreeBSD-kernel-12.0_10
vulnxml file up-to-date
FreeBSD-kernel-12.0_10 is vulnerable:
FreeBSD -- Machine Check Exception on Page Size Change
CVE: CVE-2018-12207
WWW: https://vuxml.FreeBSD.org/freebsd/edc0bf7e-05a1-11ea-9dfa-f8b156ac3ff9.html

FreeBSD-kernel-12.0_10 is vulnerable:
FreeBSD -- Intel CPU Microcode Update
CVE: CVE-2017-5715
CVE: CVE-2018-11091
CVE: CVE-2018-12130
CVE: CVE-2018-12127
CVE: CVE-2018-12126
CVE: CVE-2019-11139
CVE: CVE-2019-11135
WWW: https://vuxml.FreeBSD.org/freebsd/fbe10a8a-05a1-11ea-9dfa-f8b156ac3ff9.html

2 problem(s) in 1 installed package(s) found.
+ rc=1
+ [ 1 -lt 3 ]
+ rc=3
+ /usr/local/sbin/pkg audit -F FreeBSD-12.0_12
vulnxml file up-to-date
0 problem(s) in 0 installed package(s) found.
+ return 3
+ last_rc=3
+ [ 3 -gt 1 ]
+ rc=3
+ jls -q -h name path
+ sed -e 1d -e 's/ /|/'
+ jails=''
+ return 3
+ rc=3
+ exit 3
[dan@gelt:~] $
Comment 13 Miroslav Lachman 2019-12-01 21:24:46 UTC
(In reply to Dan Langille from comment #12)
I am not running 12 nor i386. Was this machine in question updated to the latest version? (by which method?)
Can somebody confirm i386 has different patch level numbers than amd64?
If yes, then original SA-19:25.mcepsc.asc is not clear about it. 
It stated:
Corrected: 2019-11-12 18:13:04 UTC (releng/12.0, 12.0-RELEASE-p12)

It means 12.0-RELEASE-p10 is vulnerable.
Comment 14 Dan Langille freebsd_committer 2019-12-01 21:28:01 UTC
(In reply to Miroslav Lachman from comment #13)

Was this machine in question updated to the latest version? (by which method?)

Yes, via freebsd-update fetch install
Comment 15 Miroslav Lachman 2019-12-01 22:31:24 UTC
(In reply to Dan Langille from comment #14)

According to src [0] it should be built with these variables
TYPE="FreeBSD"
REVISION="12.0"
BRANCH="RELEASE-p12"

If your kernel is not marked as 12.0-p12 then:
1) if was not updated
2) freebsd-update does not has updated kernel
3) freebsd-update has updated kernel but with an old version number

I really don't know why your system is reporting different version than expected.
I am running 11.3, pathed by make buildkernel / installkernel, reported as:
# uname -srmi
FreeBSD 11.3-RELEASE-p5 amd64 GENERIC


# /usr/local/etc/periodic/security/405.pkg-base-audit
Checking for security vulnerabilities in base (userland & kernel):
Host system:
vulnxml file up-to-date
0 problem(s) in 0 installed package(s) found.
vulnxml file up-to-date
0 problem(s) in 0 installed package(s) found.

Do somebody of you know why i386 kernel was not rebuilt on freebsd-update servers or is marked as p10 instead of p12?


[0] https://svnweb.freebsd.org/base/releng/12.0/sys/conf/newvers.sh?revision=354654&view=markup
Comment 16 Dan Langille freebsd_committer 2019-12-04 02:35:11 UTC
(In reply to Miroslav Lachman from comment #15)

[dan@gelt:~] $ date
Wed Dec  4 02:33:10 UTC 2019

[dan@gelt:~] $ uname -srmi
FreeBSD 12.0-RELEASE-p10 i386 GENERIC

[dan@gelt:~] $ sudo freebsd-update fetch install
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 12.0-RELEASE from update2.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 12.0-RELEASE-p12.
No updates are available to install.
[dan@gelt:~] $ 

[dan@gelt:~] $ uname -srmi
FreeBSD 12.0-RELEASE-p10 i386 GENERIC

[dan@gelt:~] $ uptime
 2:34AM  up 3 days, 10:28, 2 users, load averages: 1.30, 0.96, 0.85
[dan@gelt:~] $
Comment 17 Dave Cottlehuber freebsd_committer 2019-12-04 10:42:38 UTC
reopened from Dan & Ben's comments - thanks.

To summarise:

- this patch produces a warning for which there appears to be no remedial actions
- there are no patches for the recent intel vulns for 12.0R (yet)
- the advisory from security officer doesn't single out a specific architecture 
- it is not clear to end users whether this vuln applies to both x86 or x86_64 but in the absence of further information I would assume the worst case

Have I got that right?

I think we have 4 things we can do here:
 
1. Ask SO to clarify the vulnerability's applicability to x86 & update security advisory accordingly.

2. Based on 1, ask if patches for x86 are planned.

3. based on 2, amend vuxml as needed. Let's debate that once 1 & 2 are settled. BTW personally I'm OK with the warning without remedial actions *if* the vulnerability applies, patch or fixes availability notwithstanding. You can (a) stop using the vulnerable platform, (b) upgrade, (c) switch architectures, (d) suck it up and hope nobody notices "security by obscurity". I'd rather be told the emperor has no clothes than not realise.

4. Offer help to the sec team's process, to get these into vuxml as close as possible as when the vulnerabilities are made public, and document & improve this process so that next time it's clear. Don't care if this is paperwork, or XML, but having pkg audit tell me what's at risk is IMO fantastic.

thoughts?
Comment 18 Miroslav Lachman 2019-12-06 12:12:30 UTC
(In reply to Dave Cottlehuber from comment #17)
Yes, I agree.
We need confirmation from SO if i386 is vulnerable or not and if/when it will be patched (why the patch level is -p10 instead of -p12)

Then we need to decide how to handle this case in vuxml and base audit, because arch is not handled by vulxml entries nor pkg-base-audit periodic script.