Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 

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

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 ?

Confirmed with 1.5_beta1.

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

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.

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?

Apparently discussion has ceased upstream without a fix. 

web-apps please advise.

I'm testing this out now and seeing how functional things are without the
templates.php file, will keep you all apprised.

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.

Stable on ppc.

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

sparc stable.

Ready for GLSA vote

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
;)

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.

I agree someone with magic commit rights please mask.

Masked accordingly:

# Elfyn McBratney <beu@gentoo.org> (27 Apr 2005)
# Security mask, see bug #88926.
www-apps/wordpress

Thx Elfyn.

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?

It references this bug and comment #18 is a fine description.

Everything should be fixed in the new 1.5.1 version.

The script issue seems to be solved, the iframe issue is not.

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/
=============================================================

*** Bug 93355 has been marked as a duplicate of this bug. ***

Back in main scope for discussion

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? 

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 ~.

I think 1.5.1.1 can be unmasked. webapps please bump if you agree.

ka0ttic said I could go ahead and bump.

Bumped to 1.5.1.2
Keyworded for all arches
removed from package.mask

sorry guys... thought this was web-apps bug and not a security bug.  Reopening.

Thx SuperLag :)
Security: please vote on GLSA need, taking the masking history into account...

Marking stable for x86 and amd64.  They both work here.

PPC and Sparc teams, please mark stable.

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 ;-)

I tend to vote YES, hopefully this will bode well for future releases. 

I vote YES too...

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

Stable on SPARC.

Stable on ppc.

This is ready for GLSA decision. 1

This is ready for GLSA decision. 1½ YES and ½ NO so far. Please cast your 
vote. 

I think we should release a GLSA for this bug and bug #94512 when fixed. 

Ready for GLSA together with bug 94512

GLSA 200506-04 

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