Re: Drupal CKEditor 3.0 - 3.6.2 - Persistent EventHandler XSS

[InterN0T Advisories <advisories () intern0t net>]

Hello MustLive, the Administrator of Websecurity web site of the
http://websecurity.com.ua website,


The CKEditor developers, doesn't seem to have ever been aware of this
issue, and it seems like you either reported this bug to the wrong
developers, or you didn't get the point across as I often, no offense
intended, find your advisories quite confusing.
Furthermore, you didn't specify which versions of CKEditor were
vulnerable, but it is perhaps and most likely the same code enabling this
vulnerability, as it dates back to version 3.0 and up to the current
version 3.6.2
In your advisories, you describe FCKEditor/CKEditor as something that is
builtin by default in Drupal (or at least it seems so), and this bug is not
a default bug in Drupal. It is within the plugin as stated in my advisory,
this in particular not mentioned in your advisories either, unless I'm
blind: http://drupal.org/node/1332022

Just ~three days after I sent my advisory to the full disclosure mailing
list, a patch was sent to review that seems to fix the problem.

You state the following at
https://dev.ckeditor.com/ticket/8630#comment:15: "This issue is not in
CKEditor itself, but in Drupal (which must properly sanitize the input, if
only CKEditor will not have their own XSS filters). So I agree in this with
wwalc."

1) This vulnerability as I described, is not present in the default
installation of Drupal.
2) The issue is in CKEditor itself, as it affects _ALL_ versions from 3.0
to 3.6.2, even if CKEditor is not integrated into Drupal.

::: Demo time :::
- Go to: http://ckeditor.com/demo
- Click "Source"
- Paste: <img onerror="alert(0);" src="x:x" /> into the form
- Click "Source" again.

Conclusion:
- Javascript is executed. 

How can it not be a bug within CKEditor itself as well, if it works on the
demo page too?

The Drupal CKEditor plugin does store the malicious eventhandlers, but the
XSS is _STILL_ originating from CKEditor. 

If the Drupal CKEditor _PLUGIN_ developers sanitize user-input when the
POST-request is sent to e.g., add a comment, the use of malicious
eventhandlers won't be possible, but. It will _STILL_ be possible to
perform the reflected / non-persistent XSS as described in the "Demo time"
section above.

I have nothing further to add, besides that you shouldn't make the
developers of CKEditor believe, that it's not a bug within CKEditor when it
clearly is and that it should be fixed.



Best regards,
MaXe

On Sun, 22 Jan 2012 20:41:53 +0200, "MustLive"
<mustlive () websecurity com ua> wrote:
> Hello MaXe!
>
> Concerning your advisory about vulnerability in Drupal CKEditor 3.0 -
> 3.6.2 - Persistent EventHandler XSS
> (http://securityvulns.com/docs27577.html), then I'll note, that I've
wrote
> already about this vulnerability last year.
>
> As about this Persistent XSS in Drupal - SecurityVulns ID: 11748
> (http://securityvulns.com/docs26584.html and
> http://seclists.org/fulldisclosure/2011/Jun/501), as about similar
> Reflected XSS in Drupal - SecurityVulns ID: 11750
> (http://securityvulns.com/docs26588.html and
> http://seclists.org/fulldisclosure/2011/Jun/529). These XSS attacks can
be
> done as via FCKeditor/CKEditor, as via TinyMCE and any other rich
editors
> (with preview functionality).
>
> As I've mentioned in publications at my site, these vulnerabilities were
> found by me at 16.08.2010 (during security audit). After my brief
informing
> about them at 11.12.2010 and detailed informing at 13.04.2011 to Drupal
> developers, they were ignored and not fixed (so it's no wonder that
you've
> found them). I've announced these vulnerabilities at 12.04.2011 and
> 13.04.2011, and after giving enough time for developers to fix, they
were
> disclosed at 24.06.2011 and 25.06.2011.
>
> About such XSS vulnerabilities in forms with rich editors I've wrote in
> April 2011 in my article "Cross-Site Scripting vulnerabilities in forms"
(http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-October/008056.html).
> No claims to you concerning that you've found the same hole, as I've
found
> in 2010. Such things happen (and quite often people found holes, which
I've
> already found and disclosed earlier), and if you've missed these my
> findings, about which I wrote in my advisories and article, then I
reminded
> you. But, please, draw attention to above-mentioned reflected XSS attack
> via forms with rich editors in Drupal (which is similar to persistent
XSS,
> but much more forms are affected and the attack is easier to conduct,
> because the form_token is not required).
>
> Because these vulnerabilities concern Drupal itself, not only CKEditor
> (such attack can also be conducted via FCKeditor, TinyMCE and any other
> rich editors, and it's Drupal's filter fault), I've not informed
CKEditor
> developers, but only Drupal developers. So from your side, you've did
some
> job to also draw their attention to this issue (and maybe if Drupal is
> ignoring, then there will be some moving from other side to fix these
> issues, but it was better for Drupal developers to fix it).
>
> > 18th January 2012 - Developers of CKEditor has been contacted several
> > times, nothing has happened in two weeks and the advisory has been
> > available to the public via bugtrackers. Vulnerability released to the
> > general public.
>
> Taking into account, that I've disclosed this hole at 24th July 2011,
then
> it was available for the public from that time.
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/