v3.3.16 Vulnerability - CVE-2020-24861

[Brex]

My host has just applied a 403 restriction to my Get-Simple installations - v3.3.16
https://nvd.nist.gov/vuln/detail/CVE-2020-24861

They site the reason being that this version suffers from the above vulnerability.

Therefore I am unable to manage the sites until this has been resolved. As far as I can see, this is the most stable current version available. Anybody know if this has been looked into or resolved?

Regards - Neil

[Felix]

Where is the real problem ? You need to have access to the backend to execute this.
The get-simple cms is safe on the front end where it matters.

[Brex]

Where is the real problem ? You need to have access to the backend to execute this.
The get-simple cms is safe on the front end where it matters.

Yes, it is safe on the front end and the sites continue to operate as normal. However, as you say it applies to the back end, which prevents any content being added or updated - which matters very much.

[Felix]

Then who is executing these strings in the backend in the first place ? You ? Somebody from your Host ??

[Felix]

1) Turn off Mod_Security on your Host
2) Edit / update your website
3) Turn on again Mod_Security

[Brex]

Then who is executing these strings in the backend in the first place ? You ? Somebody from your Host ??

Myself. I update customer websites as and when required.

[Brex]

1) Turn off Mod_Security on your Host
2) Edit / update your website
3) Turn on again Mod_Security

I think I would need to request my host to turn Mod_Security on/off which could be a number of times a day in some cases.

[Felix]

I think I would need to request my host to turn Mod_Security on/off which could be a number of times a day in some cases.

These days Hosts have Mod_Security already in their CPanel for their clients to configure,
my Host has. Sometimes it is burried away under "Advanced Settings"

Another solution is to edit / update your website locally on a local server stack on your laptop
and upload the changes to your host. This will avoid edit strings being blocked by your Host,
when editing online.

Having a local copy of a website is always very recommended not to be at the mercy of a Hoster
because you never know what will happen with their future updates, restrictions and policies.

I have local copies of all my websites.
All you need is for example a Laragon stack on your laptop (windows)
and an FTP client to upload your edits and changes.

If you use WinSCP or Notepad++ they have ftp already integrated in the IDE
and your local editing will be synced as if you were editing online

F.

[Brex]

I think I would need to request my host to turn Mod_Security on/off which could be a number of times a day in some cases.

These days Hosts have Mod_Security already in their CPanel for their clients to configure,
my Host has. Sometimes it is burried away under "Advanced Settings"

Another solution is to edit / update your website locally on a local server stack on your laptop
and upload the changes to your host. This will avoid edit strings being blocked by your Host,
when editing online.

Having a local copy of a website is always very recommended not to be at the mercy of a Hoster
because you never know what will happen with their future updates, restrictions and policies.

I have local copies of all my websites.
All you need is for example a Laragon stack on your laptop (windows)
and an FTP client to upload your edits and changes.

If you use WinSCP or Notepad++ they have ftp already integrated in the IDE
and your local editing will be synced as if you were editing online

F.

Good advice indeed, but..
My Host is in my experience of more than ten years with them, absolutely excellent in all respects. This after having worked with many others over the years from the worst and everything in-between. They control all aspects of server security, and I am grateful for that. So unfortunately I have no access to Mod_Security via cPanel.

Local web server:
Yes, it certainly is an option. I've used local severs for many years mainly due to the lower bandwidth days prior to the broadband era which enables us to work seamlessly remotely. Since then I have found it unnecessary - until perhaps now... I do have current backups of all accounts though.

Will this issue be resolved in the next GS version upgrade and when is it likely to be released (stable)?

[Felix]

If your host has no Mod_Security config in your CPanel, then no matter your high words about them,
you host is providing an outdated CPanel. And let there be no mistake about Hosting providers,
for any Host a client is simply collateral damage when problems can not be solved.
It is up to you to find a Host with a complete CPanel (including mod_security)

Will this issue be resolved in the next GS version upgrade and when is it likely to be released (stable)?

Somebody has to dive in the 3.3.16 core and find the php that is responsible for stripping out
not allowed characters in a string. Can't promise if I can find the time for it soon.

[Brex]

If your host has no Mod_Security config in your CPanel, then no matter your high words about them,
you host is providing an outdated CPanel. And let there be no mistake about Hosting providers,
for any Host a client is simply collateral damage when problems can not be solved.
It is up to you to find a Host with a complete CPanel (including mod_security)

Will this issue be resolved in the next GS version upgrade and when is it likely to be released (stable)?

Somebody has to dive in the 3.3.16 core and find the php that is responsible for stripping out
not allowed characters in a string. Can't promise if I can find the time for it soon.

Yes, the Host is excellent. They have already worked with me to override Mod_Security as and when I require. However I would prefer if this wasn't needed at all, and so the reason for my enquiry here. Many thanks to all who have helped.

[Knobbles]

There is line 81 in admin/settings.php:

PHP Code:

if(isset($_POST['permalink'])) { 
  $PERMALINK = trim($_POST['permalink']); 
 } 


Replacing this with

PHP Code:

if(isset($_POST['permalink'])) {
    $badchars = array('<',  '>',  '(',  ')',  '{',  '}',  '[',  ']',  ' ',  "\t",  "\r",  "\n");
    $PERMALINK = str_replace($badchars, '', $_POST['permalink']); 
} 


i.e. removing all kinds of brackets, plus freespace, should bork any attempt of scripting reliably.
You might go even further, setting $PERMALINK to "" when detecting any of them in $_POST['permalink'].
These characters should not be part of an url anyway.

What am I missing?

[shawn_a]

var_out()

also any of these posted in github have already been addressed