No problem, and no need for an apology, I understood that you were still working on it. I just wanted to report my observations, and verify that I hadn’t done anything wrong. Actually, it’s pretty cool that you were able to get some of it finished while flying in a metal tube thousands of feet in the air!
So, I’m in Canada now. And it seemed to work, in my testing on the second leg. I’ve pushed the updates to Git, so if you want to test it, go wild.
However, DO A SQL BACKUP FIRST… ‘mysqldump asterisk > ~/backup.sql’
If it all goes pear shaped you can restore it with ‘mysql asterisk < ~/backup.sql’
Thanks, Rob. The problem now is when I attempt to install it, and confirm the install, the “Status” box pops up and it says:
Please wait while module actions are performed
Installing customappsreg
And then it just sits there… and sits there… and, well you get the idea.
When I get tired of waiting and close the status box, it goes back to telling me that Custom Applications are “Disabled; Pending Upgrade to 12.0.1” but if I try to upgrade again the same thing happens.
If at this point I copy the original Custom Applications module back in and then try to go to the Custom Destinations page, it says this:
Add Custom Destination
FATAL ERROR
DB Error: no such table<br><br>Error selecting from custom_destinations
Trace Back
/var/www/html/admin/modules/customappsreg/functions.inc.php:68 die_freepbx()
[0]: DB Error: no such table<br><br>Error selecting from custom_destinations
/var/www/html/admin/modules/customappsreg/page.customdests.php:44 customappsreg_customdests_list()
/var/www/html/admin/config.php:498 include()
[0]: /var/www/html/admin/modules/customappsreg/page.customdests.php
So in order to recover from that I have to restore from the SQL backup. Then everything works again. So it appears that it starts the install but hangs somewhere along the way.
The only error that appears in the FreePBX log during the time period when it is just sitting there is this:
[2015-Apr-25 04:00:16] [PHP-NOTICE] (/var/www/html/admin/page.modules.php:191) - ob_flush(): failed to flush buffer. No buffer to flush
Don’t know if any of this is helpful but that’s what I’m seeing at this point.
This is fun. Debugging whilst jetlagged!
Yesterday (Friday) was basically a blur for me, but I’m feeling much better now!
I’ll see if I can get it finished up today.
Edit: Well, it appears to pass my basic ‘It looks like it does the right thing’ tests, and upgrades properly now. Want to give it a try? (Again, this -deletes- the old database as part of the upgrade, so you need to take a backup using mysqldump to roll back)
Here’s a module.sig file for that commit, just to remove the warning (which was the ENTIRE POINT of this thread 
until it’s actually released properly.
Just dump that into a file called ‘module.sig’ in the customappsreg directory, and the warning will go away. Note that everything is on one line – you could do something like this on the machine:
wget http://pastebin.ca/raw/2981911 -O /var/www/html/admin/modules/customappsreg/module.sig
Well it actually installs and works now, and I was able to get rid of Dialplan Injections, so thank you for this. Unfortunately there are a few minor glitches remaining:
First, if you open an existing custom destination and check the return box and select a destination, it doesn’t get changed. But if you create a new custom destination, then it works.
Second, creating or editing a Custom Destination does not cause the “Apply Config” button to appear. Since you generally need to select your custom destination in another part of the GUI in order to use it, this isn’t a huge deal, but it might be if you edit an existing Custom Destination and then forget that the config still needs to be applied.
Third, on the System Status screen, the newly-created custom destinations are listed as bad destinations for some odd reason, even though they aren’t.
Thank you again, and I hope these are simple fixes!
Sorry, I am not ignoring your bug reports, I am just easily distracted 
Actually, it DOES work. But I had to mess around to make it as backwards compatible as possible. The BETTER way would have been to invalidate everyone’s Custom Dests when it was upgraded, as they way they were done was a bit of a hack (This still may happen, but I need to sit down and figure out all the edge cases and see which way is going to be better)
So, what happens now is that when you change a Custom Dest to have a ‘return’, it changes the destination in the dialplan. It used to be Goto($YOURDESTSTRING), but now it’s Goto(customdest,$DESTID,1). In the customdest context, it does the return, and then knows where to go after that.
This is the problem with backwards compatibility, of course.
So, to explain what’s actually happening, when you changed it to a return, the ORIGINAL target would have been invalidated and turned red. You would then have to re-select the target in the destination picker, and everything would work perfectly after that.
The other issue - the ‘Apply Changes’ button, I had noticed about 10 times but had forgotten to put back in 10 times as well. It’s in there now
Hmm. OK, I hadn’t noticed that, I’ll go and check it out.
If you care to check against the latest tree, Those last two are now fixed, the first one is, SORT OF ‘as designed’, but I had a bit of a thought as to how I could make it better, but it’s something I need to chat to everyone else about. Handily, we’re all getting together up here in Toronto tomorrow
Here’s the signature for the latest git!
Thank you again, this is almost perfect. I will only mention one small thing that’s not that important, and doesn’t affect the usability of the module, but it’s something you may not be aware of. On the page for an “old” custom destination, in other words one created with the currently distributed version of the module, there is a line at the bottom of the page that reads:
Used as Destination by n Object(s):
And there is a question mark icon and if you mouse over that, it will show all the objects that use that custom destination. This doesn’t seem to appear on the newly-created custom destinations. I know this is mostly a user convenience and if it had to be omitted for some reason that’s fine, but if it’s something that you’d intended to address and forgot about, now I’ve reminded you. 
Either way this module is working great now, and it’s really not a huge deal if I have to delete and recreate an “old” custom destination if I want to change the destination end to “Return” - that’s something that will so rarely happen that it’s probably not worth worrying about. But just so you are aware, even trying to change the Description of an existing Custom Destination doesn’t seem to work, and at this point I don’t know if that’s always been the way it works or if that’s a new problem. You can make the change in the text box and submit, but when the page refreshes, it appears nothing has changed. Most users probably would never try to change the description of a Custom Destination, so it might have been like that for years, for all I know.
This solves the original issue, and I have re-enabled module signature checking and all appears to be working well now - the “bad destinations” messages are gone, and the Apply Changes button appears when it should. So thank you again, and I hope you enjoy the rest of your time in Toronto! And I apologize if I was being a bit of a pain by finding things that didn’t quite work as they should.
I see you fixed the “Used as Destination by n Object(s)” thing so thank you for that. I reapplied the module signature and that seemed to work although weirdly I got a security message with no specific error in it - in other words the banner was there but the line that usually tells you what it’s alerting you to wasn’t. I closed the banner and it hasn’t come back so hopefully that’s the end of it.
So at this point it’s working great! Thanks again, and when you generally release this it will probably help a lot of users that have not been able to figure out how to insert their own bits of dialplan. I don’t know if you mark threads as “solved” here but as far as I’m concerned, this one is.
1 Like
I didn’t read every single reply to this thread because, quite frankly, there were too many that didn’t apply to the original question. But if people need the ability to disable module signing for individual modules, I can help. I just had to do it on my server. I’m sure the FreePBX people won’t be happy, but oh well. As long as you’re comfortable editing PHP it’s a piece of cake.
1 Like
It’s open source software. Do whatever you need to make it work for you. Two points here: firstly we aren’t trying to stop anyone from doing anything with FreePBX or it’s modules and secondly: the fact that you were able to do this in the first place proves that we can’t stop people as stated by point #1. So go ahead and document it if you wish.
The common misconception here is that “the FreePBX Team” or “Sangoma” is going to get mad. Well we won’t and we aren’t. So we can just stop saying that.
In an upcoming release we will have the ability to disable it globally without you having to edit php files so that you can keep updating if you wish, using some root owned file.
If however you are soliciting people to PM you for help privately then I strongly discourage that. Please document your steps for people who don’t want to join our forums or talk to you privately
1 Like
If you’ve figured out a secure way to do it, we’d love to have it! That’s our problem. We’ve got a couple of ideas, but no-one’s actually written any code to do it.
Edit: If you’re looking for suggestions, what has been going through my mind is something like this:
Use sign.php (in devtools) to sign your modified packed with an unsigned key, add the key and the module.sig to /etc/freepbx.d/MODULENAME, and then have the GPG stuff checks for that file FIRST, verify that it’s owned by root and use that for validation, instead of the embedded module.sig.
There’s a fair bit of work there, but if you want to join IRC (freenode, #freepbx-dev) and ping me there (X-Rob), I can help you out.
I’d really REALLY like your code to get into FreePBX, which means you’ll need to sign the CSA (this says, basically, that you won’t sue us for using your code, and that we’re allowed to distribute it as part of FreePBX). If you’re not willing to sign it, I’ll still help you, but I won’t be able to look at your code (in case, in the future, you decide that I copied it and want to sue ME). Sigh, lawyers.
Even if it’s a non-secure way. If it works for you then fine. You are all able to edit PHP files. However clarifying Rob’s statement we need a secure way to do it so that we can distribute it.
Finally, we asked the community to email us, tweet us, call us about their concerns about sig signing and we’ve gotten nothing. So really the priority of the root owned file goes low on our list. But it will get done at some point.
Anyways. Document away if you’d like @slonkak no one’s going to stop or stifle you!
My original comment about the FreePBX people not being happy was because in order to do this you only need to take about 45 seconds of your time, yet there were 52 posts before mine in which no FreePBX people were willing to help the OP do this (secure or not).
My way is not secure, at all. I’ve simply bypassed the GPG checking. This was the only way I found due to how the module signing works. I could have just edited the module.sig file with new hashes for the files I edited, but that would have broken the GPG signature. So the only way to make this happen was to make the GPG check not happen at all for the modules I edited.
I noticed that the “tamper” alerts stem from the data in the modules table in the database. A check happens everything a config is applied (the big red button) in the web gui, modules are checked, and if one fails the JSON is written to the modules table. So my code just makes the “untampered” JSON written to the table for the modules I specify.
In the below code all that’s happening is I run a check to see if the currently-being-checked module is the one that I’ve edited, and if so don’t run the signature checks, thus returning the “untampered” result. Editing this file, however, causes another tamper alert because it’s part of the “framework” module. So you’ll see in the regex that I had to exclude that as well. As I said earlier, completely not secure, but for people who have to edit modules because they don’t work how they’re supposed to, it makes FreePBX happy.
admin/libraries/BMO/GPG.class.php
150 if(!preg_match('/^(cxpanel|framework)$/',$modulename))
151 {
152
153 foreach ($module['hashes'] as $file => $hash) {
154 $dest = FreePBX::Installer()->getDestination($modulename, $file);
155 if ($dest === false) {
156 // If the file is explicitly un-checkable, ignore it.
157 continue;
158 }
159 if (!file_exists($dest)) {
160 $retarr['details'][] = $dest." "._("missing");
161 $retarr['status'] |= GPG::STATE_TAMPERED;
162 $retarr['status'] &= ~GPG::STATE_GOOD;
163 } elseif (hash_file('sha256', $dest) != $hash) {
164 // If you i18n this string, also note that it's used explicitly
165 // as a comparison of "altered" in modulefunctions.class, to
166 // warn people about bin/amportal needing to be updated
167 // with 'amportal chown'. Don't make them different!
168 $retarr['details'][] = $dest." "._("altered");
169 $retarr['status'] |= GPG::STATE_TAMPERED;
170 $retarr['status'] &= ~GPG::STATE_GOOD;
171 }
172 }
173
174 } // End bypass
The IF statement on lines 150-1 is the regular expression to not run the next block of code if the module name is either cxpanel or framework. Cxpanel is the one I edited and framework is the module that this file belongs to (you always have to exclude framework in addition to the module you’ve edited). Then just don’t forget to close the IF statement BEFORE the return at line 174.
There you go, no more tamper alerts.
For those who want to do this make sure you use the actual module name in the regex (the one listed in the modules table), not the name shown in the tamper alert in the web gui.
1 Like
Yes, and that’s why we don’t want to do it. The entire point of signing is to make it secure. If you want to disable signing totally, you can turn it off in Advanced settings, there’s no need to go through and hack on the code.
I don’t want to disable it totally. That’s stupid. I only want it off for the modules I’ve edited. There is no way to do this, thus my hack.
But that’s what you’ve done. By disabling it for two modules, you’ve totally removed all the security in module signing. The entire point of it is to alert you when someone messes with your stuff that you weren’t expecting.
You may not have seen my edit, but re-read my post above, that’s what’s been going through my mind for a way to make it secure. If you’d like to get involved with that, I’d love to help.
Honestly, I don’t know why people have an issue just asking for their own key to be signed, but some hysterical outbursts by a specific community member (who appears to hate me) seems to have people worried over nothing.
Your code isn’t accurate then. It’ll ignore any modules that start with cxpanel or framework, NOT any modules that ARE cxpanel or framework. I’d also suggest doing it at the top of verifyModule, before it tries to verify the signature, as your code will fail if the module.sig is missing.
No it’s not. All of the other modules are still checked for sanity. The only problems that will happen are if “bad guys” mess with the two modules I’ve excluded in the future; I won’t be notified. I’ve accepted that risk for these 2 modules, and only these 2 modules. Your suggestion of disabling it totally would mean that every single module I have would be unchecked… not what I want.
2 modules being unchecked is acceptable risk to me. 30+ is not.
I didn’t read this whole post, so I must have missed the “hate” posts. I don’t hate you, here’s a :hug: to prove it. Hah.
As for a secure way to do this, I’m not sure one exists, at least not the way you want it to. This is OSS, things can be edited. To me (a complete outsider not privy to any conversations about module signing) it seems that FreePBX module signing is Schmooze’s way of trying to defend someone’s network when the customers should be doing that themselves with firewalls and proper security config throughout their networks. It’s not the job of a VoIP server to protect a network. If someone can get inside the network far enough to edit PHP code on a server, FreePBX module signing is the least of your worries.
I’d personally be happy with the simple checking done with the module.sig file. Then if we edit any code we can simply update the hash and be happy. Obviously hackers can do that too, but like I said above, acceptable risk. This is OSS after all. The only secure way to do what module signing is supposed to do in theory is to make all modules compiled binaries, and I doubt anyone wants that. I’ve had to deal with ZEND compiled PHP before and I wanted to hang myself.
So in the bigger conversation, my 2 cents is that module signing is too restrictive considering this is all OSS. Customers should have their own defense strategy to prevent people from getting into their servers.
So what do you think? Sorry if this post sounds too attacky.
It’ll ignore any modules that start with cxpanel or framework
Yeah, I didn’t put the $ at the end of the regex. I’ll edit my post…
1 Like
That’s totally up to you, but in my opinion, by ignoring ANY module, your machine can be 100% owned without you knowing about it (for example, any module can register hooks that can be run on ANY post or get of any page. If someone hacks cxpanel, they have hacked the entire machine).
Well, there are two levels of pwnage. The first, easiest, level is something like Shellshock, where any entrypoint is a potential attack target. Or a bug in something like PhpMyAdmin, or … ANYTHING that gives an attacker ‘web-user’ permissions on the machine.
The second is when they’re root. We can’t defend against this. Once they’re root, the game is over, they own the machine, and nothing can be trusted on that machine again. So we don’t even try.
But the idea behind GPG is ‘what happens when an attacker DOES get in as the web user, and how can we defend against that’.
Nope, not at all. Firstly, GPG was 100% my idea, I pushed it, and I wrote most of it. Schmooze just happened to pay my wages whilst I wrote it. Additionally, It’s got nothing to do with networks, or defence. It’s purely to detect attacks against FreePBX. You can, for example. find a vulnerability in FreePBX, use it to get access to the machine, and then add and modify stuff outside of the FreePBX webroot, and GPG doesn’t notice.
Totally not an acceptable risk for me. Now, Sangoma may come and lean on me and say ‘We need to make Module Signing Brain Dead’ (however they phrase it, that’s how I’ll hear it), and … well, now I think about it, I probably won’t do it, even if they ordered me to. GPG is my baby, and I care deeply about it. I realise it’s not PERFECT, but it’s good enough for the moment. I think.
I am unsure if I agree with that. There are two things that need to be done (at the moment) if you want to edit a module, and not have it display the warning up the top of the page. The first thing is to request your key be signed by the FreePBX key, and the second thing is to check out the devtools repo from git, and use the tools in there to re-sign the package.
There is a page somewhere on the wiki that explains all this.
I realise that it could be simplified to just one thing, by adding some check-if-files-are-owned-by-root validation to the GPG stuff, but it’s just not terribly high on my priorities. However, having just LOOKED at the code that needs to be fixed, it’s probably NOT that much work, now I think about it.
You also want to move it above ‘Get the module.sig file’, too.