FreePBX | Register | Issues | Wiki | Portal | Support

Any way to disable module signature checking for an individual module?


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.

(Kevin J. Slonka, Sc.D.) #61

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.

(Andrew Nagy) #62

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

(Rob Thomas) #63

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.

(Andrew Nagy) #64

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!

(Kevin J. Slonka, Sc.D.) #65

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.


150   if(!preg_match('/^(cxpanel|framework)$/',$modulename))
151   {
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   }
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.

(Rob Thomas) #66

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.

(Kevin J. Slonka, Sc.D.) #67

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.

(Rob Thomas) #68

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.

(Kevin J. Slonka, Sc.D.) #69

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…

(Rob Thomas) #70

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.

(Andrew Nagy) #71

After 13 is stable let’s work on this.

(Kevin J. Slonka, Sc.D.) #72

If an attacker gets in as the web user it’s game over for FreePBX anyway. The web user is the owner of all FreePBX PHP files (I didn’t change any permissions, it’s the way it was installed from the ISO). So if someone gets in as the web user they can make the same modification as I did to the GPG.class.php file and bypass everything anyway. GPG signing won’t prevent that. So I fail to see how module signing really does anything to help.

After reading your post further you made it seem like a lot of these files are supposed to be owned by root, not the web user. That’s not the case on my install. Literally every file in /var/www/html is owned by the web user. If these files were owned by root and readable by the web user that would be a step in the right direction.

This, to me, is unacceptable. For something that should be as easy as a checkbox on a web page no FreePBX admin should ever have to create a GPG key, clone repos, or anything like that. You’re expecting people to be developers in order to do a seemingly simple thing and they aren’t. (I am, as well as an infosec engineer, so this isn’t a problem for me but for people who are simply VoIP people this is crazy).

I wholly understand that this is an edge case; most people will never have the need to edit the source of modules. But some of us do. The bottom line is that if there is critical code that you want to ensure doesn’t get tampered with it needs to be present in binary form. Otherwise, it can be edited by anyone, good or bad, and there is no way programmatically to detect one versus the other. So any protections in place hurt legitimate modifications. But just as I accepted the risk of not validating certain modules you accepted the risk of annoying certain customers in order to better protect everyone else. I get it.

I’m happy with my hack. It works for me. Would I like a GUI option to do what I did in code? Of course. But I’m not going to ask any of you to do that because there are more important things to do.

(Rob Thomas) #73

Theoretically, yes. Practically, no. There’s no advantage for an attacker to destroy a FreePBX machine. Financially, it’s in their best interest to either steal SIP credentials, or, zombie the machine into a spambot.

I actually accidentally clicked on your profile when I saw the email alert about the reply, and you have ‘security’ in there, so it’s great to have someone ELSE who thinks about this stuff… It’s pretty much just been me driving this.

As a background, most of this discussion has happened in IRC with other people, and discussions at various conferences with other people, so I totally understand that you’re coming in blind. So I’m going to go through some things that we’ve talked about, and (hopefully!) you can poke holes, or offer suggestions about what we’ve done.

So. The entire reasoning behind FreePBX’s Module Signing is to make sure users have a way to be notified if someone has changed a file or tampered with a module. Over the past few years we have seen more and more attacks on FreePBX systems and most of the time the hackers were modifying FreePBX modules and users had no way of knowing something had been modified.

That’s it. That’s all it’s for. That was actually (slightly paraphrased) the introductory paragraph I wrote about GPG when I was pushing for it.

That depends on the aim of the attacker. If their aim is to be stealthy, we want to detect that and make lots of noise. If their aim is not stealthy, then we don’t care, you’re going to notice anyway.

That’s exactly correct. And there’s nothing we can do to stop that, and that is why we turn module signature validation back on whenever framework is updated. That gives us a good compromise with people who don’t have their machine connected to the internet and want to do lots of custom code and NOT sign their code, and people who do have their machine connected to the internet.

So, at worst, a blackhat hacks their machine, removes the alerts before they’re triggered, and then starts adding malicious code. At some point, the owner is going to run an update which updates framework, module signing gets turned on, and immediately all the red flags go up and emails get fired out.

So there’s a window there, and I have no idea how to close that. Suggestions would be welcome :sunglasses:

No. I was suggesting that the GPG class check for root owned files as ‘overrides’.

I agree 100%. And no FreePBX admin has to do that. The only people who DO need to do that are people who want to be developers. The same way they need to learn how to use a text editor, understand what regular expressions are, and other things, they should be reading the Development part of the Wiki, which steps them all through this.

That’s not what we want to do. We want to warn people that code has been changed from the original packaging by the author. It doesn’t block, except in one, exceptional, circumstance that we’ve never used (when a developer with a signed key goes rogue, a revoked signature on a key blocks that module from running totally).

On the other hand, If people want to change one line in a file, then change the file. Click on the ‘X’ in the top right hand corner of the alert window, and move on. There’s nothing blocking anything anywhere, and you’ll never see the alert again. But, you’ve seen it ONCE, and that’s the important thing that we’re trying to achieve.

The problem there is ‘How do I stop the attacker from doing that?’, and as you pointed out, we can’t. So that’s why we’ve gone to all this effort to make it as foolproof as possible.

I’m trying not to be a prick here, but I can’t really think of a way to ask this question WITHOUT seeming like a prick. Sorry. But, here it is.

How is a dismissable, one-time alert, that correctly alerts you that files have been modified on your system from what they should be, annoying?


As a partially impartial observer, I take both of your arguments seriously, @xrobau has a solution that requires one to “trust” a third party (Sangoma) for a legitimate OSS effort, (which would be the whole key signing thing, in effect Sangoma “owns” such keys). @slonkak has IMHO a reasonable solution to isolate the code that is not guaranteed by Sangoma, but IS guaranteed by himself, he has obviously the ability to argue his case, and presumably provide prophylaxis against such penetration, I hate to say it but the granny state in OSS seems to me an old fart in this world a little intrusive.

Please don’t get me wrong, I also hug Rob for his efforts, but is it possible to make the whole thing either "you use my method " or "turn it off completely , any code change must be delegated to a third party " or accept that some might not fully “trust” your keys or maybe a middle line for the old hairy dudes?

(Rob Thomas) #75

No… That whole module stuff explicitly says this is not about trust.

No, again. It’s stuff that he’s happy to get changed. Again, not guaranteed.

This is where everyone seems to get confused about signing 8-\

It’s integrity validation, and that’s it.

That’s exactly how it is now.

Again, no trust is there.


I’m sorry , perhaps I misunderstand, but who has the “trust” against the generated keys and why does Sangoma accept those keys without question, could not any interloper do the same thing, given enough acquired privilege ?

(Rob Thomas) #77

I think you do… Have a read through the module signing part of the Wiki, it might answer your questions a bit better.

With trust… There is just ‘this is the person who packaged this module’, or, ‘I don’t know who packaged this module’, or, what NORMALLY happens, ‘The person who packaged this module said that this file is ABC, but it’s been changed to ABD’.

That’s NOT what this is about. This is to cover the most common attack vector, which is - for example - when someone’s left PhpMyAdmin running on their server, and now you have given random people shell access as the web user.

I want people to figure out holes, and potential weaknesses, but once the attacker is root, the game is over, and there’s nothing anyone can do from then on, so it’s not something we’re even trying to address.


how are you guys not involved, even as a second derivative?

(Rob Thomas) #79

Uh, you talked about trust? There is no trust. If we wanted to get TRUST involved, you would have needed to get a proper Code Signing Certificate, and oh my god those things are a terrible pain in the arse to get. It took me almost 2 months to get mine, sending faxes of passports and all sorts of things. It was a nightmare.