[patch] various pkg audit issues

[Michael Gmelin]

Any feedback / ideas on this?

On Mon, 29 Jul 2013 21:01:22 +0200
Michael Gmelin <freebsd at grem.de> wrote:

> 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