Several vulnerable packages without update

Dobby_

@fadinzr said in Several vulnerable packages without update:

how do I patch these packages ?

You have several choices for doing so.

Patches for the entire pfSense system (OS)
Install the patch system and have a look over that patches you will need or you should apply

Or have a look in the WebGui
system update.jpg

Patches for the packages (pkg system)
Have a look in the widget what pkg`s will be able to update or upgrade (WebGui)

If there will be an update it will be shown there sorted with a plus (+) sign!
And all also over the console like you have done!
Use PuTTy and connect to the console and run

[2.7.0-DEVELOPMENT][root@xx xx xx]/root: pkg update

[2.7.0-DEVELOPMENT][root@xx xx xx]/root: pkg upgrade

[2.7.0-DEVELOPMENT][root@xx xx xx]/root: pfSense-upgrade

fadinzr

I'm using Pfsense CE 2.6.0-RELEASE, waiting for 2.7.0 and hoping that will resolve these vuln

Dobby_

@fadinzr

Didi you install the patch system? If not try it out
and apply to the patches and then rescan your
pfSense once more again please.

fadinzr

@dobby_

I just installed "System Patches" package, wonder what is the best way to backup pfsense before installing any patch?

Also what the reliability of these patches ? I will need to read more about it before I use it.

These patches seem to address pfsense OS not packages vulnerabilities. I doubt installing these patches will make these vuln disappear.

Dobby_

@fadinzr said in Several vulnerable packages without update:

These patches seem to address pfsense OS not packages vulnerabilities. I doubt installing these patches will make these vuln disappear.

System patches are patching the entire OS
up to date system, fast reaction on vuln. are given
pkg update & upgrade are installing newer packages
up to date packages, faster reaction on vuln. & functions
patch system (own patches)
you may be able to write your own patch! Gives you a part of the control

JeGr

@fadinzr said in Several vulnerable packages without update:

These patches seem to address pfsense OS not packages vulnerabilities. I doubt installing these patches will make these vuln disappear.

There is no "pfSense OS". pfSense itself is a sum of packages that runs on a custom collection and kernel of FreeBSD. Done. So it's a minimized/customized FreeBSD install with custom packages (pfSense-xy) and system/service packages which are built by the team itself for pfSense and are managed in their own repository.

System Patches only does small changes that can be in UI code (PHP) or configs, that are easily switchable (with a diff/patch) - so the package doesn't installs/updates any new packages or big things but only fixes smaller level stuff. But that can be a config that exposes too many information, so can be relevant for such a scan.

Running pkg update is another way for a few packages that got fixed by Netgate in their repository. But you won't see the FreeBSD upstream fixes there as the packages are not the same.

But besides that: having some "vulnerabilities" displayed by a scan FROM INSIDE your network isn't the same view as from OUTside your network. Additionally I'm not sure how your nessus scan is able to check for things like CURL etc. without having actual access to the system and that would be quite a strange use case for such a security assessment as NO user besides network admins get access to my firewall. So I don't understand how half that list is actually scanned for as e.g. cURL is nothing that is running as a service. So either your scan is making assumptions that may or may not be true or you are scanning with a privilege level on the system itself that is unreasonable.

Gertjan

@jegr said in Several vulnerable packages without update:

"vulnerabilities" displayed by a scan FROM INSIDE your network ....

Still, this is a very limited view.
As the list shown above is obtained "FROM INSIDE pfSense itself".
Or : the installer USB image is unwrapped, and scanned.

By default, nothing can be obtained from the WAN interface.
By default, the LAN interface will answer on port 80 TCP (or 443 TCP as no one like 'http' these days) and port 53 UDP/TCP.
So, not 100 % sure, but a 'packet analyser' could indicate that pfSense uses :

nginx as the web server.
unbound as the DNS 'server'.
and because Ethernet packets are build by the OS (the NIC drivers), with some guessing it's even possible that the underlying OS, FreeBSD, can be recognized.

Knowing that the LAN interface should only be used or made accessible to/for devices that you really trust, and that all other devices should be placed on another LAN segment, where only port '53' is made available. Or even better : nothing, so no access pfSense itself at all.

When the 'pfSense by default' mode is used, everything boils down to just one question :
How sure is 'pf', the pfSense firewall ?
With 'by default' I mean : no gadgets. No pfSense packages. Nothing.

The question 'how sure is pf ?' can be answered as the source is for everyone who want the real answer to the real question. In case of doubt, check the source of the compiler, then compile the compiler to build itself (build the entire tool chain while you're at it) and then build 'pf' (and FreeBSD).
Now, you're safe

That dnsmasq exists on the disk (not used by default) or 'OpenVPN', 'curl', or 'python', this can can not be detected from the outside. Any side.
As always : the most secure software is the software that isn't used.
Even more secure : minimum OS + 'pf ' - no GUI, no gadgets, nothing (again).

Btw : the best and fastest result would be obtained by removing the most obvious insecure element, not yet named : the admin.

JeGr

@gertjan My intention is not to shoot against testing. That's important and right. But thing is, most testings are done with such scanners like nessus, greenbone etc. that run a list of checks for detection, then run a big list of CVEs for that OS/distro etc. etc. but all in all is only a very limited use and view, as it doesn't take into account if a CVE etc is relevant or even important in that context. And the context of a firewall is often vastly different to those of a FreeBSD service with standard packages installed etc.

And with the scaremongering going on as we see high-pitched CVE alerts that are completely out of scope where even the developers of the software are scratching their head as to why the score was given, I don't see automated scans as a really good way to secure a system. It's more or less a tool of some XYZ compliance factsheet that helps someone make checkmarks behind a ToDo list of things so e.g. an insurance company is "happy" and you can document, that you did "everything by the book" but were hacked nonetheless. Just wanted to shine some light on that , not wanting to discuss package updates away ;)

Cheers

fadinzr

Thanks all for your insights and feedback

Dobby_

@fadinzr

[23.05-RELEASE][root@xx xx xx]/root: pkg audit -F
vulnxml file up-to-date
libxml2-2.10.3_1 is vulnerable:
  libxml2 -- multiple vulnerabilities
  CVE: CVE-2023-29469
  CVE: CVE-2023-28484
  WWW: https://vuxml.FreeBSD.org/freebsd/0bd7f07b-dc22-11ed-bf28-589cfc0f81b0.html

curl-8.0.1 is vulnerable:
  curl -- multiple vulnerabilities
  CVE: CVE-2023-28322
  CVE: CVE-2023-28321
  CVE: CVE-2023-28320
  CVE: CVE-2023-28319
  WWW: https://vuxml.FreeBSD.org/freebsd/a4f8bb03-f52f-11ed-9859-080027083a05.html

py39-setuptools-63.1.0 is vulnerable:
  py39-setuptools -- denial of service vulnerability
  CVE: CVE-2022-40897
  WWW: https://vuxml.FreeBSD.org/freebsd/1b38aec4-4149-4c7d-851c-3c4de3a1fbd0.html

redis-7.0.10 is vulnerable:
  redis -- HINCRBYFLOAT can be used to crash a redis-server process
  CVE: CVE-2023-28856
  WWW: https://vuxml.FreeBSD.org/freebsd/96b2d4db-ddd2-11ed-b6ea-080027f5fec9.html

4 problem(s) in 4 installed package(s) found.