Does anyone know if there is some place that lists CVE vulnerabilities in FreePBX and their current status?
We are currently running FreePBX v15.0.23.11, and we try to keep it fully updated.
As part of our annual business insurance renewal, they ran a scan of our PBX with a tool provided by Corvus and found the following CVE vulnerabilities:
The list is a little longer than I would have expected, and the majority of them are years old.
Iâm guessing the FreePBX developers are already aware of these vulnerabilities, so Iâm hoping itâs possible to find a complete list of CVE vulnerabilities in FreePBX and whether they have been addressed or not.
The ones I sampled donât seem to be in FreePBX, although they may be in the SNG7 Linux distribution. Also most or all the ones I sampled donât seem to be exploitable purely remotely. Quite a few seem to be Apache problems that are only exploitable if third party scripts are installed, which might be an issue for a public web host, but probably not for an embedded one.
Thank you so much, @david55. This is exactly why I was hoping there was a central place to find a list of known CVEs for FreePBX and their status. I suspect most of these are not exploitable in the standard FreePBX/SNG7 distro.
FWIW, the Corvus report lists all 16 of these CVEs as âApache httpdâ vulnerabilities with one being flagged as critical and the other fifteen marked as high.
Iâm a little confused because that page identifies vulnerabilities and has NIST CVSS scores, but does not show any CVE identifiers (that I could find). According to the About the CVE Program page: âInformation technology and cybersecurity professionals use CVE Records to ensure they are discussing the same issue, and to coordinate their efforts to prioritize and address the vulnerabilities.â
Does anyone know where to find the corresponding CVE-ID for each of the identified vulnerabilities? Or, maybe there is a reason these vulnerabilities are not in the CVE database?
If anyone knows how to reach @tm1000, Iâd love to ask him to add the âOfficial Bug ticketâ ID and in what version(s) of FreePBX it was fixed for each of the vulnerabilities on the List of Securities Vulnerabilities page so you donât have to click in to each one individually to find that important info.
Until Sangoma gets off their butt and moves off CentOS 7, nothing will make this better. FreePBX 16 is a half assed step to get around CentOS 7, because they manually added PHP7 to their repos, but they did not manually update much else.
Without looking at the detail of each CVE, most will generally not be anything that is actually important unless the system is publicly available to the wider internet. So it will be busywork on your side to push back against idiotic, formulaic, nonsense from the insurance company.
Hey @sorvani! I went through each of the CVEs in the list from my OP. Here is a table of each oneâs CVSS score and the message from the changelog where it was fixed.
I pulled the CVSS score and Vulnerability type from the www.cvedetails.com website. On the NVD - Search and Statistics page, all 16 CVEs are listed as 9.8 Critical which didnât seem terribly useful to me.
@dicko, thank you so much for the link. Iâm reluctant to get too far away from the standard FreePBX install and configuration though since it makes it harder to get help when things are all custom rolled. But, if the insurance company plays hardball, itâs good to know I have a workable path forward.
Do you or @sorvani know @tm1000? Iâm still scratching my head on why the List of Securities Vulnerabilities page doesnât use CVE IDs and doesnât include a list of CVEs that are known to apply.
FWIW, it sure looks like the 16 vulnerabilities identified by the Corvus scan are still open given the version numbers of the products deployed in FreePBX v15.0.23.11:
> httpd -v; openssl version; php -v
Server version: Apache/2.4.6 (CentOS)
Server built: Apr 2 2020 13:13:23
OpenSSL 1.0.2k-fips 26 Jan 2017
PHP 5.6.40 (cli) (built: Jan 22 2019 23:51:52)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with Zend Guard Loader v3.3, Copyright (c) 1998-2014, by Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2015, by Zend Technologies
Itâs not just Insurance companies that are hidebound, currently Sangomaâs FreePBX ( the âdistroâ) still relies on no longer supported code or deprecated usage, naming some . . .
Is there anyone trying to bring FreePBX into the modern world? Whereâs the main thread on this issue, dicko? This is definitely off topic from my OP asking for a list of FreePBX CVE vulnerabilities, but itâs definitely important. (Five of the open CVEs are from 2016. )
Are we talking FreePBX or Sangomaâs FreePBX âdistroâ ?
Apart from the asterisk macro thing (the pot and the kettle live next door now, go figure ), FreePBX itself can happily now run with current open-source OSâs, PHP 7.4 Fail2Ban 0.11 OpenSSL 1.1.1n , current apache 2.4.54 nginx 1.22.0
Incron and cron like services are better handled by systemd
If you rely on any commercially licensed modules including sysadmin or the firewall, then they have you by the short and curlies
@dicko, I want to respond, but not on this thread. If thereâs not another thread on the topic youâre discussing, should I just open a new one? -Mark
Itâs important to understand that simplistic security scanners are going to flag Apache as vulnerable in some cases when it has already been patched against the vulnerability. The reason is explained at Security Backporting Practice - Red Hat Customer Portal
Simple version number scanners see Apache/2.4.6 and do not see that it has had patches applied to it through the RedHat backport process.
Apache 2.4.6 isnât really 2.4.6âŚ
# httpd -v
Server version: Apache/2.4.6 (CentOS)
Server built: Apr 2 2020 13:13:23
[root@uc-x ~]# rpm -q httpd
httpd-2.4.6-93.el7.centos.x86_64
itâs actually Apache 2.4.6-93! (on a fully-updated FreePBX distro)
As you can see it was compiled in April 2020 so this should satisfy the Apache CVEs before then (youâd have to go through the release notes and check), though you have several on your list that were published after April 2020, so those obviously arenât resolved.
@billsimon, thanks, and I couldnât agree more. In fact, that is exactly what I wrote back to the insurance company about their Corvus scan.
My issue here is that without someplace for us to go to to get a definitive list of known vulnerabilities, weâre all just guessing about our security position. Iâm hoping others would like CVE numbers added to the List of Securities Vulnerabilities page.
FWIW, hereâs what my system has to say about package versions:
Looks like we have a fully-updated FreePBX distro. Woo hoo!
That still doesnât get us to the 2.4.54 release where all eight of the identified apache vulnerabilities have been addressed.
FWIW, I did go through all of the official Apache release notes. The fixes arenât incorporated on a date of compilation, but on a release number. So, the CVEs before April 2020 have definitely not been addressed.
Iâve posted this before, but this link is often helpful in these scenarios. You will also want to look into Red Hat back-ports security releases without bumping the release number. Read this article for details: Security Backporting Practice - Red Hat Customer Portal
I believe based on very old information @mbrooks is doing the distro stuff. @kgupta heads up most of the FreePBX dev stuff including publishing.
Project managers currently are @lgaetz For FreePBX (the open source project, not the SNG distro) and @jcolp for the Asterisk project.
None of this matters if you donât understand the following concepts which have been covered here.
The FreePBX Distro is named SNG 7 and is a commercial product. It is NOT the same as FreePBX the open source project
SNG 7 is an âEnterprise Linuxâ derivative based and is much like CentOS with different branding
The term âEnterprise Linuxâ is used to not get sued by the redhat people
All âELâ distros are built from Redhat packages with branding stripped for trademark compliance
Redhat backports bug and security fixes and maintain their own stable branches.
Security scanners should be a starting point NOT a final say. Almost all CVE reports will have a proof of concept. TRY THE EXPLOIT AND SEE IF IT WORKS
If you are still reading this we have been trying to reach you about your cars expiring warranty
In any case security should be left up to security professionals typically. If you hired someone rather than running a script, most of this post wouldnât be required.