wp-login.php - Cannot modify header information

[cashbox0815]

AFFECTED PRODUCTS:

---

WordPress 4.1.1 and prior

DETAILS:

---

The WordPress Login Controller is prone to a full path disclosure vulnerability concerning the strpos() php function which allow attackers to
gather the real path of the server side script.

The strpos() PHP function takes strings as parameters
and will raise warnings when values that are passed are arrays rather
then strings. To get the path of the current script, you simply need to pass the
arguments as arrays rather then expected strings
and then simply read the warning message generated by PHP to see the
error including the full path of the current running script.

PROOF OF CONCEPT:

---

​http://pathtoyourwordpress.tld/wp-login.php?redirect_to[]=http%3A%2F%2Fwww.secalert.net%2Fwp-admin%2F&reauth=1

Output:
Warning: strpos() expects parameter 1 to be string, array given in /var/www/clients/0815/websites/www/wp-login.php on line 849

Warning: Cannot modify header information - headers already sent by (output started at var/www/clients/0815/websites/www/wp-login.php:849) in var/www/clients/0815/websites/www/wp-includes/pluggable.php on line 940

WRONG SOLUTION:

---

I would NOT recommend to just react by "security through obscurity" and
turn off the error messages, error reporting etc.
This is not a solution because there are a lot of users that are having
a shared hosting server where they aren't able to manipulate
the "php.ini" configuration file - even ini_set() is forbidden on some
shared hoster servers.
So they still would have the full path disclosure there which is something that the web application should catch if quality is important.

WORKAROUND:

---

I would recommend to meticulously go through the code forcing PHP to
cast the data to the desired type, in this case the (string) casts
to eliminate the Notice or Warning messages.

[nacin]

Hi cashbox0815, there is no way for us to hide every full-path disclosure that could be triggered by WordPress or a theme or a plugin (short of a auto prepend file) without resorting the rule that display_errors must never be enabled on a production site.

IMO, file paths are guessable 99% of the time anyway and leaking them doesn't really matter. Regardless: display_errors must never be enabled on a production site.

If we leak a path even with display_errors turned off (this has happened before, such as in an error message), then we'll gladly fix it.

Thank you for your report. Please email security@… next time (as the new ticket form requests in multiple places, including a checkbox you had to click).