Hi, this is the first time I start a personal conversation
I just wanted to thank you for your calm and brilliant explanation of the “security issue”. David removed the thread as a flame war. If you’d want to place your answer elsewhere, on a github issue like https://github.com/mautic/mautic/issues/2034 perhaps, I saved it for you:
Quote:
Well, thanks for confirming what I thought in the first place but I didn't have any proof. Your tech support admin is clueless as well. One of the first things you do in securing a PHP installation is to setup open_basedir especially when using vhosts. That's not my recommendation, that's from well-known security practices documented not only internet wide, but on PHP's secure practices site as well. You, like most people, hosters include, don't know about or use open_basedir as an added measure to secure PHP installs because it's commented out by default in php.ini. Having open_basedir empty is essentially the same as the commented out default. Your PHP has no restrictions filesystem wide where the user your web server runs under has read access, at a minimum, and has write access to any world writeable file and directory or group writeable file and directory.
It's one of the principle means of preventing any XSS or rogue PHP vulnerability causing damage systemwide. Don't take my word for it, here's an explanation on PHP's site what it's supposed to prevent (https://secure.php.net/manual/en/ini.core.php#ini.open-basedir) or just look in the image above. Open_basedir is a poorman's "jail".
However, this supposed vulnerability doesn't work the way you think it does. If you don't know what a random generator is or what it does relating to this by accessing the entropy pool in urandom generated by devices drives simply running in kernel space, it's best to remain quiet. The discussion explains how the v2 version ignores the random generator in OpenSSL and uses the random generator from Linux's kernel space (/dev/urandom) instead. With a correctly locked down open_basedir restricted only to where PHP files reside, PHP rightly blocks access outside access except for the directories whitelisted which is good practices.
It's one of the principle means of preventing any XSS or rogue PHP vulnerability causing damage systemwide. Don't take my word for it, here's an explanation on PHP's site what it's supposed to prevent (https://secure.php.net/manual/en/ini.core.php#ini.open-basedir) or just look in the image above. Open_basedir is a poorman's "jail".
However, this supposed vulnerability doesn't work the way you think it does. If you don't know what a random generator is or what it does relating to this by accessing the entropy pool in urandom generated by devices drives simply running in kernel space, it's best to remain quiet. The discussion explains how the v2 version ignores the random generator in OpenSSL and uses the random generator from Linux's kernel space (/dev/urandom) instead. With a correctly locked down open_basedir restricted only to where PHP files reside, PHP rightly blocks access outside access except for the directories whitelisted which is good practices.
