Yes it is it basically says if you know the password you can execute php code , its fucking stupid.
This CVE should not have been issued as Critical as it relies on a premis of
"However, what is overlooked is that the Apache HTTP Server by default no longer enables the AllowOverride directive, leading to data/users/admin.xml password exposure."
"If a someone leaks the API key and the admin username, then they can bypass authentication. "
We can add a check to GS that would check if files are publicly accessible, and shut gs down entirely.
I mean the alternative is to make sure users can move these files above public, or lock them down some other way.
We also have chmod rules which can be added or adjusted
Example to Protect system files for Apache versions older than 2.4:
<FilesMatch "\.(inc|info|info\.json|module|sh|sql)$|^(\..*)$">
Order allow,deny
</FilesMatch>
<Files .htaccess>
order allow,deny
deny from all
</Files>
But I doubt anyone using a shared host has access to apache config and most host should have htaccess enabled no? How else are users to config their sites?
2019-06-15, 16:26:27 (This post was last modified: 2019-06-15, 16:29:23 by Felix.)
If a webmaster does not have access to apache config, then it can be asked through the hosting support.
Most cpanels access allow to move files above the public html root.
I am a big fan of php side, js side fallback health check or upgrade check if we can get to sensitive files or detect that overrides is off? Then we can lock down all permissions and warn user that it needs to be remedied and passwords changed.
Another option is to allow moving a hash or salt into a php global via apache or somehow making sure it cannot be fetched or exists in any file in public
2019-06-16, 02:05:52 (This post was last modified: 2019-06-16, 02:21:55 by Felix.)
Here is to protect system files for Apache versions 2.4 and newer:
(I also added xml) Put this code in the .htaccess file
that resides in the root of your website
Code:
<FilesMatch "\.(inc|xml|info|info\.json|module|sh|sql)$|^(\..*)$">
Require all denied
</FilesMatch>
<Files .htaccess>
Require all denied
</Files>
2019-06-16, 02:17:28 (This post was last modified: 2019-06-16, 02:22:48 by Felix.)
To prevent certain files to be included by attack or remote scripts,
please read this article, especially the part with the function blockit(),
and the part on the bottom to prevent XSS-style attacks.
Yeah the problem is this blocks theme xml files, we tried this before, I guess this is ok and users will have to explicitly allow specific file names if they need it
Thanks for the reply on this Shawn. I didn't know this.
I will try out all possible variations and see which ones
work best. I will post back about it.
Hi,
If I understood everything (thanks to the automatic translation google), it's not so serious, but possibly a little when even if we do nothing ...
Thanks @shawn_a and @Felix for these explanations and first troubleshooting solutions ...
If you do a research with Google you will not find any news about GS websites that have been exploited.
Compare that to the news about the so called "most popular cms" out there ( I won't mention any name
to avoid a flame war) then you will know that GS is very safe to use.
All that we are doing here in this thread is to discuss new ways how to make it even more harder for attackers
to exploit websites made with GS.
(2019-06-22, 01:49:52)shawn_a Wrote: If you run a gs site you should make sure your data directories are protected via htaccess and have strict permissions only for php and not public etc
Is this documented enough? I always assume GS installation takes care of the correct htaccess files.
2019-06-22, 06:33:01 (This post was last modified: 2019-06-22, 06:42:14 by Felix.)
Quote:Is this documented enough? I always assume GS installation takes care of the correct htaccess files.
I think what Shawn means is, if after you have installed GS and are going to add your own custom directories,
then you have to protect them your self with a .htaccess file.
2019-06-22, 17:58:05 (This post was last modified: 2019-06-22, 17:58:30 by Felix.)
Quote:Thanks, I just thought that this kind of info, including adviced permission settings would be nice in the wiki (docs).
Yes I totally agree. This info, together with adviced chmods should be added to the Wiki.
Or maybe add it to a GS installation, or include it with a read me first text file ?
I think Shawn should give someone permission to update the Wiki and also to remove
spam from the forum.