Ready to get started?Download WordPress

Make WordPress Core

Tagged: security Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 4:52 pm on June 21, 2013 Permalink
    Tags: security, swfupload   

    Announcing a secure SWFUpload fork 

    The WordPress security team has officially forked the long-abandoned SWFUpload project and is strongly encouraging all web developers who use SWFUpload to update.

    We strongly suggest you do not use SWFUpload. But if you must, use this fork. You can find it on GitHub at github.com/wordpress/secure-swfupload.

    WordPress does not use SWFUpload, but we continue to include it in WordPress core for plugins that have yet to be updated to use Plupload, our upload library of choice. Plupload is written and actively maintained by Moxiecode, the developers of TinyMCE.

    We do not condone the use of abandonware. We only wish to make the web a better place by ensuring that developers have access to a secure version of SWFUpload, when the only alternative may be to use insecure code.

    This is a fork of SWFUpload and includes cross-site scripting fixes that have been reported by Szymon Gruszecki (CVE-2013-2205 and CVE-2012-2399), and Neal Poole and Nathan Partlan (CVE-2012-3414). It also includes fixes from Yelp’s engineering team for CVE-2012-2399.

    WordPress 3.5.2, released moments ago, includes fixes for CVE-2013-2205 and CVE-2012-2399. WordPress 3.3.2 (2012-04-20) included a fix for CVE-2012-3414 and an incomplete fix for CVE-2012-2399.

    If you think you have found a vulnerability in this fork of SWFUpload, we appreciate your help in disclosing it to us responsibly. Please email reports of security vulnerabilities to swfupload-security AT wordpress.org. These reports will be reviewed by the WordPress security team and by security researchers contributing to this project, including Neal and Szymon.

  • Andrew Nacin 8:00 pm on December 31, 2010 Permalink
    Tags: security   

    The published exploit for WordPress 3.0.4 isn’t accurate 

    We were informed yesterday of a published vulnerability for WordPress 3.0.4, “Stored XSS (via Editor role)”.

    This is an invalid report. (Edit: The exploit has been delisted by the database.)

    The dead giveaway was the title: “via Editor role.” In WordPress, users with the role of Editor or Administrator have the ability to post unfiltered HTML. It has always been like this.

    From the Security FAQ on the Codex:

    Users with Administrator or Editor privileges are allowed to publish unfiltered HTML in post titles and content. WordPress is, after all, a publishing tool, and people need to be able to include whatever markup they need to communicate. Users with lesser privileges are not allowed to post unfiltered content.

    We also issue a warning for security researchers, which wasn’t followed here:

    If you are running security tests against WordPress, use a lesser privileged user so that all content is filtered.

    How to change this behavior

    In multisite, only super administrators can publish unfiltered HTML. All other users are considered untrusted in this case, as they can be administrators for their own sites. (There is a plugin to restore unfiltered HTML to editors and regular administrators in this case, if you trust those users: Unfiltered MU.)

    There’s a constant you can use to disallow unfiltered HTML for everyone, including administrators and super administrators. To disallow unfiltered HTML for all users, you can add this to wp-config.php:

    define( 'DISALLOW_UNFILTERED_HTML', true );

    Filtered HTML for Editors

    To deny unfiltered HTML for Editors, try the Filtered HTML for Editors plugin, which I put together today. The description and FAQ go into much of what was covered here.

    How to report security vulnerabilities

    Standard practice when finding a security vulnerability is to privately notify the vendor and give them an opportunity to respond and prepare a fix for public release. It’s the concept of responsible disclosure. We’ll always credit responsible disclosure in the release announcement as the person requests, such as with a link to your blog.

    For WordPress, suspected vulnerabilities can be privately emailed to our security team at security@wordpress.org.

    Unfortunately, not everyone follows responsible disclosure. In the case of 3.0.4, an exploit published regarding 3.0.3 forced our hand to release the fix we had been privately testing (thanks to responsible disclosure). This can sometimes force our hand in very bad ways — the fixes included in 3.0.4 were very complicated and involved more than a hundred hours of work from more than a dozen individuals. Had we rushed a release due to a public announcement, we might have missed something.

    Not following responsible disclosure also prevents us from responding to invalid reports. Unfiltered HTML results in false reports every so often. The fact that this was published as an exploit, without any confirmation or notification, only contributes to FUD and perception issues.

    The status of WordPress 3.0.4

    This all said, there are currently no known vulnerabilities for WordPress 3.0.4. I’ll go knock on wood now.

    • Andrew Nacin 9:48 pm on December 31, 2010 Permalink | Log in to Reply

      The report is being removed from the exploit DB. I’ve updated the post.

    • Travis Miller 4:15 pm on January 3, 2011 Permalink | Log in to Reply

      Hi Andrew -

      Thanks for the update. I’ve been trying to research this security patch, and a few things still aren’t clear.

      1. Do I need to upgrade my 3.x sites to 3.0.4, or not? This post seems to be saying that the vulnerability that 3.0.4 supposedly fixes did not exist in the first place. Am I understanding that correctly?

      2. If there *is* a vulnerability, does it exist in the 2.x branch as well, or only 3.x?

      3. If the vulnerability does exist in 2.x, is there an official or quasi-official patch for that branch, or am I stuck doing a major version upgrade from 2.x to 3.x?

      Sorry if this isn’t the best venue for this question – comments are closed on the post on the main WordPress blog, so I can’t ask there. I’m sure others in the WordPress community would appreciate some clarification on these questions.

      • Jane Wells 4:31 pm on January 3, 2011 Permalink | Log in to Reply

        Hi Travis. I think you misunderstood Andrew’s post. After 3.0.4 came out, a website started reporting that there was a new vulnerability. That is the one that is invalid. Yes, you should update to 3.0.4. The 2.x versions are no longer supported, so please please update to the most current version. If you are still running 2.x versions, you are likely facing multiple vulnerabilities.

    • Travis Miller 6:58 pm on January 3, 2011 Permalink | Log in to Reply

      Thanks, Jane. You’re correct; I misunderstood the post. Thanks for the info.

  • Mark Jaquith 4:54 pm on May 18, 2009 Permalink
    Tags: , , esc_url, esc_url_raw, security   

    Deprecated clean_url() in favor of esc_url(), and deprecated sanitize_url() in favor of esc_url_raw().

  • Mark Jaquith 3:13 pm on May 18, 2009 Permalink
    Tags: , , esc_attr, esc_html, security   

    Deprecated wp_specialchars() in favor of esc_html() (also: esc_html__() and esc_html_e()). Using wp_specialchars() with more than one param works for backwards compat. Also, esc_html() (or wp_specialchars() with one param) escapes quotes, just like esc_attr(). This buys security for plugin authors who were mistakenly using a one-param wp_specialchars() call in an HTML attribute. See this wp-hackers message for more detail.

  • Mark Jaquith 9:16 pm on May 5, 2009 Permalink
    Tags: , , security   

    Standardizing and shortening the WP security escaping functions.

    attribute_escape() is now esc_attr()

    Additionally, you can do attribute escaping and translation in one go. Just add the translation function to the end. Like so:

    • esc_attr__() — translate and return, attribute-escaped.
    • esc_attr_e() — translate and echo, attribute-escaped.

    Will be following up with esc_html (with __() and _e() variants), esc_url(), maybe some more. Will be nice, short, predictable, and allow you do translate/escape in one go without a lot of nested parenthesis.

    • Viper007Bond 5:04 am on May 6, 2009 Permalink | Log in to Reply

      An esc_js() or whatnot might be useful to (i.e. an improved js_escape() (see #7648).

      • Mark Jaquith 5:58 am on May 6, 2009 Permalink | Log in to Reply

        Yes, I meant to include that in the list of “coming soon” ones. Though js_escape() would continue to work, as would attribute_escape() and wp_specialchars().

        Improvements to esc_js() née js_escape() are a separate issue — I’ll take a look at that ticket.

    • Leandro Vieira Pinho 3:11 am on May 9, 2009 Permalink | Log in to Reply

      Why not escape_attr than esc_attr?. Write escape is more intuitive than esc.

  • Ryan Boren 10:45 pm on September 4, 2008 Permalink
    Tags: security   

    The auth cookies are now HTTPonly in trunk.

  • Ryan Boren 7:28 pm on April 24, 2008 Permalink
    Tags: security   

    Need a secret key for your wp-config.php? Get one here

    • douglsmith 12:55 am on April 25, 2008 Permalink | Log in to Reply

      FYI, the some of the keys being generated include a single quote character, which closes the string prematurely, thus causing an error if used. I saw the same issue while helping people upgrade to WordPress 2.5 when using https://www.grc.com/passwords.htm to generate a key as suggested in the wp-config.php comments.

    • Robert Wetzlmayr 7:28 pm on April 25, 2008 Permalink | Log in to Reply

      So well, this turns out quite complicated, doesn’t it?

      Here’ my take on an automagical generation tool for a grain a salt adding to WordPress’s security pleasure: Enjoy!

    • Jacob Santos 9:17 pm on April 30, 2008 Permalink | Log in to Reply

      How about actually putting it in the core of WordPress?

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc