Idea for quicker CVE patching
What do you say about having the current supported versions of pfSense running "pkg audit -F" daily on your test bench boxes? And sending patch request tickets automagically to the public Redmine instance if CVEs are returned?
Ran that command today again and there's three other CVEs besides the recently json-c patched one for 2.4.5-p1. It's not really fun having to create tickets manually for these, plus there'd be a quicker visibility over such issues.
Gertjan last edited by
python37-3.7.7 is vulnerable: Python -- Regular Expression DoS attack against client CVE: CVE-2020-8492 WWW: https://vuxml.FreeBSD.org/freebsd/a27b0bb6-84fc-11ea-b5b4-641c67a117d8.html python37-3.7.7 is vulnerable: Python -- CRLF injection via the host part of the url passed to urlopen() CVE: CVE-2019-18348 WWW: https://vuxml.FreeBSD.org/freebsd/ca595a25-91d8-11ea-b470-080027846a02.html libnghttp2-1.40.0 is vulnerable: nghttp2 -- DoS vulnerability CVE: CVE-2020-11080 WWW: https://vuxml.FreeBSD.org/freebsd/4bb56d2f-a5b0-11ea-a860-08002728f74c.html json-c-0.13.1_1 is vulnerable: json-c -- integer overflow and out-of-bounds write via a large JSON file CVE: CVE-2020-12762 WWW: https://vuxml.FreeBSD.org/freebsd/abc3ef37-95d4-11ea-9004-25fadb81abf4.html 4 problem(s) in 3 installed package(s) found.
If these 4 could be used somehow by an unknown person or script from a remote or local site, then yes, there is an issue.
Normally, a good router firewall has 4 NIC's : a WAN, a LAN for very trusted visiors, lke the admin - probaly only him, a second LAN which is the company or family LAN, and a third interface for devices you don't trust at all.
On the WAN, third and fourth interface, pfSense should not propose any ports that are serviced. The list with exceptions is rather small : DHCP, NTP, DNS - or port 67 and 68, 123 and 53. Behind these ports there is no 'Python, no json, "libnghttp2" based services.
If a vulnerability is exploited, the "hacker" should first have to, have access at 'admin' level. When that happens, the mentioned vulnerabilities are the very least of your problems.
Btw : every update will include of course upstream upgrades, and it has even happened that an pfSense was updated because of an urgent CVE matter ( think of Heartbleed a couple of yeras ago)
We always check that ourselves, and it's not always as simple as updating a package binary to fix them.
@Gertjan Concur. The vulns above are just current examples, those that matter are indeed the user-facing ones on data planes. Thinking squid & clamav just to start.
Now, because one cannot just get patched packages from anywhere in this project's case, the point of the topic would be to have them patched as soon as feasible, with integration tests etc. for QA.
@jimp Good to hear that. Only wanted to have something more public, let's say? If possible. Kind of like an acknowledgment that issues exist, are known, and are being worked on.
Remember reading some <<upset>> posts here of some vulns present in the period between release of 2.4.5 and the previous one. Maybe that person didn't know the vulns were already patched or a "pkg upgrade" (option 13 on CLI doesn't always find updated packages, whereas pkg does) would bring their system to a more patched state.
On a more off-topic note, are patched programs/libraries made available on the daily development releases, or is there a way to install them on current releases, say like with a command such as Fedora's "sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-ca8855e4de"?
If we pull fixes into a release branch of the ports repository, they're available to everyone within a few minutes in most cases. For snapshot branches, they're in the next snapshot (whenever that gets built).
Not every CVE is relevant to pfSense or the way a package/library gets used on pfSense, too. Just because there is a known issue doesn't mean it's actually a concern for us. But some people see any CVE notice and get scared.
@jimp All right.
Just as a thought, finished reading today the report from https://www.synopsys.com/content/dam/synopsys/sig-assets/reports/2020-ossra-report.pdf - not endorsing that company in any way - and think the software BOM (bill of materials) idea is quite good, plus knowing which packages/libraries are no longer maintained.
BTW, I think I might have marked feature request #10404 as private and nobody sees it anymore (?).
Gertjan last edited by