It has been 7 days since @xrobau (The guy who originally wrote FreePBX) provided a solution. Has this been applied, adapted, worked on? Even though in the grand scope of things this is a minor issue it still has a CVE applied against it which means the people who care about such things like major corporations, the government, my cousin Jed all need to see a fix version released so when this comes up in compliance ventures they can say resolved. I would assume with all the work mostly done this should be in edge and perhaps most of the way through QA since it is a SECURITY ISSUE THAT YOU ARE NOW AWARE OF FOR AT LEAST 8 DAYS IF NOT SOONER. While we would all prefer responsible disclosure via official channels that apparently didnât happen. That said the issue exist, you have acknowledged it and a fix has been provided. What is missing to make this matter to someone? Should I go through the âproper channelsâ and submit this information on github?
To answer you question, as far as I can see there has been no updates on this. I donât see a fork that is handling this nor do I see an active branch that is dealing with it on the main FreePBX/framework repo.
The solution that @xrobau suggested already exists in the _proccess_archive() function. It wonât accept a file format that doesnât match an accepted file format for modules. So really that process needs to be done before hand but that makes no sense since other methods of installing a module also call on _process_archive() to do those checks as well.
There needs to be client side validation added to help stop a bad format from even being uploaded. In the case of downloads, that check should happen before the download is even started.
As for the server side, perhaps we need to pull the validation from _process_archive() and make a new function _validate_archive() that other functions can call on. If _validate_archive() doesnât return an error, move the file to needed location and run _process_archive() to handling the processing of the module (expanding, installing, etc)
Side note: I have noticed that we canât assign ourselves to tickets like we could in Jira.
FYI, As the unofficial, volunteer open source community advocate I went ahead and submitted clarifications and updates to MITRE for the CVE that explains everything out. It will likely be downgraded or invalidated. That doesnât mean there arenât bugs and as long as there is a valid CVE it does need to have something done. I think rather than throwing the baby out with the bath water a few extra checks and some garbage collection is fine.
Do a clientside validation of tgz, tar.gz, tgz.pgp and on the server side do a mime check for application/x-gzip and application/pgp-signature and if the file fails primary validation delete the file and return an error. No complex code or ninja rewrites. A few simple lines.
@BlazeStudios when I work on tickets I usually reference it in the PR and Kapil will close em out. They donât ever get assigned to me.
True, but it was more about being able to track if someone is working on an issue or claimed something to work on. Avoids the whole multiple people working on the same problem because they didnât know anyone else was working the issue.
Guess you could just indicate it in the notes.
Their policy on the security reporting github technically says that they respond within 3 days and resolve within 60. Whether that is appropriate, thatâs not for me to say.
Timeline
We aim to initially respond to security vulnerability reports within 3 US business days. We aim to resolve security vulnerability reports within 60 US business days, but may need additional time to be able to do so.We will communicate with the reporter throughout the process providing updates regarding resolution and timeline.
Once published the reporter is welcome to make additional posts about their finding alongside the published disclosure that Sangoma will provide.
