I installed for testing, and also to be able to assist here in the Forum, SuiteCRM 7.11.0 on a web hosting server using Linux.
The hosting server prompltly blocked the whole domain because it claims to have detected a file containing the php.exe.globals malware.
The file is;
I opened and examined it to find that it contains a number of curl_exec calls with rm commands, which I assume that this is the cause of the (false) postive.
The hosting company refuses to reactivate the whole domain unless the file is removed.
Can the file be safely removed?
Why is the folder tree structured “vendor/elasticsearch/elasticsearch/tests/Elasticsearch/Tests/”
This seems a little redundant. Why not simplify it to “vendor/elasticsearch/tests/” since above folders are empty?
There seem to be a few other of these “test” scripts which seem to be there because some developer has forgotten to remove them so can they all ve removed? Why not remove them in the next release?
Anyone from Sales Agility could answer?
This file is blocking the usage of the latest version of SuiteCRM.
the only think I can see in that file is shell_exec() function , may be they don’t support it?
and instead of disabling it, they decided to simply block it
any problems trying to remove that file? I assume you will not be using elastic search anyway
but it may be better to change your provider if they cant be even bothered to explain whats the problem
I would like to know from SalesAgility if it is OK to remove all the test files in the elastic search folders (these are the files that the antivirus does not like, and thus the provider blocks everything!).
Sorry amariussi, I am only reading this now for the first time :ohmy:
I usually catch all new threads but I must have missed this one, sorry.
The files under vendor/elasticsearch are the responsibility of that package. It’s composer that puts the files in there. Those are probably tests written by the Elasticsearch developers, though I don’t see them on their repo, they must be coming from somewhere else.
I suggest moving that directory to outside the web directory (as a backup so you can put it back if necessary).
Not an important issue but useful information.
If I get some errors I will post them.
Dear @pgr and @amariussi,
I have also got the same message from hostgator.in.
As provider of Shared Hosting services, we monitor the usage of all our customers to ensure that our Quality of Service is not adversely affected. Our goal is to ensure that one customer should not affect all the other customers on the same server.
As part of our routine monitoring, we have observed that some of the files hosted on this server belonging to luminisindia.com hosted under your account, has some malicious files hosted. In order to prevent blacklisting of our service with various service providers, we have blocked outbound port 80, 443, 587 and 465 for this domain name as a precautionary measure. Here are the details of the files that were detected to be malicious.
/home/luminisi/public_html/SuiteCRM/cache/upgrades/temp/0n48Sr/SuiteCRM-Upgrade-7.10.x-to-7.11.1/vendor/elasticsearch/elasticsearch/tests/Elasticsearch/Tests/YamlRunnerTest.php /home/luminisi/public_html/SuiteCRM/cache/upgrades/temp/6L7azM/SuiteCRM-Upgrade-7.10.x-to-7.11.1/vendor/elasticsearch/elasticsearch/tests/Elasticsearch/Tests/YamlRunnerTest.php /home/luminisi/public_html/SuiteCRM/cache/upgrades/temp/LQNCgU/SuiteCRM-Upgrade-7.10.x-to-7.11.1/vendor/elasticsearch/elasticsearch/tests/Elasticsearch/Tests/YamlRunnerTest.php /home/luminisi/public_html/SuiteCRM/cache/upgrades/temp/XX0wpX/SuiteCRM-Upgrade-7.10.x-to-7.11.1/vendor/elasticsearch/elasticsearch/tests/Elasticsearch/Tests/YamlRunnerTest.php /home/luminisi/public_html/SuiteCRM/vendor/elasticsearch/elasticsearch/tests/Elasticsearch/Tests/YamlRunnerTest.php
We have currently altered the permissions of the files so that they become immutable. This means you will not be able to read or write to the file.
We strongly suggest you to scan all the above listed files for any vulnerabilities. If the files are part of some plugins of your CMS, then we suggest you to update the plugin to the latest version or contact the plugin developer directly.
Please treat this as an alert to take immediate action and remove the malicious file(s) within the next 48 hours. If we detect malicious files in your account again, we will be taking strict action against the domain which might cause disruption of the service
Kindly suggest what to do.
Thank you @theachiever
Exactly same problem.
I think that we should add an issue in gitHub. Could you take care @theachiever? I am a little busy these days. Thx!!!
Additionally I don’t like the folder structure of these elasticsearch files: there is a(n apparently) usless double repetition of folders!
I’ve looked into this (just a bit) and I believe that since those files are part of the tests, they won’t be installed if you run composer with the “no-dev” flag, which is what is recommended by SuiteCRM…
So this seems to be a 3rd party problem, which only happens to people who didn’t follow instruction given on-screen by SuiteCRM, and in Docs (if I am not mistaken).
Maybe there is some room for improvement on our part, but I’m not sure what it could be. I don’t know much about composer but maybe there is a way to make it default to “–no-dev”?
I found it perplexing. Because I knew nothing about Elastic Search functionality.
I had missed 3-4 upgrades of SuiteCRM, before I came back and decided to update it with version 7.11.1.
I simply don’t know what to do now!
However, I have raised a issue at Github: 6978
Still I need the solution as a part of better instructions, so that I can upgrade to 7.11.2 and get everything working normally and fully.
Then I would try to unblock the ports which are blocked by hostgator.
Unfortunately there’s not much we can do here until this gets fixed by the elasticsearch devs. This file is always going to get pulled down when you run a composer install --no-dev or composer update. We can’t lock the composer.lock to an older version either as this file has always been present.
As a temporary solution i’ll update the installer and upgrade packs for 7.11.2 to remove this file but it won’t stop anyone from re-downloading it when doing composer installs.
However you understand that this solution may not be the optimal one because it will create plenty of problems on working systems.
This also raises the issue about composer: personally, although I appreciate the benefits, I never use it for the following reasons:
you totally lose control
upgrades to new versions with composer may bring parts that are not compatible with your configuration and might become quite complicated to revert back once you have find out.
using composer requires extra training and learning yet another tool
using composer on windows is not exactly the same as in linux so this adds to the learning curve complexity
certain (I would say most) shared hostings will not allow you to use composer
you may get unwanted software as in this case and you can’t control it
The use of a composer.lock file ensures that only a specific version of each package gets pulled down every time you run composer install. The only reason we are encountering an issue here is that every version of this dependency contains the unwanted file.
This may be true but the alternative is maintaining 100s of packages which receive constant updates and security fixes.
I don’t have much experience with composer on windows but again, the alternative would be us maintaining these dependencies ourselves.
Shared hosting can be very restrictive, there’s not much we can do about this. Some shared hosting won’t even allow you to change the php.ini.
I’d agree that if we were to maintain every package in SuiteCRM manually it would indeed give us more control but this would involve continuously checking for new releases from 102 different dependencies which just isn’t realistic for such a large codebase.
@Dillon-Brown please don’t misunderstand me. I agree in full with your comments and I also think that using composer is a big time saver for SuiteCRM (and increases the overall quality).
@amariussi, no worries, I appreciate the discussion :). As a temporary solution I’ve removed these files from the installers and added them to the files_to_remove part of the upgrade process, this won’t stop anyone from re-downloading them when running composer update though…
I’m currently looking why the elastic-search is triggering this malicious file warning, I think I’ve narrowed it down to SiteLock Website Security but this would need to be resolved on their end or the elastic-search guys. It’s possible we might just need to remove it from composer and manually include it without the tests directory.