CVE-2018-7251 | Info Disclosure due to public error logs
pehelwan opened this issue · 15 comments
An issue was found in Anchor CMS leading to Info Disclosure.
Thanks for spotting this! Would you be able to advise on a solution? Other than the user not turning on errors on live sites?
Yes , Its clear here that this file should in fact be not accessible to anyone but administrator so its a case of Improper Access Control rather , only admin should have access to it . Can you elaborate what do you mean by "Other than the user not turning on errors on live sites?"
Regards,
@pehelwan I didn't realise this error log isn't your own, I thought it was your test. Surely you shouldn't be reporting that url publicly as you're only making the security issue worse?
My query was to whether you have a bug fix in mind for the security problem?
Temporary - Forbid access to errors.log until further fixture
Long Time - Fixing access controls to admin only in sensitive areas like error logs files
This just got assigned CVE-2018-7251 and published.
@pehelwan thank you for reporting this. I understand that it must be quite easy to get a hold of the error log, but I would prefer not to have it posted on an open source forum for people to easily locate and use on their site without their consent. I've redacted the url for now.
As for the bug we'll have to do some investigation, but I'm guessing the only way that error log got uploaded was that the user deployed the site with a development setting turned on? Would that be the case @CraigChilds94?
@pehelwan thanks for updating the issue title, will help with future referencing. Sorry but we don't have a place other than this GitHub repo to provide credit for bug reporting
@pehelwan that is an interesting idea, but I would think it would be only for people who have contributed a fair amount of development to the project
Fixed by #1248
This is not going to fix it quite well. What about other webservers like nginx who ignore .htaccess?
@KennethWussmann I will admit we should provide examples in the documentation, but someone who uses nginx probably also has their own (VPS) server. Reasonably, you can expect those people to be proficient enough to configure nginx on their own.
There are way too many web servers to provide examples and consideration for, but the typical audience of AnchorCMS is likely using shared hosting with Apache2 so that is always going to be top priority.
@Radiergummi You should definitely provide this information in the installation process documentation, that you may punch holes in your system and loose your database.
Maybe there should also be the opportunity to log to a different file/directory outside of the default static served directory.
in the ngnix conf file add the following directive -
location ~ /anchorcms/errors.log {
deny all;
}
Hope this works !
@KennethWussmann although not too obvious, the log file output directory can be changed by using a custom log reporter, refer to anchor/config/error.php in your installation. On L15, change the output path to a directory outside of your web root.
We are currently reviewing the logging functionality and in the middle of setting up CI including E2E/unit tests to prevent things like these from happening in the future. I hope you understand, however, that this is a project we work on in our spare time and some things might take a little to be properly implemented.
@pehelwan nginx was just an example to show that this issue is not fixed with adding a .htaccess file.
@Radiergummi Well, letting the users messing about with your source code and deal with it again after updating doesn't seem to be a good solution either.
For sure it's a DevOps problem. There should just exist the opportunity for them to prepare their systems.