[patch] various pkg audit issues

[Matthew Seaman]

On 16/08/2013 13:24, Michael Gmelin wrote:
> 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

Thanks for the patch.  I'll have a look at this over the weekend.

I agree that next day alert to any new vulnerabilities are desirable
nowadays.  And your comments about checking the CREATED header are valid
too.

	Cheers,

	Matthew

PS.  While we are happy to receive feedback by any channel, opening an
issue on GitHub is our preferred mechanism: we can't miss that, and it
won't get accidentally forgotten.