Hi Everyone,
Our site is at https://www.cryptopp.com/wiki.
Since the Mediawiki 1.34.3 upgrade, the wiki serves each page with the following at the top:
<br /> <b>Warning</b>: php_uname() has been disabled for security reasons in <b>/var/www/html/w/includes/GlobalFunctions.php</b> on line <b>1333</b><br /> <!DOCTYPE html> <html class="client-nojs" lang="en" dir="ltr"> <head> ...
Any ideas how to fix things?
Thanks in advance.
====================
There seems to be a fair amount of php_uname:
/var/www/html/wiki # grep -IR php_uname ./* ./extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneEngine.php: if ( php_uname( 's' ) === 'Linux' ) { ./extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneEngine.php: if ( php_uname( 's' ) == 'Linux' ) { ./extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneEngine.php: if ( php_uname( 's' ) == 'Windows NT' ) { ./extensions/CodeEditor/modules/ace/mode-php.js: 'php_ini_loaded_file|php_ini_scanned_files|php_logo_guid|php_sapi_name|php_strip_whitespace|php_uname|phpcredits|phpinfo|phpversion|pi|' + ./extensions/CodeEditor/modules/ace/mode-php.js: "php_uname": [ ./extensions/CodeEditor/modules/ace/mode-php.js: "string php_uname(void)", ./includes/debug/logger/monolog/MwlogHandler.php: $this->hostname = php_uname( 'n' ); ./includes/debug/logger/monolog/SyslogHandler.php: $this->hostname = php_uname( 'n' ); ./includes/debug/logger/MonologSpi.php: * 'args' => [ 'mediawiki', php_uname( 'n' ), null, '', 1 ], ./includes/GlobalFunctions.php: return php_uname( 'n' ) ?: 'unknown'; ./includes/installer/Installer.php: $os = php_uname( 's' ); ./includes/Pingback.php: 'OS' => PHP_OS . ' ' . php_uname( 'r' ), ./includes/Pingback.php: 'machine' => php_uname( 'm' ), ./maintenance/benchmarks/bench_wfIsWindows.php: return substr( php_uname(), 0, 7 ) == 'Windows'; ./maintenance/benchmarks/Benchmarker.php: php_uname( 'm' ), ./maintenance/benchmarks/Benchmarker.php: php_uname( 's' ), ./maintenance/benchmarks/Benchmarker.php: php_uname( 'r' ), ./maintenance/benchmarks/Benchmarker.php: php_uname( 'v' ) ./RELEASE-NOTES-1.34:* (T172060) GlobalFunctions: Use php_uname instead of posix_uname. ./vendor/pear/pear-core-minimal/src/OS/Guess.php:// php_uname() without args returns the same as 'uname -a', or a PHP-custom ./vendor/pear/pear-core-minimal/src/OS/Guess.php: * This class uses php_uname() to grok information about the current OS ./vendor/pear/pear-core-minimal/src/OS/Guess.php: $uname = php_uname(); ./vendor/symfony/console/Output/ConsoleOutput.php: \function_exists('php_uname') ? php_uname('s') : '', ./vendor/phan/phan/src/Phan/Plugin/Internal/UseReturnValuePlugin.php: 'php_uname' => true, ./vendor/phan/phan/src/Phan/Language/Internal/FunctionDocumentationMap.php:'php_uname' => 'Returns information about the operating system PHP is running on', ./vendor/phan/phan/src/Phan/Language/Internal/FunctionSignatureMap.php:'php_uname' => ['string', 'mode='=>'string'], ./vendor/phan/phan/src/Phan/Language/Internal/FunctionSignatureMapReal_php73.php:'php_uname' => '?string', ./vendor/phan/phan/src/Phan/Language/Internal/FunctionSignatureMapReal.php:'php_uname' => 'string',
On Thu, Sep 24, 2020 at 3:34 PM Jeffrey Walton noloader@gmail.com wrote:
Hi Everyone,
Our site is at https://www.cryptopp.com/wiki.
Since the Mediawiki 1.34.3 upgrade, the wiki serves each page with the following at the top:
<br /> <b>Warning</b>: php_uname() has been disabled for security reasons in <b>/var/www/html/w/includes/GlobalFunctions.php</b> on line <b>1333</b><br /> <!DOCTYPE html> <html class="client-nojs" lang="en" dir="ltr"> <head> ...
Any ideas how to fix things?
According to https://stackoverflow.com/q/47373937, the '@' can be used to suppress the warning:
function wfHostname() { // Hostname overriding global $wgOverrideHostname; if ( $wgOverrideHostname !== false ) { return $wgOverrideHostname; }
return @php_uname( 'n' ) ?: 'unknown'; }
But I am not sure that is the best approach here. It seems like there should be an alternative method for this. For example, on [systemd] startup, run a shell script that executes 'uname -n' and write the result to a file. Then, have wfHostname() read the value from the file, if present.
Can anyone confirm it's OK to add the '@' to silence the warning (rather than fixing the function)?
(And I am not sure about the other transgressions present in an installation).
Jeff
Well,
In the meanwhile I would suggest to contact your hosting provider: they should remove the php_uname() function from the disabled_functions directive.
Cheers
On September 24, 2020 10:30:01 PM GMT+02:00, Jeffrey Walton noloader@gmail.com wrote:
On Thu, Sep 24, 2020 at 3:34 PM Jeffrey Walton noloader@gmail.com wrote:
Hi Everyone,
Our site is at https://www.cryptopp.com/wiki.
Since the Mediawiki 1.34.3 upgrade, the wiki serves each page with
the
following at the top:
<br /> <b>Warning</b>: php_uname() has been disabled for security reasons
in
<b>/var/www/html/w/includes/GlobalFunctions.php</b> on line <b>1333</b><br />
<!DOCTYPE html>
<html class="client-nojs" lang="en" dir="ltr"> <head> ...
Any ideas how to fix things?
According to https://stackoverflow.com/q/47373937, the '@' can be used to suppress the warning:
function wfHostname() { // Hostname overriding global $wgOverrideHostname; if ( $wgOverrideHostname !== false ) { return $wgOverrideHostname; }
return @php_uname( 'n' ) ?: 'unknown';}
But I am not sure that is the best approach here. It seems like there should be an alternative method for this. For example, on [systemd] startup, run a shell script that executes 'uname -n' and write the result to a file. Then, have wfHostname() read the value from the file, if present.
Can anyone confirm it's OK to add the '@' to silence the warning (rather than fixing the function)?
(And I am not sure about the other transgressions present in an installation).
Jeff
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On Thu, Sep 24, 2020 at 5:17 PM Valerio Bozzolan via MediaWiki-l mediawiki-l@lists.wikimedia.org wrote:
Well,
In the meanwhile I would suggest to contact your hosting provider: they should remove the php_uname() function from the disabled_functions directive.
That's us. We run a hardened installation: https://github.com/weidai11/website/blob/master/apache-php/security.ini.
Jeff
Uhm,
I like people who harden shared hosting environments but I do not understand how restricting yourself should give you any pratical security advantage.
I'm not aware of any security concern involving php_uname(). Are you?
Having said I'm not a fan of [[security through obscurity]], but having said I love the STFU operatoe, I would suggest to just allow that function instead of patching MediaWiki with '@' there.
Cheers
On September 24, 2020 11:19:58 PM GMT+02:00, Jeffrey Walton noloader@gmail.com wrote:
On Thu, Sep 24, 2020 at 5:17 PM Valerio Bozzolan via MediaWiki-l mediawiki-l@lists.wikimedia.org wrote:
Well,
In the meanwhile I would suggest to contact your hosting provider:
they should remove the php_uname() function from the disabled_functions directive.
That's us. We run a hardened installation: https://github.com/weidai11/website/blob/master/apache-php/security.ini.
Jeff
On 25/9/20 5:34 am, Jeffrey Walton wrote:
Hi Everyone,
Our site is at https://www.cryptopp.com/wiki.
Since the Mediawiki 1.34.3 upgrade, the wiki serves each page with the following at the top:
<br /> <b>Warning</b>: php_uname() has been disabled for security reasons in <b>/var/www/html/w/includes/GlobalFunctions.php</b> on line <b>1333</b><br /> <!DOCTYPE html> <html class="client-nojs" lang="en" dir="ltr"> <head> ...
Any ideas how to fix things?
Set $wgOverrideHostname.
The calls to php_uname('s') could be replaced by PHP_OS_FAMILY. That would be a patch suitable for upstream.
On 25/9/20 8:00 am, Valerio Bozzolan via MediaWiki-l wrote:
I like people who harden shared hosting environments but I do not understand how restricting yourself should give you any pratical security advantage.
I'm not aware of any security concern involving php_uname(). Are you?
It can be used to obtain the version of the operating system being used, which could in turn be used to obtain the exact binaries being used, which makes heap overflow attacks and the like easier.
If that's the level of paranoia you're at, you should probably also disable Special:Version, which is routinely crawled and can be used to rapidly exploit vulnerable MediaWiki installations after a vulnerability is announced. In LocalSettings.php:
$wgSpecialPages['Version'] = DisabledSpecialPage::getCallback( 'Version' );
-- Tim Starling
On Thu, Sep 24, 2020 at 6:37 PM Tim Starling tstarling@wikimedia.org wrote:
On 25/9/20 5:34 am, Jeffrey Walton wrote:
Our site is at https://www.cryptopp.com/wiki.
Since the Mediawiki 1.34.3 upgrade, the wiki serves each page with the following at the top:
<br /> <b>Warning</b>: php_uname() has been disabled for security reasons in <b>/var/www/html/w/includes/GlobalFunctions.php</b> on line <b>1333</b><br /> <!DOCTYPE html> <html class="client-nojs" lang="en" dir="ltr"> <head> ...
Any ideas how to fix things?
Set $wgOverrideHostname.
Thanks. I guess that is new. We don't seem to have it in LocalSettings.php:
# grep -i name /var/www/html/w/LocalSettings.php $IP = dirname( __FILE__ ); # match the server name in httpd.conf or logon will break $wgSitename = 'Crypto++ Wiki'; ... $wgDBname = "my_wiki"; $wgLocalInterwiki = $wgSitename;
... If that's the level of paranoia you're at, you should probably also disable Special:Version, which is routinely crawled and can be used to rapidly exploit vulnerable MediaWiki installations after a vulnerability is announced. In LocalSettings.php:
$wgSpecialPages['Version'] = DisabledSpecialPage::getCallback( 'Version' );
Yeah, I've been thinking about that for some time now.
What it comes down to is, when we ask for help, you need accurate information to help us. If I remove Special:Version then you don't have the information you need. I don't want to screw you by taking that information away.
Jeff
On Thursday, September 24, 2020, Jeffrey Walton noloader@gmail.com wrote:
On Thu, Sep 24, 2020 at 6:37 PM Tim Starling tstarling@wikimedia.org wrote:
On 25/9/20 5:34 am, Jeffrey Walton wrote:
Our site is at https://www.cryptopp.com/wiki.
Since the Mediawiki 1.34.3 upgrade, the wiki serves each page with the following at the top:
<br /> <b>Warning</b>: php_uname() has been disabled for security reasons in <b>/var/www/html/w/includes/GlobalFunctions.php</b> on line <b>1333</b><br /> <!DOCTYPE html> <html class="client-nojs" lang="en" dir="ltr"> <head> ...
Any ideas how to fix things?
Set $wgOverrideHostname.
Thanks. I guess that is new. We don't seem to have it in LocalSettings.php:
[...]
It normally wouldn't be in LocalSettings.php, you would have to add it yourself. If its not present in LocalSettings.php then its default value is used.
-- Brian
On Thu, Sep 24, 2020 at 8:53 PM Brian Wolff bawolff@gmail.com wrote:
On Thursday, September 24, 2020, Jeffrey Walton noloader@gmail.com wrote:
On Thu, Sep 24, 2020 at 6:37 PM Tim Starling tstarling@wikimedia.org wrote:
On 25/9/20 5:34 am, Jeffrey Walton wrote:
Our site is at https://www.cryptopp.com/wiki.
Since the Mediawiki 1.34.3 upgrade, the wiki serves each page with the following at the top:
<br /> <b>Warning</b>: php_uname() has been disabled for security reasons in <b>/var/www/html/w/includes/GlobalFunctions.php</b> on line <b>1333</b><br /> <!DOCTYPE html> <html class="client-nojs" lang="en" dir="ltr"> <head> ...
Any ideas how to fix things?
Set $wgOverrideHostname.
Thanks. I guess that is new. We don't seem to have it in LocalSettings.php:
[...]
It normally wouldn't be in LocalSettings.php, you would have to add it yourself. If its not present in LocalSettings.php then its default value is used.
Thanks.
Out of curiosity, why is "unknown" used instead of "localhost"? localhost is a standard hostname. Are there negative side effects from using localhost?
Jeff
On 25/9/20 10:56 am, Jeffrey Walton wrote:
Thanks.
Out of curiosity, why is "unknown" used instead of "localhost"? localhost is a standard hostname. Are there negative side effects from using localhost?
It's just used for debugging, so it doesn't matter if it's a standard hostname. "Unknown" at least tells us that the host is unknown, whereas "localhost" might be misleading.
You can set $wgOverrideHostname to whatever you like, it doesn't need to be resolvable.
I don't know why it needs to be called on every request. I see that it is passed from MWLBFactory::applyDefaultConfig() to LBFactory and then LoadBalancer, but LoadBalancer just stores it in a private property and never touches it again. Maybe there was previously a log entry that used it, but it's gone now.
-- Tim Starling
mediawiki-l@lists.wikimedia.org