Hi, periodic/410.pkg-audit produces inconsistent output depending on if the database has been fetched or not. Since the default db expiry is two days this produces alternating output, e.g.:
Day 1: Checking for packages with security vulnerabilities: subversion-1.7.10 Day 2: Checking for packages with security vulnerabilities: Database fetched: Sun Jul 28 03:02:06 UTC 2013 subversion-1.7.10 is vulnerable: subversion -- remotely triggerable "Assertion failed" DoS vulnerability or read overflow. WWW: http://portaudit.FreeBSD.org/2ae24334-f2e6-11e2-8346-001e8c75030d.html 1 problem(s) in your installed packages found. Day 3: Checking for packages with security vulnerabilities: subversion-1.7.10 And so on. The attached patch (also available at [1]) fixes this by running pkg audit a second time in case a vulnerability has been found on the first (fetching) run. This is merely a workaround, IMHO it would be best to provide a "fetch only" option to pkg audit and do fetching and checking in two separate invocations. The default of two days for daily_status_security_pkgaudit_expiry seems not a good choice, I would suggest to change it to one day, so that the periodic job always uses the latest version of the audit database (you don't want to loose an extra day learning about that remote exploitable vulnerability - anything > one day should be the exception and not the rule at this point). I seems like pkg audit doesn't validate the signature of auditfile after fetching it. I originally introduced this signature to portaudit to mitigate a remote command execution vulnerability (see [2]). The potential for remote code execution is lower compared to ports-mgmt/portaudit, since auditfile is not processed by shell scripts directly - even though its output might be processed by users, not that uncommon. Regardless, checking the signature would be reasonable to ensure that auditfile has not been tampered with, especially since it's fetched using plain http and could get faked quite easily (e.g. DNS spoofing or transparent proxying). It also seems like pkg audit doesn't check the CREATED header of auditfile, therefore it won't complain in case an outdated auditfile is used. This could be used in a malicious way or simply happen by accident in setups where machines, which are not directly connected to the internet, access a copy on the local network that might have stopped receiving updates. By implementing both features, signature and creation timestamp checking, pkg audit would ensure that always a recent and authoritative vulnerability database is used. Michael [1]http://blog.grem.de/0001-Ensure-pkg-audit-periodic-output-consistency.patch [2]http://vuxml.freebsd.org/freebsd/6d329b64-6bbb-11e1-9166-001e4f0fb9b1.html -- Michael Gmelin
>From 7c0f54f48ce411450e5855203c002262c351b45c Mon Sep 17 00:00:00 2001 From: Michael Gmelin <free...@grem.de> Date: Mon, 29 Jul 2013 20:00:54 +0200 Subject: [PATCH] Ensure pkg audit periodic output consistency. --- scripts/periodic/410.pkg-audit.in | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scripts/periodic/410.pkg-audit.in b/scripts/periodic/410.pkg-audit.in index bfcb20e..82f617a 100755 --- a/scripts/periodic/410.pkg-audit.in +++ b/scripts/periodic/410.pkg-audit.in @@ -61,7 +61,10 @@ case "${daily_status_security_pkgaudit_enable:-YES}" in if [ $rc -ne 0 -o \ $(( 86400 \* "${daily_status_security_pkgaudit_expiry:-2}" )) \ -le $(( ${now} - ${then} + 600 )) ]; then - ${pkgcmd} audit -Fq || { rc=$?; [ $rc -lt 3 ] && rc=3; } + ${pkgcmd} audit -Fq > /dev/null || { rc=$?; [ $rc -lt 3 ] && rc=3; } + if [ $rc -eq 3 ]; then + ${pkgcmd} audit || { rc=$?; [ $rc -lt 3 ] && rc=3; } + fi else echo -n 'Database fetched: ' date -r "${then}" || rc=3 -- 1.8.2.3
_______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"