Mailing List Archive

php_uname() has been disabled for security reasons...
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',

_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Re: php_uname() has been disabled for security reasons... [ In reply to ]
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
Re: php_uname() has been disabled for security reasons... [ In reply to ]
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

--
E-mail sent from the "K-9 mail" app from F-Droid, installed in my LineageOS device without proprietary Google apps. I'm delivering through my Postfix mailserver installed in a Debian GNU/Linux.

Have fun with software freedom!

[[User:Valerio Bozzolan]]

_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Re: php_uname() has been disabled for security reasons... [ In reply to ]
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

_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Re: php_uname() has been disabled for security reasons... [ In reply to ]
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

--
E-mail sent from the "K-9 mail" app from F-Droid, installed in my LineageOS device without proprietary Google apps. I'm delivering through my Postfix mailserver installed in a Debian GNU/Linux.

Have fun with software freedom!

[[User:Valerio Bozzolan]]

_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Re: php_uname() has been disabled for security reasons... [ In reply to ]
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



_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Re: php_uname() has been disabled for security reasons... [ In reply to ]
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

_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Re: php_uname() has been disabled for security reasons... [ In reply to ]
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
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Re: php_uname() has been disabled for security reasons... [ In reply to ]
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

_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Re: php_uname() has been disabled for security reasons... [ In reply to ]
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 mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l