@billsimon, thank you!. That is a pitb, but I don’t mind spelunking. Especially when I can post the results here and maybe save someone else some effort in the future. I was completely unaware of the RedHat EL backporting, so thanks again! It’s not a complete answer, but I think you’ve pointed me in the right direction.
@jfinstrom, thank you! (And thanks for reaching out about the warranty. 
)
It sounds like @kgupta might be the guy in charge of updating the List of Securities Vulnerabilities page. If not, who do you think the right person might be?
For all the reasons you and @billsimon point out, it’s extra important that there be some easy to find a page listing all of the known CVEs and whether they have been fixed or not - for both the SNG7 FreePBX distro and the open source project.
It would also be a good place to put your bullet points. 
I’m not finding the proof of concept you mentioned. Can you point me to one so I can try the exploit to see if it actually works?
As far as I know, all Linux distributions do this. Packagers want maximum stability of a package during the life of a major version and normally only fix security issues.
Google any of the CVEs you listed above + words like POC/Proof of Concept/Demo
I do keep various exploits PoCs from research but I do not release any of that code to the public. Some of the code is not mine to release (I work with a team of people to dig in to things) and when so many people don’t patch their systems it would be irresponsible to hand out tools that can break them.
@jfinstrom, in your earlier reply you said:
You then said with emphasis:
You seemed to be saying that these were readily available, and should be used to verify an actual vulnerability after any security scanner (e.g. the Corvus scan) has identified potential exploits because, as you say, it “should be a starting point NOT a final say.”
From your most recent response, and for any future admins reading this far down: we continue to try to reach you about your expiring warranty… 
Just joking.
What @jfinstrom is actually saying is that CVE exploits probably have a proof of concept, but he does not know of any publicly available way to test the exploits directly, so there is not much to do at this time (short of hiring a security expert who may or may not be able to exercise the exploit directly).
Again, to @kgupta, or whoever is able to maintain the List of Securities Vulnerabilities page, PLEASE update that page to include a definitive list of CVE’s, their corresponding “Official Bug ticket” ID, and in what version of FreePBX the issue was resolved.
Forcing every single conscientious FreePBX admin to “hire a security professional” every time some rando scanner reports a vulnerability (as @jfinstrom admonishes) would be a huge and useless waste of resources, imho. Especially since most/all of the exploits in the OP are probably not exploitable unless someone roots in to the dedicated FreePBX server directly. (At least that’s my understanding.)
If none of the admins at wiki.freepbx.org are willing to create and maintain a page of CVEs (like every other major distribution does), then please at least put a big bold notice on the List of Securities Vulnerabilities page saying: “THIS INFORMATION IS OUT OF DATE AND HAS NOT BEEN UPDATED SINCE 2018. FREEPBX DOES NOT MAINTAIN A LIST OF KNOWN VULNERABILITIES”
I would be willing to mark that as a solution to my OP.
1 Like
You are linking to the FreePBX vulnerabilities page but your original post was about operating system & package vulnerabilities (mostly httpd, php, etc.). To be honest it seems as though the FreePBX maintainers are doing a very good job of documenting FreePBX security issues. The OS vulnerability confusion seems to be centered on Enterprise Linux’s backport scheme.
I am a little confused by your post.
The document with the List of Securities Vulnerabilities is fully up to date with every vulnerability that was reported to the FreePBX project. Every vulnerability has an ID and the version number that it was fixed.
Like other users have mentioned, that the list of vulnerabilities in your original post, is OS related and why they would show up in security scanners would flag those due to minor versioning numbers.
So others have mentioned, that in your list of OS vulnerabilities, if you think that the FreePBX distro is still vulnerable, then go ahead and test it, a lot of CVEs have a POC online. And no, FreePBX will not post the CVE POCs that are related to the FreePBX project for obvious reasons.
So again, which page is not being updated, and what info is missing?
I would contend if you know nothing about security don’t run a scanner, it is pointless.
Anyone managing a network should have some security knowledge. Anyone running multiple systems and a large network should be the security guy or have someone who is.
I am “a security guy” as are most of the former FreePBX developers. Security was always a primary concern and even we sometimes missed something. That is why it is beneficial to have ethical hackers.
The steps I take when reviewing a CVE.
- Read it and what they say it does
- google it and see if someone has “done the work” to write a PoC.
- If nothing comes up on 2, look at the commits for the fix to see what they changed
- If 3 is unavailable ask myself how would I exploit as described.
- Start implementing #4
Here is the thing, most exploits you are concerned about will be based on a network request. Things like sending malformed data or causing overflows. Some things may need a few steps but in general it will be some sort of network request. Most of these can be done in any language with little to no effort.
The fore mentioned exploit to restapps involved simple post data. The code is not available because it is a commercial module. So we start inspecting post variables and make the same condition happen.
Again this isn’t security guy or hacker stuff. This is all basic network stuff any IT professional should generally know.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.