- Oct 12, 2007
- Reaction score
Mark Crane • 4 days ago
* We did respond multiple times in email and on github.
* Your email said you were going to write the security announcement and you did.
* We immediately commented out or removed the debug information on operator panel that created the Information disclosure vulnerability.
* We immediately added iptables rules to block SIP messages that have keywords that made the vulnerabilities possible.
* We focused our efforts on improving the security for things you reported and more.
* You sent your first pull request which was accepted 6 days ago. That was delayed because there were additional security concerns that we noticed and fixed. Which then caused a conflict on your changes. You updated your pull request and then they were accepted.
* You have provided companies with additional reasons to upgrade for that we can thank you.
* You did make us aware of a some security vulnerabilities that we did take seriously.
* Your suggestions only represent a small portion of the of the ongoing improvements to security and improvements to other areas of the FusionPBX code base.
* We have accelerated our efforts to make code base more secure.
FusionPBX is an open source project and has operated under limited resources. We have accomplished a lot with these limited resources. However, the project has outgrown the limited resources, so we have adjusted our sustainability model to provide growth of our team and resources. We have created a FusionPBX members ecosystem that is helping us to meet the growth. We are making progress in this regard and this is helping FusionPBX further accelerate improvements to security, support, features and overall to the success of FusionPBX and to the users of our software worldwide.
I don't know which is worse: a vulnerability in CallerID that compromises your entire call center or a developer that refuses to warn his users about the vulnerability.
In any case, if you are using FusionPBX, now would be a good time to shut it down unless it's been patched.
This is opposite from my findings. FreePBX provides hooks and custom dialplan and config insertion points all over the place. Using the _custom.conf files, you can do anything, adding on to or overriding the GUI. With FusionPBX, everything is driven by the database. You have to use the front-end for configuration and dial plan. If you try to look at anything from the CLI, it's obfuscated, named with UUIDs rather than the names assigned in the GUI.And you can't make any changes to anything or add anything unless sng 100% controls it from their end.
If you do not require FreePBX commercial modules, then it is very easy to build a lean FreePBX server without the things you dislike, on the Linux distro of your choice. Personally, I go for Debian.That is in stark contrast to fpbx which is a bloody mess. It's like "hey, let's see what else we can bolt on to this thing". "All the cool kids are talking about nodejs and mongodb so lets throw that in there because why not. Iptables works great so we need to break that by adding our own firewall to the GUI that
fightsoverrides it and causes more problems than it solves."
But that didn't go far enough apparently so they rolled their own operating system because reasons.
*.conf files are asterisk not fpbx. One in the same company now but two separate things. Fpbx was basically just a *.conf file generator at one time and it was very good at that. But then they tried to throw all that other stuff in there and it turned into a mess imo. You don't have to use the commercial modules but you cannot get rid of that module signature system or the warning messages.Using the _custom.conf files, you can do anything, adding on to or overriding the GUI
If you do not require FreePBX commercial modules, then it is very easy to build a lean FreePBX server without the things you dislike, on the Linux distro of your choice. Personally, I go for Debian.
.With FusionPBX, everything is driven by the database. You have to use the front-end for configuration and dial plan. If you try to look at anything from the CLI, it's obfuscated, named with UUIDs rather than the names assigned in the GUI.
vim /usr/local/freeswitch/scripts/app/xml_handler/index.lua --set the debug options debug["params"] = true; debug["sql"] = true; debug["xml_request"] = true; debug["xml_string"] = true; debug["cache"] = true;
Not really following you here... FreePBX generates conf files, and also has #includes to *_custom.conf files so that you can augment the work that FreePBX does with your own Asterisk config. That's what makes FreePBX a very flexible and configurable system. Anything you can't do in the GUI, you can finish the job in the conf files.*.conf files are asterisk not fpbx.
Fpbx just generates the files including #includes which are part of the syntax of the Asterisk *.conf system. It is not something fpbx has added to the asterisk file handler system. You do not need fpbx to add those things manually yourself. Fpbx just makes it MUCH more convenient by generate all that for you.Not really following you here... FreePBX generates conf files, and also has #includes to *_custom.conf files so that you can augment the work that FreePBX does with your own Asterisk config. That's what makes FreePBX a very flexible and configurable system. Anything you can't do in the GUI, you can finish the job in the conf files.
No FreePBX wont overwite the includes, it will regenerate its own files that include the #includes and it doesnt touch the base files on a reload, but for the following reasons , before you touch the base files . . .I'm not sure where the disconnect is here.
Q: where are those *.conf files located?
A: in the /etc/asterisk directory, with all the other asterisk .conf files.
You can create files and call them whatever you want. Call them supercalifragalisticexpialidosious.conf if you want and add the #include in which ever standard asterisk .conf file it needs to be in for asterisk to see it. They are still part of the asterisk *.conf system. It doesn't matter what the name is. Of course if you are using fpbx you would need to put that into one of the custom.conf files otherwise fpbx will overwrite the #include.
There was a time when you could not disable signature module warnings. I guess you can now.
Looking at the GUI it reminds me of another annoying thing they did. Where if you installed fail2ban it would warn you on the dashboard or something like that. Because it had to be THEIR version of fail2ban which was an older version. And it had to be installed with that sysadmin module which they made into a commercial module. I can't remember the exact details of the problem but it was yet another annoying problem they created by trying to take over control of e verything where there was never a problem before.