Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
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("<",">","(",")"); $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("<",">","(",")"); $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.
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
