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.
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.
(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.
^Triage: Leave ports-secteam (maintainer) CC'd
When "make validate" is okay, Approved from ports-secteam (joneum)
Many thanks Miroslav for your contribution!
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
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
# 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.
(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
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:~] $
(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.
(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:~] $
(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.
(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
(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
(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:~] $
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?
(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.
Today I emailed the SO team.
This problem no longer exists for me.
Is this one still relevant? I just committed the January patch from PR#243702. I'm working on improving the security-officer checklist so vuxml does not get forgotten every time. Thanks for bearing with us. Philip [hat: security-officer secretary]
(In reply to Philip Paeps from comment #21) This one was committed but the information in original SA was not clear (if it is for amd64 only or not) i386 kernel was not updated by freebsd-update (have the same patch level number) and that causes i386 system reported as vulnerable. I think Dan Langille updated his machines with January updates, kernel patch level was changed and vuxml / pkg audit is no more reporting his system as vulnerable to November advisories. Just my guess. I do not run i386. This was problem with original SA rather than vuxml.
(In reply to Miroslav Lachman from comment #22) Yes, that is accurate.
(In reply to Miroslav Lachman from comment #22) There were two SAs: SA-19:26 is a CPU microcode update and we recommend installing that if you are running on real hardware. I don't believe there is a way for vuxml to know if the microcode was updated. The closest approximation is whether the devcpu-data package is up to date. SA-19:25 only affects amd64. As far as I can tell, there is no further action that needs to be taken on this bug so I'll mark it closed/fixed. If there are actionable points on the broader issue (e.g. from comment #17), they should be tracked in separate bug reports.