Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: Drupal CKEditor 3.0 - 3.6.2 - Persistent EventHandler XSS
From: InterN0T Advisories <advisories () intern0t net>
Date: Sun, 22 Jan 2012 20:47:14 -0500

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/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]