WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#8814 closed defect (bug) (fixed)

Bad use of $_REQUEST variable in wordpress

Reported by: firstbit Owned by: ryan
Milestone: 2.8 Priority: normal
Severity: normal Version: 2.8
Component: Security Keywords: has-patch tested commit dev-feedback
Focuses: Cc:

Description

As reported in CVE-2008-5113 (1) wordpress has many security issues related to the bad use of $_REQUEST variable. Most of them ar related to the possibility to overwrite $_POST and $_GET values with a simple cookie.

I uploaded a package with a working workaround in Debian but the problem still exists and has not been solved. I think the only way to get rid of the bug is to use $_POST, $_GET and $_COOKIES instead of merging them in a single array.

Thank you very much for your help and work.

Regards.

Andrea De Iacovo

(1) http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5113

Attachments (2)

8814.diff (979 bytes) - added by Denis-de-Bernardy 5 years ago.
8814.2.diff (545 bytes) - added by ryan 5 years ago.

Download all attachments as: .zip

Change History (19)

comment:1 jacobsantos5 years ago

There was already a discussion about this a year ago with no results. So I mean, good luck.

I also don't think it is as big of a problem as you seem to make it out to be. WordPress uses nonces, so it is unlikely that deletions could occur. WordPress also does sanitizations, so it is unlikely that a XSS attack will occur.

comment:2 wet5 years ago

I did an experiment where I provoked something I'd roughly dub "denial of service".

Steps to reproduce:

Expected: Creation of post titled 'bar baz'.

Result: Creation of post titled 'foo bar'.

This error persists as long the cookie is set.

comment:3 DD325 years ago

  • Keywords needs-patch dev-feedback added
  • Priority changed from high to normal
  • Version set to 2.8

See also: http://www.suspekt.org/2008/10/01/php-53-and-delayed-cross-site-request-forgerieshijacking/

I'd nearly suggest something similar to {wp_unregister_GLOBALS() which only populatd it with GET/POST/SERVER data.. and ignored cookie data.. just for the simplicity which $_REQUEST brings, In quite a lot of places the reason $_REQUEST is used is because the data could come from either GET or POST, and we'd end up with things such as:

$action = isset($_GET['action']) ? $_GET['action'] : (isset($_POST['action']) ? $_POST['action'] : '');

which is ok, but.. it gets a bit tedious, and is near impossible to use in-line.. I know if i was to suggest that there'd be a whole lot of negitive to that i'm sure :)

comment:5 firstbit5 years ago

Also the creation of blog entries with unwanted title seems a grave bug to me. However, please, refer to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504771 for further information.

As for now I patched the Debian package by introducing a workaround but I think a system-wide solution (like gps() in the comment above) would be better.

Thank you very much for your help.

Regards.

Andrea De Iacovo

comment:6 Denis-de-Bernardy5 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

comment:7 Denis-de-Bernardy5 years ago

I can spot a lines in the code where _REQUEST[auth_cookie] gets used for whatever reason. I take it that it's to make WP based authentication work with _ENV variables on wordpress.org.

at any rate, the attached patch needs some testing, as I might have missed areas in the code base where a REQUEST variable might be in a cookie.

comment:8 follow-up: wet5 years ago

I'm wondering what's this snippet supposed to accomplish:

+        if ( ini_get('variables_order', 'EGPS') )
+                return;

comment:9 in reply to: ↑ 8 ; follow-up: Denis-de-Bernardy5 years ago

Replying to wet:

I'm wondering what's this snippet supposed to accomplish:

+        if ( ini_get('variables_order', 'EGPS') )
+                return;

if the variables_order is set to EGPS, then we're good already -- cookies are not passed into the REQUEST variable.

comment:10 in reply to: ↑ 9 wet5 years ago

Replying to Denis-de-Bernardy:

This is what I suspected. But why would you omit the actual comparison with the current value, like so:

+        if ( ini_get('variables_order') === 'EGPS' )
+                return;

Denis-de-Bernardy5 years ago

comment:12 Denis-de-Bernardy5 years ago

  • Keywords tested added; needs-testing removed

@wet: because the code just exactly that... behave as if variables_order was EGPS.

comment:13 Denis-de-Bernardy5 years ago

  • Keywords commit added

ryan5 years ago

comment:14 ryan5 years ago

I see a lot of setups that define both variables_order and gpc_order, and they don't match. We'd have to check both, I think.

Attached patch keeps it simple and puts only GET and POST in REQUEST.

comment:15 Denis-de-Bernardy5 years ago

+1 to simpler fix, personally. it might have some side effects when WP is integrated with 3rd party scripts (a forum script, etc.) that might rely on the $_REQUEST variable to contain $_SERVER variables. but better that that leaving this ticket remain open for 2 years.

comment:16 ryan5 years ago

So many hosts are set to GPC, that relying on SERVER in REQUEST is already likely to be broken.

comment:17 ryan5 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [11268]) Set REQUEST to contain GET + POST. No cookies. fixes #8814

Note: See TracTickets for help on using tickets.