You can comment out the redirect part in RawPage.php, about 2/3 down.
DO NOT COMMENT THAT OUT! It's a workaround for an IE security flaw, for which we made a security fix release in late September.
Brion Vibber--
I believe you, though I'm not sure how that could be a real security threat since it's only data that the client already has anyway. However, just because I don't understand doesn't mean I will decline your good advice.
The workaround is to require that a 'raw' access be made from a canonical script URL, ... I did this with a redirect (instead of simply a 403 rejection) to preserve existing links.
Perhaps I could modify the testing lines of my copy of the script to ignore, specifically, the cmw/ addition. This should not prevent the security check from keeping it's promise to ward off invalid requests.
No, that's an URL rewrite which passes the new URL (eg /cmw/index.php) internally to the final request.
Ah, my experience was with IIS, but this is installed under Apache. So I misinterpreted the role of .htaccess in that capacity.
If you want to map the physical path directly, normally you'd use a DocumentRoot directive in the virtual host configuration.
I'm afraid that with my hosting provider (as with 99% of potential hosting providers for MediaWiki's installation base) do not give httpd.conf access, they merely allow .htaccess files to be uploaded. Do you have a suggestion (here and for posterity) of an .htaccess change that will satisfy the strict requirements of your security hole patch while allowing administrators to use subdomains? Neither DocumentRoot nor Alias seems to be quite the right thing for mere .htaccess useage.
Unfortunately this breaks wikis where edit/diff etc urls are supposed to be short and tidy. There the browser gets stuck in an endless redirection loop. It's not too hard to fix this though, will change it in the next days.
That sounds like the penultimate solution. Will you issue it as a straightf orward "change this line to that" patch, or should I grab a diff/merge tool to install a whole new package when you issue 1.3.9a?
Meanwhile, I will contact my host provider and the user group there to see if there's an .htaccess solution so that we don't have to make unneccesary changes to the codebase.
Thanks for your ongoing attention and problem solving skills, --N. Buzdor
On Jan 12, 2005, at 1:09 PM, N. M. Buzdor wrote:
You can comment out the redirect part in RawPage.php, about 2/3 down.
DO NOT COMMENT THAT OUT! It's a workaround for an IE security flaw, for which we made a security fix release in late September.
I believe you, though I'm not sure how that could be a real security threat since it's only data that the client already has anyway.
That data can be sent somewhere _else_, since the browser is now under the control of a potentially malicious third party who can produce arbitrary JavaScript code which is executed in the context of your wiki's web site.
As I already mentioned, login credentials can be sent to a malicious server for later use, and/or the script could directly execute actions on the wiki with the user's permissions (potentially a sysop account which can delete pages, protect or unprotect pages, ban or unban accounts, and more).
If someone can trick a user into to visiting that page (potentially via a hidden frame or a redirect), the vulnerability allows that someone to effectively act as that user on the wiki.
Further, if the vulnerable browser is also vulnerable to other more serious attacks (buffer overflows, the Java applet security leak vulnerability, perhaps some ActiveX control attacks) the malicious attacker might be able to gain control of the user's local computer account and for instance install spyware, gain access to their passwords, read their e-mail, etc.
The workaround is to require that a 'raw' access be made from a canonical script URL, ... I did this with a redirect (instead of simply a 403 rejection) to preserve existing links.
Perhaps I could modify the testing lines of my copy of the script to ignore, specifically, the cmw/ addition. This should not prevent the security check from keeping it's promise to ward off invalid requests.
Maybe. See if you can find a way to get the exact given URL in a way that doesn't open it up to other security holes and works consistently across different web servers and PHP server APIs.
-- brion vibber (brion @ pobox.com)
mediawiki-l@lists.wikimedia.org