WordPress inadvertent disclosure bug

By | October 6, 2009

As I previously wrote, I recently had to change my password on over 300 Web sites because my default “medium-security password” was compromised.  The compromise was caused by a bug in the WordPress blogging platform which can result in inadvertent disclosure of information when content is pasted into the WYSIWYG text editor built into WordPress.

In a nutshell, sometimes when you paste text into the editor, the editor inserts an invisible copy of the pasted text.  You won’t see the invisible text at all in the editor; it’s visible in the HTML view, but WordPress users often post without every looking at the HTML view (that is, after all, the whole point of the editor).  Even if you do look at the HTML, you probably won’t notice the hidden text block unless you know to look for it, which most people obviously don’t.  It is not clear whether this invisible copy is inserted in addition to a visible copy of the same text, or whether it’s inserted instead of the visible copy you intended.

Although the text is not visible in the editor, it is in the HTML, which means that when you publish your blog entry, the hidden text goes along with it.  Search engines will happily index it and even show you snippets from it in search results if you search for a keyword that’s found in the hidden text.  Furthermore, syndicators of your blog that strip out HTML style attributes (including, e.g., the feed syndicator at LiveJournal.com) will render the previously invisible text for the world to see.

I was posting a blog entry about some idiots emailing me a Web site username and password, and I cut and pasted their email into my blog posting and then edited it to remove the username and password before publication.  Although I edited the visible text successfully, the unedited, invisible text remained and was picked up by the search engines and LiveJournal.  Voilà!  Time to change a bunch of passwords. *sigh*

This is not a terribly serious security hole, as these things go, but it is real and needs to be addressed.  Unfortunately, the maintainers of WordPress do not seem to be taking it particularly seriously.  I sent this report to security@wordpress.com:

I am running WordPress 2.8.4.

I recently posted a blog entry…

Here is what appeared, without my knowledge at the end of the unfixed version that I first published:

<div id=”_mcePaste” style=”overflow: hidden; position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px;”> … </div>

In other words, for some reason, when I pasted the email message text into the Visual editor, somehow this hidden text block got pasted, in addition to the visible text block that I then edited, and the hidden, unedited text block remained in the blog entry when it was published.

I don’t know how this happened. I don’t recall doing anything unusual that might have caused it when editing the blog entry.

The security issue here should be obvious — it is a big problem that text that someone pastes into a blog entry they are editing can end up being inserted into the published blog entry without their knowledge. In my case, the problem is particularly egregious, since usernames and passwords were involved, but any time text gets published that the author isn’t aware is being published, that’s a problem.

The text was invisible in my blog because of the style attributes, but Google indexed it anyway, which means that it could show up in Google search results if you searched for the right keyword. Not only that, but when the syndicated LiveJournal feed of my blog picked up the blog posting, the style attributes were stripped, and the text became visible on LiveJournal to everyone who reads my blog there.

When I Google for “<div id=”_mcePaste” style=”overflow: hidden; position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px;”>”, Google finds 83 matches (if you tell it to display all matches, rather than letting it filter out the ones it thinks are similar), so clearly I’m not the only person who has been bitten by this, although I haven’t looked to see if any of the other inadvertently exposed text is as security-sensitive as it was in my case. Also, if you Google for “_mcepaste hidden”, you will see that others have run into this issue, although it doesn’t look like anyone has realized the security-hole aspect of it.

I hope you will take this issue seriously.

I didn’t hear back from them for two days, so I wrote to them again.  I didn’t hear back from them for another five days after that, so I wrote to them again.  They finally responded, “Switch from the Visual to the H TML tab to see hidden blocks.  Visiaul is a WYSIWYG and seems to be doing exactly as it should… That said, we can look into putting up a little warning message if the content contains hidden text.”

I responded:

I don’t understand what you are saying.

It is not correct behavior for a WYSIWYG editor to paste hidden text into a document and not tell you that it is there.

You could make a case that it is correct behavior if (a) there were some purpose to the hidden text and (b) it happened every time. Neither of these is the case. There is no purpose to the hidden text; when the WYSIWYG editor pastes properly, the text is visible, not hidden. And it only happens rarely, thus making it rather clear that it is a malfunction rather than intended behavior.

Even if the behavior were both intended and functional, neither its existence nor its purpose is documented anywhere, nor is the user informed in any way when invisible text is pasted. Therefore, it would still be a security issue in this case, because it is making data that people publicly visible that people don’t expect to be publicly visible without informing them.

If there is a purpose to the hidden text, then what is it?

I also told them that displaying a warning message would be a good start, but not inserting hidden text into blog postings for no discernable reason would be a better solution.

I’ve heard nothing further back from them.

I am publicizing this issue both to warn other WordPress bloggers about it and to ask publicly for the WordPress development team to acknowledge that this bug is a security hole and commit to fixing it.

Share

8 thoughts on “WordPress inadvertent disclosure bug

  1. Pingback: Security in October: Google Wave, Facebook, XSS | .eduGuru

  2. Eric Howe

    If you grab the TinyMCE source and grep it for _mcePaste you’ll find it in the paste plugin. I don’t know my way around TinyMCE but it looks like it creates an id=”_mcePaste” as a holding pen for incoming pasted HTML so that it can clean it up; it looks like one _mcePaste is created on the first paste and re-used for subsequent paste; however, I don’t think TinyMCE is cleaning up after itself, it should be deleting the _mcePaste after it is done with it but I don’t see anything like that going on. Cleaning up pasted HTML makes a lot of sense, have a look at the HTML the Word tries to paste into things for some reasons; also, you have to worry about properly closing block tags if you’re pasting over a selection that crosses blocks.

    The problem looks like sloppiness in TinyMCE. However, WordPress should be scrubbing and sanity checking the HTML (WordPress does do this, right?) so it should be easy for WordPress to strip out the during the scrubbing. OTOH, TinyMCE should be doing the paste like this: create “hidden” , paste into it, mangling incoming HTML, delete “hidden” . That last step seems to be missing.

    BTW, I don’t even use WordPress or TinyMCE, I think I got here through comp.risks and started playing around to see what I could eye-ball in the code.

    Reply
  3. jik Post author

    I’m not saying this is not a security issue, but is it possible that the clipboard contents you pasted contained this style=”overflow: hidden;” stuff?

    No.

    Then again, with a name like “_mcePaste” perhaps this scenario is less likely than WYSIWYG editor creating the tag out of thin air as you presume. I dunno. (Is MCE a WordPress acronym?)

    Yes. TinyMCE is the visual editor used by WordPress. See http://tinymce.moxiecode.com/.

    Reply
  4. bitguru

    I’m not saying this is not a security issue, but is it possible that the clipboard contents you pasted contained this style=”overflow: hidden;” stuff?

    It seems possible that you pasted HTML content from your email client, and that the HTML content did contain this … tag. In cases like this should we expect the WordPress WYSIWYG editor to sanitize the paste, or to pass it through verbatim? I can see arguments for either way.

    Then again, with a name like “_mcePaste” perhaps this scenario is less likely than WYSIWYG editor creating the tag out of thin air as you presume. I dunno. (Is MCE a WordPress acronym?)

    Reply
  5. jik Post author

    @Terence Eden: The issue with this security hole isn’t that there’s hidden text in the original document being pasted and this hidden text is carried over into the blog posting being edited. Rather, the security hole is that it is possible for visible text in the document being pasted to become hidden when it is pasted, such that even if you edit or remove the text after you paste it (as I clearly intended to do, when I pasted text containing a password and then edited it to remove the password), the original text could remain hidden in your blog posting without you realizing it.

    The truly paranoid will therefore carefully review the entire HTML version of a blog entry before publishing it, if there’s any chance that private text was inadvertently posted into it in hidden form, but most people are not going to bother with this, because most people have no idea that the visual editor could have added hidden text to their blog without their knowledge or consent.

    Reply
  6. jik Post author

    Can you work out what you did to make the problem repeatable? Until it’s possible to isolate the bug, it’s very difficult to fix.

    If the folks at security@wordpress.com had agreed with me that there is a security issue and asked me to work with them to help identify it, I would have been happy to do so.

    Instead, they ignored me for a week, and then when they finally replied to my third attempt to get them to pay attention to me, they said everything was working properly and there was no security issue. They still haven’t acknowledged that there is a security issue.

    So, I hope you’ll understand when I say that I’m not exactly motivated to put myself out to help them figure out their bug.

    In any case, many people have posted about the problem on the Web, albeit not the security aspects of it, and several of them have discussed how they were able to reproduce it. I’m not convinced that they way they were able to reproduce it is the only vector for this bug, but it’s more than enough information to point the WordPress developers in the right direction and enable them to figure out the bug, should they choose to do so rather than ignoring reports about it.

    Also, most support issues should go to the WordPress › Support forums.

    This is not a support issue, it is a bug. Furthermore, it is a security bug, which is why I sent email to the private security email list rather than posting publicly about it. I posted publicly only because of the unacceptable response from the WordPress developers who are on that list.

    Reply
  7. Terence Eden

    An interesting point. Does WordPress need a “Paste Special” option.

    From my point of view, copying and pasting HTML should act on *everything* a user has selected. There’s no way of knowing if the user just wants to paste the plain text, simple formatting (bold, lists, etc) or complex (tables, hidden markup, etc).

    WordPress has no way of knowing whether the author wants the hidden markup or not. It would also be complex for it to figure out if the text would be hidden in the WYSIWYG view.

    Assuming you do think it should change – how would you design the User Interface? Do you show a pop-up every time the user pastes HTML? The first time? Have it remove all formatting unless the user checks a config box?

    It is a security flaw – no doubt about that. But it comes down to the bug/feature dichotomy.

    T

    Reply
  8. scruss

    Can you work out what you did to make the problem repeatable? Until it’s possible to isolate the bug, it’s very difficult to fix.

    Also, most support issues should go to the WordPress › Support forums.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *