Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 88926 - www-apps/wordpress XSS, HTML and SQL injection
Summary: www-apps/wordpress XSS, HTML and SQL injection
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: High minor (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B4 [glsa] jaervosz
Keywords:
: 93355 (view as bug list)
Depends on: 94512
Blocks:
  Show dependency tree
 
Reported: 2005-04-12 23:17 UTC by Sune Kloppenborg Jeppesen (RETIRED)
Modified: 2006-05-18 17:18 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-12 23:17:43 UTC
Reported on BT. No link as I can't reach SecurityFocus atm:

============================================================
Title: WordPress XSS and HTML injection
Vulnerability discovery: SoulBlack - Security Research -
http://soulblack.com.ar
Date: 12/04/2005
Severity: Medium. users can obtain cookies of other users and defacement website
Affected version: <= 1.5
============================================================

============================================================
*Summary
http://wordpress.org. Wordpress is a popular blogging system built on
PHP (the scripting language) and is licensed under the GPL. It is free
software supported by a large and vibrant community of users. You can
use WordPress as a stand-alone application to publish your web log, or
incorporate its functionality into an existing site.

============================================================
*Problem Description:
Bug is in the content and 
Comment 1 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-12 23:17:43 UTC
Reported on BT. No link as I can't reach SecurityFocus atm:

============================================================
Title: WordPress XSS and HTML injection
Vulnerability discovery: SoulBlack - Security Research -
http://soulblack.com.ar
Date: 12/04/2005
Severity: Medium. users can obtain cookies of other users and defacement website
Affected version: <= 1.5
============================================================

============================================================
*Summary
http://wordpress.org. Wordpress is a popular blogging system built on
PHP (the scripting language) and is licensed under the GPL. It is free
software supported by a large and vibrant community of users. You can
use WordPress as a stand-alone application to publish your web log, or
incorporate its functionality into an existing site.

============================================================
*Problem Description:
Bug is in the content and  title of post, when not controlling the
entrance of  characters, being able to inject HTML code

============================================================
*Example:
Type in the title or content of post

  <script>alert(document.cookie)</script>

  <iframe src=http://othersite/sb.php>

============================================================
*Fix:
  wordpress\wp-includes\template-functions-post.php

function get_the_title($id = 0) {
        .
        .
        .
        return $title;
}

replace for by function

function get_the_title($id = 0) {
        .
        .
        .
        $sb_convert = $output;
        $sb_input =  array("<",">","(",")");
        $sb_output = array("&lt;","&gt;","&#40;","&#41;");
        $output = str_replace($sb_input, $sb_output, $sb_convert);
        return $title;
}


function get_the_content($more_link_text = '(more...)', $stripteaser =
0, $more_file = '') {
        .
        .
        .
        return $output;
}

replace for by function

function get_the_content($more_link_text = '(more...)', $stripteaser =
0, $more_file = '') {
        .
        .
        .
        $sb_convert = $output;
        $sb_input =  array("<",">","(",")");
        $sb_output = array("&lt;","&gt;","&#40;","&#41;");
        $output = str_replace($sb_input, $sb_output, $sb_convert);
        return $output;
}

============================================================
-- 
 SoulBlack - Security Research
 http://www.soulblack.com.ar
Comment 2 Thierry Carrez (RETIRED) gentoo-dev 2005-04-13 08:11:29 UTC
Discussion @
http://wordpress.org/support/topic.php?id=30721

Apparently the authors can't reproduce the problem. Any Wordpress user wants to help reproducing it ?
Comment 3 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-13 08:56:06 UTC
Confirmed with 1.5_beta1.
Comment 4 Peter Westwood 2005-04-13 11:16:43 UTC
Comments from upstream:
http://textdrive.com/pipermail/wp-hackers/2005-April/000530.html

Quote:
Eli Sarver wrote:
> Has this been addressed?
> 
> http://soulblack.com.ar/repo/papers/wordpress_advisory.txt

This is someone looking for recognition by trying to identify a 
non-issue as a problem. WordPress is highly secure by default. Should 
you be worried about this? Not if you haven't been worried by the past 5 
years of blogging software or any other CMS in the world.

That said, I think a default feature restricting users lower than level 
8 to a known subset of HTML would be useful, and will be including a 
future release. A while back Mark Ghosh created the giant array that 
KSES needs to accomplish this, I'm sure he (or I) still have it somewhere.

-- 
Matt Mullenweg
Comment 5 Thierry Carrez (RETIRED) gentoo-dev 2005-04-13 11:27:54 UTC
I'm a bit concerned wbout that comment:

=============
> Owner logs on, sees a new draft, clicks on it to view, and has just lost 
> his weblog.

That's pretty extreme. One person would have to invest a lot of time and 
technical knowledge to execute that kind of exploit for very little (one 
blog) payoff.

Additionally, if they do contain control (however they manage it, JS 
XMLhttprequest *might* work) then what? They log in, post a bunch of 
crap, hijack the blog for 20 minutes? Big deal. You should have backups, 
and they don't actually have any passwords (they only have md5'd 
cookies). So the recovery, sure, would be a pain, but would be quick. 
Combine that with the minimal likely hood of this happening and I don't 
think this comes close to anything critical.
==============

What he says basically is that you don't need security if you aren't the USAF or the NASA, and if you get hacked, so what, you've backups...

Let's wait a little and see if something comes out of this discussion.
Comment 6 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-15 23:05:45 UTC
Upstream still discussing what to do. Though the included file editor does not appear too smart security wise. Perhaps we should not install templates.php in the future?
Comment 7 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-17 22:36:59 UTC
Apparently discussion has ceased upstream without a fix. 

web-apps please advise.
Comment 8 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-04-20 09:31:09 UTC
I'm testing this out now and seeing how functional things are without the templates.php file, will keep you all apprised.
Comment 9 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-04-20 10:59:32 UTC
wp-admin/templates.php is removed by the ebuild and installs a dummy templates.php that die()'s informing the user of the reason and references this bug for more information.

Tested and marked stable on x86.  Arches, please test and mark stable.
Comment 10 Michael Hanselmann (hansmi) (RETIRED) gentoo-dev 2005-04-20 12:02:34 UTC
Stable on ppc.
Comment 11 Peter Westwood 2005-04-20 14:39:13 UTC
Bug 82295  which was about including 1.5 noted that upgrade path from 1.2.2->1.5 is not simple.

Also current ebuild in cvs doesn't mark enough files as user configurable for multiple installs - e.g. anything in plugins and themes folders under wp-content for starters
Comment 12 Gustavo Zacarias (RETIRED) gentoo-dev 2005-04-26 18:37:52 UTC
sparc stable.
Comment 13 Thierry Carrez (RETIRED) gentoo-dev 2005-04-27 00:36:21 UTC
Ready for GLSA vote
Comment 14 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-04-27 00:58:13 UTC
Sorry to chime in on this so late (been having webapp-config and upstream issues), but this needs a new revision as disabling templates.php is not enough.  I've worked on a bump, but it's getting hard as upstream is not helping me at all.

I will continue and bump wordpress again, however I would like to request that, before I do so, security@ seriously consider serurity masking www-apps/wordpress.  Upstream clearly doesn't regard security very highly, and quite frankly, upstream have been a nightmare with this and other security issues - extracting blood from an ant comes to mind.

Again, apologies for being late on this one.  Being stretched very thing here ;)
Comment 15 Thierry Carrez (RETIRED) gentoo-dev 2005-04-27 01:04:11 UTC
I don't want to waste more time on wordpress... I propose we mask it until upstream cares about security enough to patch those things.
Comment 16 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-27 07:34:58 UTC
I agree someone with magic commit rights please mask.
Comment 17 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-04-27 07:51:09 UTC
Masked accordingly:

# Elfyn McBratney <beu@gentoo.org> (27 Apr 2005)
# Security mask, see bug #88926.
www-apps/wordpress
Comment 18 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-27 08:16:03 UTC
Thx Elfyn.
Comment 19 Aaron McCaleb 2005-05-03 09:44:46 UTC
Perhaps a bit more information should be included in the mask?  As I understand it, this only affects sites with multiple authors that have posting access.  Those with only one author, or with only a core group of authors who are fully trusted shouldn't have need to fear this potential vulnerability.  

I agree that it should probably still be masked to protect the unwary, but perhaps the comment in /usr/portage/profiles/package.mask should direct users in the two cases I mentioned to feel free to unmask the file in /etc/portage/package.unmask?
Comment 20 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-03 13:43:33 UTC
It references this bug and comment #18 is a fine description.
Comment 21 Marcel van den Bosch 2005-05-10 06:33:26 UTC
Everything should be fixed in the new 1.5.1 version.
Comment 22 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-10 08:29:20 UTC
The script issue seems to be solved, the iframe issue is not.
Comment 23 Thierry Carrez (RETIRED) gentoo-dev 2005-05-21 02:17:18 UTC
Apparently there also is SQL injection...

==============================================================
From: 	  bugtraq@morph3us.org
	Subject: 	[BuHa Security] Wordpress SQL-Injection
	Date: 	May 19, 2005 11:52:58 PM EDT
	To: 	  bugtraq@securityfocus.com



 ---------------------------------------------------
| BuHa Security-Advisory #1     |    May 17th, 2005 |
 ---------------------------------------------------
| Vendor   | Wordpress                              |
| URL      | http://wordpress.org/                  |
| Version  | <= Wordpress 1.5                       |
| Risk     | Moderate (SQL-Injection)               |
 ---------------------------------------------------

o Description:
=============

WordPress is a state-of-the-art semantic personal publishing platform
with a focus on aesthetics, web standards, and usability. 

Visit http://wordpress.org/ for detailed information.

o SQL-Injection:
===============

The most critical vulnerability in the 1.5 release of wordpress is an
SQL-Injection in `wp-trackback.php'. It's not easily exploitable
because you do not get a result when you inject a valid query but it's
possible to bruteforce values in the tables - for example the password
hashes.

Here some details:
The parameter `tb_id' in `wp-trackback.php' is not validated correctly
and there are no quotes in the SQL-query so an attacker is able to 
insert sql commands.

$pingstatus = $wpdb->get_var("SELECT ping_status FROM $wpdb->posts
WHERE ID = $tb_id");
	
Example: (I converted the POST-request into a GET-request.)

$tb_id = 1 union select user_pass,0 from wp_users
$url = bla
$title = bla

</wp-trackback.php?tb_id=1%20union%20select%200,user_pass%20from%20
wp_users&url=bla&title=bla>

By injecting this query I get following databae error:

WordPress database error:
[The used SELECT statements have a different number of columns]
SELECT ping_status FROM wp_posts WHERE ID = 1 union select 0, 
user_pass from wp_users

When I insert "1 union select user_pass from wp_users" as value for
`tb_id' I get no error message because the query was well-formed -
logical. Through the possibility to insert any sql-command it's
possible to 'reconstruct' values of the tables.

o XSS:
=====

</wp-admin/edit.php?s=[XSS]&submit=Search>
</wp-admin/post.php?action=confirmdeletecomment&comment=1&p=[XSS]>

o Path Disclosure:
=================

</wordpress-1.5-strayhorn/wp-content/themes/*>
</wordpress-1.5-strayhorn/wp-includes/*>
</wordpress-1.5-strayhorn/wp-admin/*>

Fatal error: Call to undefined function add_filter() in
[...]/htdocs/testenv/blogs/wordpress/wordpress-1.5-strayhorn/
wp-content/themes/classic/comments-popup.php on line 3

o Disclosure Timeline:
=====================

17 Apr 05 - Security flaws discovered.
19 Apr 05 - Vendor contacted.
10 May 05 - Vendor released bugfixed version.
17 May 05 - Public release.

o Solution:
==========

Upgrade to wordpress 1.5.1 [1]

o Credits:
=========

Thomas Waldegger <bugtraq@morph3us.org>
BuHa-Security Community - http://buha.info/board/

[1] http://wordpress.org/development/2005/05/one-five-one/
=============================================================
Comment 24 Thierry Carrez (RETIRED) gentoo-dev 2005-05-21 02:18:04 UTC
*** Bug 93355 has been marked as a duplicate of this bug. ***
Comment 25 Thierry Carrez (RETIRED) gentoo-dev 2005-05-21 02:18:48 UTC
Back in main scope for discussion
Comment 26 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-22 22:37:23 UTC
Release note for 1.5.1.1 does not mention a fix of the iframe issue. 
 
http://wordpress.org/development/2005/05/one-five-one/ 
 
Is the iframe issue also relevant for comments or only posts? 
Comment 27 Aaron Kulbe (RETIRED) gentoo-dev 2005-05-24 11:57:55 UTC
Potential issues with PHP were having display_errors turned on in php.ini, which
goes against the advice of the PHP developers for use in a production
environment.  It would allow security info to be displayed that was unnecessary.

Also, iframe is only an issue if the blog admin gives a new user the rights to
publish and said user goes berserk and starts doing malicious things.  If the
admin keeps things locked down, this isn't an issue at all.  This can happen on
ANY platform if permissions are too loose.

There *have* been security issues found with users being able to reset admin
passwords, and the password would go back to the original ownser.  This issue
has been fixed in 1.5.1.1

Perhaps adding some einfo text is warranted, mentioning to users that they
should take care who they give privileges too, but this is common sense.

In my opinion, it should be bumped to 1.5.1.1 ASAP, and this can be removed from
package.mask and moved to ~.
Comment 28 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-25 06:48:26 UTC
I think 1.5.1.1 can be unmasked. webapps please bump if you agree.
Comment 29 Aaron Kulbe (RETIRED) gentoo-dev 2005-05-27 08:01:01 UTC
ka0ttic said I could go ahead and bump.

Bumped to 1.5.1.2
Keyworded for all arches
removed from package.mask
Comment 30 Aaron Kulbe (RETIRED) gentoo-dev 2005-05-27 08:09:14 UTC
sorry guys... thought this was web-apps bug and not a security bug.  Reopening.
Comment 31 Thierry Carrez (RETIRED) gentoo-dev 2005-05-27 08:21:05 UTC
Thx SuperLag :)
Security: please vote on GLSA need, taking the masking history into account...
Comment 32 Aaron Kulbe (RETIRED) gentoo-dev 2005-05-27 08:36:04 UTC
Marking stable for x86 and amd64.  They both work here.

PPC and Sparc teams, please mark stable.
Comment 33 Matthias Geerdsen (RETIRED) gentoo-dev 2005-05-27 08:57:03 UTC
Since this package has been masked before, I slightly tend to vote no. Since
it's just too hot in here atm to think... just count it as 0.5 votes against a
GLSA ;-)
Comment 34 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-27 10:20:33 UTC
I tend to vote YES, hopefully this will bode well for future releases. 
Comment 35 Thierry Carrez (RETIRED) gentoo-dev 2005-05-27 13:41:48 UTC
I vote YES too...
Comment 36 Thierry Carrez (RETIRED) gentoo-dev 2005-05-27 13:46:48 UTC
superlag: apparently it's not been unmasked.

sparc, ppc: wordpress was marked stable before masking, please test 1.5.1.2 and
mark stable if possible
Comment 37 Jason Wever (RETIRED) gentoo-dev 2005-05-27 15:17:52 UTC
Stable on SPARC.
Comment 38 Michael Hanselmann (hansmi) (RETIRED) gentoo-dev 2005-05-28 12:57:05 UTC
Stable on ppc.
Comment 39 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-28 23:18:02 UTC
This is ready for GLSA decision. 1
Comment 40 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-28 23:18:02 UTC
This is ready for GLSA decision. 1½ YES and ½ NO so far. Please cast your 
vote. 
Comment 41 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-30 08:36:17 UTC
I think we should release a GLSA for this bug and bug #94512 when fixed. 
Comment 42 Thierry Carrez (RETIRED) gentoo-dev 2005-06-01 00:49:14 UTC
Ready for GLSA together with bug 94512
Comment 43 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-06-06 13:53:14 UTC
GLSA 200506-04 
Comment 44 Ruben Jenster 2005-11-30 15:58:34 UTC
Does the vulnerability still exist on version 1.5.2? 
Ebuild still replaces template.php with the dummy template. 
 
http://forums.gentoo.org/viewtopic-p-2919254.html#2919254