Idea for quicker CVE patching

e-1-1

Dear developers,

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

Hi,

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)

jimp

We always check that ourselves, and it's not always as simple as updating a package binary to fix them.

e-1-1

@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.

e-1-1

@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"?

jimp

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.

e-1-1

@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

@Gertjan said in Idea for quicker CVE patching:

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

This one made it : https://docs.netgate.com/pfsense/en/latest/releases/2-4-5-p1-new-features-and-changes.html