Non-Dismissible Software Generated End User Warnings

Should software developers include non-dismissible methods to warn end users of potential danger

  • Yes, Someone has to be responsible

    Votes: 1 9.1%
  • No, I paid for the software i should have total control

    Votes: 10 90.9%

  • Total voters
    11

fixer

I'm In My Prime
Joined
Jan 28, 2010
Messages
2,054
Should software developers include non-dismissible methods to warn end users of potentially dangerous versions of software being used.

like when security patches are ignored by webmaster putting visitors at harm.
 

LeadCrow

Apocalypse Admin
Joined
Jun 29, 2008
Messages
6,818
No, for both users and non-admins, dismissible and non-dismissible. A notice would always used as a mean to pressure webmasters into updating... or paying up.

A notice would fail to list all the ways a user could be vulnerable anyway. Even a properly updated board can be vulnerable if your webhost's server stack is running old versions of libraries. How many do you think upgrade their server farm as soon as new libs are released?
 

Solidus

Stupid machines!
Joined
Jan 23, 2012
Messages
605
Absolutely not. I'd prefer the freedom to make a risk and pay the consequences.
 

capbiker

Aspirant
Joined
Jul 12, 2005
Messages
34
Another thing to consider. Would be, would hackers looks for non dismissible messages. To know which websites are have security holes, and attack them.

Also what if the webmaster apply the patches manually. How would the dismissible messages, know that it's been fixed. But the webmaster, don't install the latest version of the board. Due to many installed apps, modifications etc.
 

Ryan Ashbrook

IPS Developer
Joined
Jan 26, 2004
Messages
3,571
No - doing so would be wholly irresponsible, and I do not know of a software that does display such messages.
 

Maddox

Habitué
Joined
Jul 29, 2016
Messages
1,243
I voted no - but with a caveat. For those that don't understand the backend workings of servers (that's me BTW) such notices are unnerving and because they are beyond my understanding (and often beyond my control) they put the fear of God into people. Contacting their host will almost (depending on how flexible their host can be) certainly not be able to help other than to suggest a customised php.ini file. This is not a difficult thing to do, but some hosts do not have the facility to make that file recursive - so it only affects the files in the folder it appears in. There are (at last count) 730 folders in the last iteration of IPS Suite (for me that's forums, pages, calendar) so that would mean I would have to copy my php.ini file 730 times in order for it to be fully active.

My host does not use suPHP so it's not possible to mitigate a recursive option for a single php.ini file. The only option is to change host, that's not always an easy option especially if you have numerous domains and different websites to service. Moving to a VPS is also not always an option when you are on a limited budget and are not monetising a site; with not knowing the backend workings of servers a managed VPS takes costs even higher and even then you do not always have root access to make changes. I've contact a few recommended hosts and this is the information they have fed back to me.

What also puzzles me is if these php commands are dangerous why are they enabled at all? Why do they even exist? Perhaps someone may have a use for them, but that brings me back to why use them if they are considered dangerous?

Puzzles me lol. So if anyone with backend server knowledge can please educate me I would appreciate it lol.

As for giving examples of what to do to mitigate these php functions within the ACP - I'm all for that too, but I would imagine they would have to be pretty generic as not all hosts are equal.

;)
 

Ryan Ashbrook

IPS Developer
Joined
Jan 26, 2004
Messages
3,571
What also puzzles me is if these php commands are dangerous why are they enabled at all? Why do they even exist? Perhaps someone may have a use for them, but that brings me back to why use them if they are considered dangerous?

They can be useful on a server that is completely locked down, whose primary function is to just perform basic day-to-day tasks that is disconnected from the outside world.

They are dangerous because they completely bypass any and all restrictions that may be in place. So, for instance, if the open_basedir directive is enabled and configured properly (so PHP can only access the users home directory and the tmp directory). Then trying to do something like this, to see and remove the contents of "root" will fail:

PHP:
dir('/root');
rmdir('/root');

But this would work just fine:

PHP:
exec('ls /root', $output);
exec('rm -rf /root');

Obviously that is a very basic example that doesn't take into consideration other server level security enhancements (such as su), but my point remains. A better example would probably be:

PHP:
// current working directory: /home/user1
$dir = dir('/home/user2');

// Output the contents of user2's homedir - this will fail because /home/user2 is outside of the open_basedir directive
foreach( $dir AS $d )
{
    var_dump( $d );
}

// Remove user2's homedir entirely - again, fails because rmdir() knows it's not allowed to move outside of the current working directory
rmdir('/home/user2');

// List user2's homedir using exec - these will work because exec() has no knowledge of open_basedir.
exec('ls /home/user2', $output);
echo $output;

// Remove user2's homedir using exec - again, exec has no knowledge that it shouldn't be able to do this, because all it's doing is issuing system level commands
exec('rm -rf /home/user2');

Most backdoor scripts can be blocked completely when exec(), system(), shell_exec(), etc. functions are disabled. So even if there is an exploit in your software, that would allow a hacker to upload a backdoor, then you are still somewhat protected because these functions do not work.
 

Maddox

Habitué
Joined
Jul 29, 2016
Messages
1,243
They can be useful on a server that is completely locked down, whose primary function is to just perform basic day-to-day tasks that is disconnected from the outside world.

This interesting, because hosting companies are not in such a complete lockdown, yet they allow these functions to be active; it doesn't make sense to me for them to allow these functions to be available unless they have some other security measures in place to negate them - is this possible?

I am a complete noob when it comes to servers - I know how to access them using an FTP client, how to create a php.ini file and an .htaccess file (with some help from Google) beyond that I go glassy eyed lol. I cannot believe that hosting companies are so naive when it comes to this, yet there they are doing what we are told they shouldn't be doing.

Appreciation to Ryan Ashbrook for taking the time to explain why these functions should not be enabled.

;)
 

Ryan Ashbrook

IPS Developer
Joined
Jan 26, 2004
Messages
3,571
This interesting, because hosting companies are not in such a complete lockdown, yet they allow these functions to be active; it doesn't make sense to me for them to allow these functions to be available unless they have some other security measures in place to negate them - is this possible?

Sure - it's possible, but when it comes to security it's always best to be overly cautious. Proactive rather than reactive, some might say.

EDIT: That said, there is a balance of course - don't install add-ons that simply say "increased security!" - do your research first. Some say that, but really do nothing other than hinder the end user experience and cause issues "fixing" security holes that aren't actually security holes (I'm looking at you Suhosin... bane of my existence <_<).
 

Maddox

Habitué
Joined
Jul 29, 2016
Messages
1,243
Proactive rather than reactive, some might say.

I completely agree with this - prevention is far better than cure in this instance.

I would love to go for a root accessed VPS (very reasonably priced) but I haven't a clue what to do with it. I can get a managed VPS, but man the price simply triples and there is no root access so making changes is down to the host.

:)
 

Ryan Ashbrook

IPS Developer
Joined
Jan 26, 2004
Messages
3,571
Suhosin whats wrong with that Ryan Ashbrook

Most people will configure it improperly, which can break things with no indication as to why it's broken. For instance, there is a setting in Suhosin to encrypt to contents of cookies set by PHP. While this, in and of itself, is not a problem, it means that JavaScript can no longer read a cookie set by PHP. For most sites, this isn't really necessary because cookies set won't contain anything that truly needs to be encrypted that isn't done already by the site itself.
 

Ryan Ashbrook

IPS Developer
Joined
Jan 26, 2004
Messages
3,571
It's not inherently bad, it just makes debugging issues difficult if it's not configured properly or the site admin gets overly zealous with it.
 
Top