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

[dicko]

Wow, that bolsters your underlying trust factor in which way? , anonymous folks can circumvent your security and f%# wiih your site willy nilly ? Come on you deserved that

[el_es]

How about an idea like this:

• create another non-root and non-wheel user on the machine,
• as root - change the ownership of the module files TO the designated user that is in the same group as the original (so that the permissions can still be rwxr-xr-x or even rwxr-x— maybe?)
• the integrity check while encountering such files, owned by the designated user (e.g. also member of an ‘allowed_editors’ group), can maybe keep track of the changes in the checksum and show/send an alert when this changes, without affecting the ‘official’ module integrity checking online upon updates; (a single permanently dismissable alert on status page ? A line of text in Module Admin showing ‘this module has been edited locally last on $date?’ with a button ‘revert back to online version’ ?)
• mid-step: when ‘checking for updates’ and checking the integrity, display them a choice: we noticed this module has file(s) owned by $allowed_editor, last changed on $date, do you want to keep or revert to online version?
  (- advanced: do a 3 way merge )
• this should have the effect, that if attacker becomes www-data, they can read but can’t write to the changed file(s), AND an owner who wants to give a third party HE trusts, the right to edit things on HIS machine, will get a notice every time they do that.
• bottom line is: this will not bypass the integrity check, will not disable it completely, but make it really flexible for those who know what they are doing (and still want to be safe too)

How’s that sound?

(+xrobeau has suggested changing to ownership by root originally on one of above posts, but I can see where that goes with people who DON’T want to give root to their allowed_editors…)

[tm1000 (Andrew Nagy)]

@el_es

has suggested changing to ownership by root originally on one of above posts, but I can see where that goes with people who DON’T want to give root to their allowed_editors

Again. Rob never said that. There is massive confusion here. He said a single root owned master file that has other keys in it

[el_es]

Hmm… post 70, please:

@xrobau

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.

i see where my confusion came from :L

[tm1000 (Andrew Nagy)]

@el_es

check-if-files-are-owned-by-root validation to the GPG stuff

He is talking about a root owned master file. Not root owning all files in html. That would prevent updates. Same as your other method.

[el_es]

OK so… webupdates will not update locally modded files ?
that would ACTUALLY do what is expected of it then…
Why?
because the POINT of local modification is, we don’t want to revert it without being asked. Twice.
Neither we want chown system to revert that ownership setting. so that will need a mod, yes.
The assumption here is, we were told, we need to know what we are doing before we tinker.
And yes, root shall not own files in html, hence the special user/group idea.

[tm1000 (Andrew Nagy)]

Ok but since you don’t understand how the underlying system works that is a very bad practice. Firstly say you lock out a file in a module. Great. The way the subsystem works is that you can never update that module. Until you remove the lock on that one file. You can’t update around just that file, it’s all or nothing… which causes a bigger issue with Framework because in framework it over writes all files at the same time throughout the system. If you locked a file down from being modified and we made changes to its structure and other new items expect those changes then bam. You are SOL as your system would be totally unmaintainable. It would crash and there would be no way for FreePBX to help you out of it.

[slonkak]

Please read the whole thing before starting your reply, as I backtrack on some of the things I say further down…

@xrobau

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.

If this is the real problem then I believe you’ve added a decent solution with module signing.

But, as a security person, my inclination would be to look for the root cause; how did the attacker get into the system in the first place? Making malicious edits to modules is the effect, not the cause. Module signing fixes the effect of the attack, it doesn’t prevent the cause. A better solution would be to find how they’re getting into the system and stopping them at that point.

I like the GPG signatures the same way as I like them on RedHat et al. But in the latter cases the signing is just for initial installs. If I download rdesktop from yum, its signature will be verified and the package will be installed. After that I can edit any of the files that were contained in the package and the system isn’t going to complain because the signature will never be checked again. I would like that type of signature checking with FreePBX modules, but that can only exist if, as I said earlier, the root cause of the attacks that lead to the implementation of module signing is fixed. In the meantime, I think the constant validation that is currently implemented is fine due to the real attacks that it prevents/complains about.

@xrobau

That’s not what we want to do.

I totally agree. Binary PHP sucks. My point was simply that it’s the only way to actually prevent malicious modifications (and even then the good hackers can still finesse the binaries)

@xrobau

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?

I’m sorry if I sounded rude in any of my posts. Nothing was meant to be rude or passive aggressive (as I’ve seen in recent replies to this thread). What I found to be annoying was that it took me about an entire day to trace back PHP and db calls to eventually find the file I edited to implement my hack only to find how trivial the hack actually was.

We have 3 people at my company who manage our multi-tenant voip server. When I make an edit, I immediately get calls/emails, “hey, voip is saying files have been tampered with, you should check it out”. sigh “Yes, that’s me, I’m working.” That constant back and forth is annoying, but what’s even more annoying is that, because it’s a multi-tenant system and changes are constantly being made, the alerts keep coming back. Every time the “Apply Config” button is pressed the modules get verified again and the alert that I dismissed is back. In addition, 2 big red alert boxes are constantly in the System Overview window in the dashboard. That makes the other 2 admins constantly tell me that something’s wrong and I have to deal with it. Annoying. I understand this is exactly what you want in the case of malicious modifications, but it’s not what I wanted after my legit edits.

@xrobau

I’m hoping that @slonkak will join in and point out any potential pitfalls

As far as self-signing is concerned, you shouldn’t do that. Then there is nothing stopping an attacker from breaking in, creating a key, and signing all of his malicious edits. Making someone reach out to you to get a legit key is the only way to have any sort of verification that signed code was done legitimately (then it’s on you guys to weed out hackers requesting keys )

@tm1000

I just think it’s been overly hashed and everything is laid out on the table no?

I’m sorry for my long diatribes, especially since I seem to be 1 of 2 people who care about editing modules on my server. I’m most likely just wasting the time of everyone here…

So let me just end with some final thoughts on this whole thread:

• The whole reason I joined this thread was because after I found how trivial solving the OP’s request was I was annoyed that no one helped him implement it 87 replies ago. Someone could have just told him, “hey, this is insecure, here are the pitfalls, but if this is something you need to do here’s how you can do it”.
• There seem to be legit attacks on modules happening, so getting rid of the constant sig checking is a bad idea.
• Having a root-owned file somewhere that contains override hashes seems like a good idea. Web-user can’t touch it, so no chance of attack that way. Obviously it needs to be kept out of directories that web-user needs to work with to keep module updates working, but you guys already know that…

So I’ll let it at that. No reason to beat a dead horse.

[dicko]

This is perhaps off topic, but I will share my recipe, it doesn’t use sexy pgp signing but has certain advantages when it comes to recovery and is just good old bash and perl scripting and some general linux utilities already installed on every machine. I have used it successfully for several years and it has occasionally protected me from myself and a couple of old invasions of /recordings

Install rnapshot

yum|apt-get install rsnapshot

with a schedule to suit, I use a thirty minute window, in /etc/rsnapshot.conf the pertinent lines for asterisk are.

.
snapshot_root /rsnapshot/
.
cmd_postexec /var/lib/asterisk/bin/rsnappost
.
retain interval 48
retain daily 7
retain weekly 4
retain monthly 3
.
backup /etc/asterisk asterisketc/
backup /var/www/html webroot/
.
.

/var/lib/asterisk/bin/rsnappost contains

#!/bin/bash
diff -r /rsnapshot/interval.1/webroot/admin /rsnapshot/interval.0/webroot/admin
diff -r /rsnapshot/interval.1/asterisketc /rsnapshot/interval.0/asterisketc

and /etc/cron.d/rsnapshot

.
0,30 * * * * root /usr/bin/rsnapshot interval
30 0 * * * root /usr/bin/rsnapshot daily
0 3 * * 1 root /usr/bin/rsnapshot weekly
30 2 1 * * root /usr/bin/rsnapshot monthly

.

That’s all there is to it, a watchful system monitor that uses cron to email alerts on changes, and that includes changes done into /etc/asterisk perhaps as an audit trail of what got done and when, expected or not. I feel it covers all of the pgp signing verification efforts plus a built in recovery system that covers your “arse” (indeminifies your system equally) for three months. It is very extensible by for example adding /var/spool/asterisk/voicemail or /var/spool/asterisk/backup, is low impact, uses hard-links extensively so little hard-drive space, and doesn’t require an internet connection.

Personally I use one dedicated backup server for many FreePBX instances but it works fine in a standalone situation also.

[xrobau (Rob Thomas)]

@slonkak

If this is the real problem then I believe you’ve added a decent solution with module signing.

Yay! Thanks I’m glad that someone else thinks that this actually solves the problem that it was meant to solve!

@slonkak

Making malicious edits to modules is the effect, not the cause.

And that’s not what we’re trying to stop. We’re just trying to make sure that people know that stuff has been changed. The CAUSE is security vulnerabilities.

We have a [email protected] email address that goes to lots of important people, and we take security very seriously - so seriously that I’m happy to say we haven’t had to release a CVE this year. I really hate writing them, so we do our best not to have to

@slonkak

But in the latter cases the signing *[RedHat

@slonkak

My point was simply that it’s the only way to actually prevent malicious modifications (and even then the good hackers can still finesse the binaries)

]* is just for initial installs.

Actually, it’s not! This is something that a lot of people don’t know but RPM (specifically, dpkg doesn’t do this, and I think it’s a terribly important missing feature) DOES do integrity checks. Try this:

rpm -qVa

That does an integrity check and alert of every file that has been changed on your system, that isn’t tagged as a config file in the spec.

Sorry, my nerd is creeping in here.

@slonkak

My point was simply that it’s the only way to actually prevent malicious modifications (and even then the good hackers can still finesse the binaries)

Exactly. And PREVENTING people changing our stuff kinda goes against the GPL, which is why we go out of our way to make it easy to do so! I <3 the GPL! In fact, I’m one of those people who DON’T think the AGPL is crazy, and you may notice that we’ve been using it for a lot of our new modules.

@slonkak

When I make an edit, I immediately get calls/emails, “hey, voip is saying files have been tampered with, you should check it out”.

If it’s actually happening that much, it might be worth you signing the indemnification and getting your own GPG key signed, so it stops complaining. The other thing is, you’re going to have to redo the changes every time you update, too, or, you need to stop updating… Which then means you may miss a security fix.

Are your changes something that other people are going to want?

@slonkak

In addition, 2 big red alert boxes are constantly in the System Overview window in the dashboard.

There’s an X in the top right hand corner of that box. Once you click on that, you’ll never see it again. I realise that the contrast could be slightly better on the X, and we’ve fixed that in 13, but the CSS in 12 makes it hard to see.

@slonkak

Having a root-owned file somewhere that contains override hashes seems like a good idea. Web-user can’t touch it, so no chance of attack that way. Obviously it needs to be kept out of directories that web-user needs to work with to keep module updates working, but you guys already know that…

I think I have already written this down somewhere, but I can’t seem to find it, so here’s the idea that @tm1000 and I were thinking about.

• A new directory /etc/freepbx.d that contains a subtree of module names. (Thus /etc/freepbx.d/dialplaninjection)
• Each module folder has a module.sig and a key file that must be owned by the root user
• Before GPG checks for and validates the module.sig in the module folder, it checks for the existence and validates the ownership of the files in freepbx.d. If it finds it, it works from that, otherwise it works from the standard one.

That’s still going to require people who want to change code to pull the devtools repo and use the packaging tools, but it also removes the requirement for us to get involved.

@slonkak

As far as self-signing is concerned, you shouldn’t do that.

I think we need to provide a way to let users do that. We can’t stop them from being stupid, we just need to give them as many alternatives as possible so they don’t think using a shotgun to remove a blackhead is their only option

@slonkak

Making someone reach out to you to get a legit key is the only way to have any sort of verification that signed code was done legitimately (then it’s on you guys to weed out hackers requesting keys )

We’re not even doing that. That’s why we put the ‘revoked key’ stuff in there. If someone malicious DOES start publishing nasty modules, we revoke their key, and all their modules are blocked. Obviously, they can simply remove the module.sig and it’ll then start working again as an unsigned module, but this is all about alerting, and making noise about bad things, not blocking.

@slonkak

I’m sorry for my long diatribes, especially since I seem to be 1 of 2 people who care about editing modules on my server. I’m most likely just wasting the time of everyone here…

Hell no! This is great! Are you coming to Linux.conf.au in Feb? We can sit down and have a beer and you can tell me why my code sucks. (Those are the best kind of discussions!). As you know, security should never exist in a vacuum, which is why I love to talk about it. @tm1000 is a bit sick of it by now, but that’s because he’s normal, and I’m an anal-retentive security nazi who can’t stop talking about it

I truly appreciate your input!

[slonkak]

@xrobau

Are your changes something that other people are going to want?

I’m sure the essence of my changes are something that others using that module would want but the way I implemented it was a total hack just to get the job done. In the cxpanel module it enables a separate webserver (f’ing java tomcat). By default it opens a port using HTTP. There is a nice little checkbox to enable HTTPS (in addition to some heavy config editing) that uses a different port. Unfortunately, when you do this none of the links anywhere are updated to https://. So I went through all of the files for that module that had links and changed http:// to https://. Totally not the right way to do it (it should be tied into the checkbox on the admin panel), but I don’t have the time to go through their code and implement it properly.

@xrobau

There’s an X in the top right hand corner of that box. Once you click on that, you’ll never see it again. I realise that the contrast could be slightly better on the X, and we’ve fixed that in 13, but the CSS in 12 makes it hard to see.

Only on the one at the top (see below image):

I see that X and can click it. I’m not worried about this box. It’s the following one that annoys me because it never goes away unless my hack is in place:

Those 2 red boxes are the ones that generate calls to me to “fix things”.

@xrobau

That’s still going to require people who want to change code to pull the devtools repo and use the packaging tools, but it also removes the requirement for us to get involved.

Wait, why? I must be missing something because it would be much easier if I could just generate the SHA hash and vi the module.sig file. What do I need those other tools for if that’s all I’m doing?

@xrobau

Are you coming to Linux.conf.au in Feb?

I’m from PA, USA. Australia is slightly far away . Especially on a professor’s salary ;).

[xrobau (Rob Thomas)]

@slonkak

Wait, why? I must be missing something because it would be much easier if I could just generate the SHA hash and vi the module.sig file. What do I need those other tools for if that’s all I’m doing?

Well, I’m talking about someone who DOESN’T understand how to cleartext sign files. If you want to do that yourself, then sure, but it’s easier to use the script in the devtools repo that hashes the files and signs it for you. I’m lazy

Going back to your other point… Yes. Those two are going to stay, unless I’m convinced otherwise, and you’ll need to make a REALLY good point why. But that’s the reasoning behind us wanting to allow people the equivalent of self-signed certificates, so people who know what they’re doing CAN legitimately remove those warnings in a way that makes it really hard for an attacker to do.

@slonkak

By default it opens a port using HTTP. There is a nice little checkbox to enable HTTPS (in addition to some heavy config editing) that uses a different port. Unfortunately, when you do this none of the links anywhere are updated to https://.

That’s a bug. Can you report it on http://issues.freepbx.org please? Just copying and pasting that comment will be enough, and it’ll get Triaged on Monday (US time).

@slonkak

I’m from PA, USA. Australia is slightly far away.

It’s only far away until you get on the plane. Then it’s close!

[wardmundy]

Going back to your other point… Yes. Those two are going to stay, unless I’m convinced otherwise, and you’ll need to make a REALLY good point why. But that’s the reasoning behind us wanting to allow people the equivalent of self-signed certificates, so people who know what they’re doing CAN legitimately remove those warnings in a way that makes it really hard for an attacker to do.

Delighted that we’re finally making what appears to be some progress. Wouldn’t root privs and a self-signed certificate address the legitimate FreePBX concerns over tampered files especially when we’re talking about a number of modules that have been around forever??

[avayax (Johann Zurner)]

I know one thing for certain, that users like us shy away from using 3rd party modules in the first place, because of the warning that FreePBX generates.
At least there is some hesitation, which in turn would result in fewer usage of 3rd party modules on average. At least, that is what I would expect.

[xptpa2020]

I know this is old, but I’m going to give a pretty simple and easy example for editor to understand.

I simply want to create two modules on our system where their only purpose is to provide some links - one to fop2, one to fop2/admin, and probably one to create a support ticket with our company. All these modules will be doing is add a menu item that will reference those links. I did not write our company’s ticket system and I do not own the intellectual property of fop2. Nicolas at Asternic could ask me to stop writing modules that are linking to fop2 and I would gladly oblige, but the modules that I will be signing are simply shortcuts referencing it. I understand there could even be some gray area here, but the modules regardless are only going to exist on the PBXes that I manage and nothing more.

If I were to redistribute these modules, even ones as simple as a shortcut to another product, then it would be more questionable. But we aren’t redistributing them, so we won’t worry about it.

I think your main focus, editor, should be on not redistributing whatever module you are attempting to sign and use. Don’t focus on the signing and using part. Just do it and don’t redistribute it. If you could you would have contacted the original author, but you can’t - so don’t worry about it.

Perhaps I’m being too laid back here, but I wouldn’t make a bigger issue out of it than it should be. If it is only going to be on your systems as it is then don’t worry about it. If you feel terrible still then keep his name referenced in the comments and author section of the module.xml file. If you don’t know his name, then write it out to “that guy”.

Just to make you feel more comfortable, here’s some legal stuff:

The information contained in this forum post is provided to you “AS IS”, does not constitute legal advice, and I am not acting as your attorney. I make no claims, promises or guarantees about the accuracy, completeness, or adequacy of the information contained in this forum post.

The law changes very rapidly and, accordingly, we do not guarantee that any information on this forum post or our affiliated forum posts are accurate and up to date. Additionally, the law differs from jurisdiction to jurisdiction, and is subject to interpretation of courts located in each county. Legal advice must be tailored to the specific circumstances of each case and the tools and information provided to you may not be an appropriate fit in your case. Nothing that you read or is provided on this forum post should be used as a substitute for the advice of competent legal counsel.

Postings in the Forums, Message Boards, Guides and any other areas of and through our forum post are for educational and information purposes only. They are not legal advice or legal opinions. Transmission of the information is not intended to create, and receipt does not constitute, a lawyer-client relationship between xptpa2020, and you or anyone else except as explicitly set forth in a signed writing. The opinions expressed in the postings may be opinions of the authors and do not reflect the opinions of xptpa2020, its employees or agents. The seals, trademarks, or other advertising that may appear on our site or within our articles shall not be considered to create any sponsorship or affiliation with such other forum post or author. xptpa2020, or others that provide information on or through this forum post will not be liable or responsible to you for any claim, loss, injury, liability, or damages related to your use of this site or any site linked to this site.

[xrobau (Rob Thomas)]

@xptpa2020

I know this is old

It is, and it’s out of date. Locally signable modules have been around for ages (and are documented!). So it’s kinda not relevant. Sorry 8)

[marcelser]

What’s not documented at least not here:
https://wiki.freepbx.org/display/FOP/Signing+your+own+modules#Signingyourownmodules-LocalKeyWalkthrough
or here where dev env is explained
https://wiki.freepbx.org/display/FOP/Setting+up+a+Development+environment+from+the+FreePBX+Distro
or here:

What’s not clear is, what are the minimal steps to just be able to sign modules using the “sign.php” from devrepo when I don’t want to switch the whole installation to dev mode. I just want the signing tools and that part of documentation is missing.

Can someone please provide the necessary steps? Is it just install git and clone devrepo or is that not enough?

[tm1000 (Andrew Nagy)]

I’m not sure what you think is missing. Can you clarify more in depth. If you checkout the dev tools repo you aren’t putting your whole system into dev mode.

[marcelser]

My bad. I really missed a part (must have overlooked it). So it’s really just checking out dev-repo and running signing as described.