WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#9185 closed feature request (wontfix)

cordon off all non-entry points from the public

Reported by: jidanni Owned by: ryan
Milestone: Priority: normal
Severity: normal Version: 2.7
Component: Security Keywords: 2nd-opinion dev-feedback
Focuses: Cc:

Description

Gentlemen, I just realized that anybody can go prancing around
the whole file tree, executing php programs left and right.
Browse your

http://example.net/blog/wp-config.php
http://example.net/blog/wp-admin/includes/
http://example.net/blog/wp-admin/includes/file.php ...
Fatal error: Call to undefined function __() in ...file.php on line 11
each file will generally produce a different error message.

We are very very lucky nothing worse happens here, allowing the public
to randomly execute internal components of wordpress that were never
intended to be executed separately, even by the administrator.

Compare this to MediaWiki. No idle executing random PHP files allowed:

$ find * -name .htaccess
includes/.htaccess
languages/.htaccess
maintenance/archives/.htaccess
maintenance/.htaccess
math/.htaccess
serialized/.htaccess
t/.htaccess
tests/.htaccess
$ find * -name .htaccess|xargs cat|sort -u
Deny from all

And for individual files, we observe

die( "This file is part of MediaWiki, it is not a valid entry point" );

Now you might say "go make your own .htaccess files or use a plugin."
However I say the onus is on the core team to identify the entry
points to be allowed, and cordon the rest off like MediaWiki does!

Change History (6)

comment:1 follow-up: DD325 years ago

  • Keywords 2nd-opinion dev-feedback added
  • Milestone changed from 2.8 to 2.9
  • Type changed from defect (bug) to feature request

Moving to 2.9 due to no patch, and is a feature request.

The worst that will ever happen is a fatal PHP error is shown, allowing a end-user to find out the path in which WordPress is installed, Many have argued in the past that this is a security issue, and allows people to easier exploit a WordPress installation, But the fact is, They'll do it one way or another anyway.

Due to the way WordPress is structured, It will always be impossible for code execution, or unintended permanent changes to be made to WordPress, The database, Files, or the server by directly accessing any non-entry point, If it was wanted, It could be set to redirect users back to the front page in the even that they do come across the page, But its not exactly a needed requirement (or urgent item).

Something such as this could be added to every page:

if ( ! defined('ABSPATH') ) {
header('Location: ../'); //Despite the fact you should only use absolute url's here..
die('Bugger off');
}

comment:2 in reply to: ↑ 1 jidanni5 years ago

Even arbitrary execution of my well intentioned
http://abj.jidanni.org/articles/wp-content/themes/jidanni/index.php
jammed an error message into a <title>

<title><br /> <b>Fatal error</b>: Call to undefined function
wp_title() in
<b>/home/jidanni/abj.jidanni.org/articles/wp-content/themes/jidanni/index.php</b>

One might imagine longer such strings ending up in <title>s etc.
crashing people browsers or overflowing stacks leading to arbitrary
code execution...

Firefox was immune but emacs-w3m fell for it.

Then of course there are poorly written 3rd party plugins, or maybe
even with backdoors using overflows and <script> etc. achieving XSS
and other things over my head, (so sorry for the FUD if I'm wrong.)

Or perhaps just a one-liner that when executed prints wp-config.php,
exposing passwords.

OK, all of this could be done by different routes, except maybe the
XSS.

Anyway, mainly I notice MediaWiki even has a includes/FakeTitle.php

* Fake title class that triggers an error if any members are called

which I don't understand, but implies that MediaWiki are serious about security...
It is some kind of double entry point protection...

comment:3 follow-up: westi5 years ago

  • Milestone changed from 2.9 to Future Release

We have been round and round this loop before.

A good php configuration for a non-development server won't show you the error messages.

If you are really worried about people accessing the files then use a .htaccess file.

comment:4 in reply to: ↑ 3 jidanni5 years ago

  • Cc jidanni@… added

Replying to westi:

If you are really worried about people accessing the files then use a .htaccess file.

MediaWiki includes them in the tarball for the user already.

comment:5 hakre5 years ago

With a full URL abstraction, reflecting both the request as well as the response, the placement of wordpress php files is on free will an configuration.

until then, feel free to configure your webserver as it pleases you. putting .htaccess files into the zip does not make much sense for servers other then apache mainly.

comment:6 Denis-de-Bernardy5 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

+1 to the general trend. and adding such .htaccess files all over could potentially prevent plugins from working when their php files would need to be called directly.

Note: See TracTickets for help on using tickets.