Topic on Project:Support desk

Hi! Here's my Special:Version info

Product 	Version
MediaWiki 	1.15.1
PHP 	5.2.14 (cgi-fcgi)
MySQL 	5.1.39-log

On my MediaWiki (http://pj.freefaculty.org/cgi-bin/mw), everything works fine, except, I started to get 404 errors, but only when I entered some magic character string. I was writing about Linux file permissions and I pasted in some text output from a Linux terminal and after submitting that to the wiki, either by preview or save, the error message says:

Not Found
The requested URL /cgi-bin/mw/index.php was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

I went back to the edit window and gradually cut out material until I found the thing causing the problem. This one line in the text of my wiki message causes that 404 error.

drwxr-xr-x 112 root     root          112 Nov 18 17:21 ..

I've come here to test your wiki, and that line does not cause the 404 crash. So I'm quite stumped and have to ask for your help. If I put a blank space anywhere between the first 5 characters, there is no trouble. For example, this is OK

d rwxr-xr-x 112 root     root          112 Nov 18 17:21 ..

I'm baffled. I wish you could help me.

Here's an even worse part. Once a Wiki page is saved with that destructive string, then the page cannot be opened or edited, so it can never be fixed or deleted.

Paul Johnson <pauljohn at ku dot edu> Center for Research Methods and Data Analysis

I've cut out my password info here, but other than that, this is the LocalSettings.php file.

$ cat LocalSettings.php
<?php

# This file was automatically generated by the MediaWiki installer.
# If you make manual changes, please keep track in case you need to
# recreate them later.
#
# See includes/DefaultSettings.php for all configurable settings
# and their default values, but don't forget to make changes in _this_
# file, not there.
#
# Further documentation for configuration settings may be found at:
# http://www.mediawiki.org/wiki/Manual:Configuration_settings

# If you customize your file layout, set $IP to the directory that contains
# the other MediaWiki files. It will be used as a base to locate files.
if( defined( 'MW_INSTALL_PATH' ) ) {
        $IP = MW_INSTALL_PATH;
} else {
        $IP = dirname( __FILE__ );
}

$path = array( $IP, "$IP/includes", "$IP/languages" );
set_include_path( implode( PATH_SEPARATOR, $path ) . PATH_SEPARATOR . get_include_path() );

require_once( "$IP/includes/DefaultSettings.php" );

# If PHP's memory limit is very low, some operations may fail.
# ini_set( 'memory_limit', '20M' );

if ( $wgCommandLineMode ) {
        if ( isset( $_SERVER ) && array_key_exists( 'REQUEST_METHOD', $_SERVER ) ) {
                die( "This script must be run from the command line\n" );
        }
}
## Uncomment this to disable output compression
# $wgDisableOutputCompression = true;

$wgSitename         = "PJMediaWiki";

## The URL base path to the directory containing the wiki;
## defaults for all runtime URL paths are based off of this.
## For more information on customizing the URLs please see:
## http://www.mediawiki.org/wiki/Manual:Short_URL
$wgScriptPath       = "/cgi-bin/mw";
$wgScriptExtension  = ".php";

$wgFileExtensions = array( 'png','gif','svg','jpg','pdf' );

## UPO means: this is also a user preference option

$wgEnableEmail      = true;
$wgEnableUserEmail  = false; # UPO

$wgEmergencyContact = "pauljohn32@freefaculty.org";
$wgPasswordSender = "pauljohn32@freefaculty.org";

$wgEnotifUserTalk = false; # UPO
$wgEnotifWatchlist = false; # UPO
$wgEmailAuthentication = true;

## Database settings
$wgDBtype           = "mysql";
$wgDBserver         = "wiki.pj.freefaculty.org";

# MySQL specific settings
$wgDBprefix         = "wiki_";

# MySQL table options to use during installation or update
$wgDBTableOptions   = "ENGINE=InnoDB, DEFAULT CHARSET=binary";

# Experimental charset support for MySQL 4.1/5.0.
$wgDBmysql5 = true;

## Shared memory settings
$wgMainCacheType = CACHE_NONE;
$wgMemCachedServers = array();

## To enable image uploads, make sure the 'images' directory
## is writable, then set this to true:
$wgEnableUploads       = true;
$wgUseImageMagick = true;
$wgImageMagickConvertCommand = "/usr/bin/convert";

## If you use ImageMagick (or any other shell command) on a
## Linux server, this will need to be set to the name of an
## available UTF-8 locale
$wgShellLocale = "en_US.utf8";

## If you want to use image uploads under safe mode,
## create the directories images/archive, images/thumb and
## images/temp, and make them all writable. Then uncomment
## this, if it's not already uncommented:
# $wgHashedUploadDirectory = false;

## If you have the appropriate support software installed
## you can enable inline LaTeX equations:
$wgUseTeX           = false;

$wgLocalInterwiki   = strtolower( $wgSitename );

$wgLanguageCode = "en";

$wgSecretKey = "9b5be89ae9788a7d9136b5a829713bc7abb7549e60374bb84a02467177483c10";

## Default skin: you can change the default skin. Use the internal symbolic
## names, ie 'standard', 'nostalgia', 'cologneblue', 'monobook':
$wgDefaultSkin = 'cologneblue';

## For attaching licensing metadata to pages, and displaying an
## appropriate copyright notice / icon. GNU Free Documentation
## License and Creative Commons licenses are supported so far.
$wgEnableCreativeCommonsRdf = true;
$wgRightsPage = ""; # Set to the title of a wiki page that describes your license/copyright
$wgRightsUrl = "http://www.gnu.org/copyleft/fdl.html";
$wgRightsText = "GNU Free Documentation License 1.3";
$wgRightsIcon = "${wgScriptPath}/skins/common/images/gnu-fdl.png";
# $wgRightsCode = "gfdl1_3"; # Not yet used

$wgDiff3 = "/usr/bin/diff3";

# When you make changes to this configuration file, this will make
# sure that cached pages are cleared.
$wgCacheEpoch = max( $wgCacheEpoch, gmdate( 'YmdHis', @filemtime( __FILE__ ) ) );

$wgGroupPermissions['*']['createaccount'] = false;

# Disable for everyone.
$wgGroupPermissions['*']['edit']              = false;
# Disable for users, too: by default 'user' is allowed to edit, even if '*' is not.
#$wgGroupPermissions['user']['edit']           = false;
# Make it so users with confirmed e-mail addresses are in the group.
#$wgAutopromote['emailconfirmed'] = APCOND_EMAILCONFIRMED;
# Hide group from user list.
#$wgImplicitGroups = array( 'emailconfirmed' );
# Finally, set it to true for the desired group.
#$wgGroupPermissions['emailconfirmed']['edit'] = true;

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['sysop']['edit'] = true;


##Creates "Trusted" group
$wgGroupPermissions['Trusted'] = $wgGroupPermissions['user'];
$wgGroupPermissions['user'   ]['edit']          = false;
$wgGroupPermissions['Trusted']['edit']          = true;
$wgGroupPermissions['sysop'  ]['edit']          = true;


$wgUseTwoButtonsSearchForm = false;

##$wgUseTex = true;
$wgAllowCopyUploads = true;
$wgGroupPermissions['*']['edit'] = false;

Thats one of the more weird issues I've ever heard of.

I think its just the phrase "drwxr" appearing in the output causing this. I think it might be your webserver, because http://pj.freefaculty.org/cgi-bin/mw/api.php?action=help&requestid=drwxr causes the issue, which doesn't really invoke much of mediawiki at all. You might want to try putting just a plain html document containing "drwxr" (and perhaps a plain php document outputting just that) to try and see if its a web server or php issue.

You are on the money. It has to be something wrong on dreamhost.

I put up an html file with only the magic characters:

http://pj.freefaculty.org/testbadfile.html

$ cat testbadfile.html
<html>
<body>
drwxr
</body>
</html>

And guess what? When you browse http://pj.freefaculty.org/testbadfile.html

Not Found
The requested URL /testbadfile.html was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

I will see about reporting this to the server administrators.

Thanks for the idea.

I got to the bottom of this issue on Dreamhost.com. They are running the 'Apache "mod_security" module. The module scans incoming and outgoing documents to detect/block web attacks. It guards against is a trojan horse attack through which the user tries to retrieve information about a file system.

If

1. "drwxr" or
2. "uid" or
3. "gid" appear in a page...

...even a static page, then mod_security will block that display for fear somebody has tried to snoop into the system.

I have been asking if there is a way to create a special exception to this policy for a particular web page, but have not found a way. It is easy to exempt a particular IP client from mod_security, but not so easy to customize the particular phrases for which it scans. If this were convenient or easy to fix, I expect we would see more on how to do it. As it is, I see only frightening comments which indicate that customizing mod_security is even more difficult than customizing mod_rewrite, and even then, I'd have to be root to get around the problem.

And here's the worst part of the whole thing. The mod_security system intentionally gives back a vague/misleading error message in order to prevent the attacker from knowing that mod_security has thwarted them. All in all, this makes it almost impossible to be a "part time" web page writer.

My effort to write a little note about the meaning of "ls -la" on Linux has cost me about 12 hours of exploration.

That seems like a rather stupid security system...

As a hack, you could add an invisible unicode character between the drwxrwx so the filter doesn't get triggered.

For example drwx‌rwx (Which looks identical: drwx‌rwx) probably will work .

Cheers.

I could not upload an image named tracert.gif. This was a screenshot of output of the tracert command. After renaming it to trace-rt.gif, everything was OK. This makes me think that O.S. commands and reserved words are forbidden. This might prevent certain types of attacks on the wiki.

This post was posted by NeilBauers, but signed as Nbauers.

Ask your hosts's support about their mod_security settings. While some stuff like prohibition on certain file names can be understandable (although stupid), some "smart" hosts prohibit people to post the word "select" to the wiki (or forum). Which is kinda like a preventative murder to save someone from being killed by criminals.

Thanks. The problem has another twist. The file upload succeed but now I can't access the file to use it or delete it. I think I can work out how to get rid of it with ftp and MySQL table access. To err is human. To really foul things up, you need a computer.

This post was posted by NeilBauers, but signed as Nbauers.

See also:

• (RESOLVED) index file exception on save

here are a lot more articles on this issue

100% mod_sec was the problem. Once namecheap removed the mod_sec my wiki works great. Here is youtube video of the problem: https://www.youtube.com/watch?v=82MvQXQgfHo

I get this 404 error when I add this: [http://is.gd/namecheapmod namecheap] This is my solution: namcheap http://is.gd/namecheapmod