Re: [Full-disclosure] Drupal CKEditor 3.0 - 3.6.2 - Persistent EventHandler XSS
- From: InterN0T Advisories <advisories@xxxxxxxxxxxx>
- Date: Sun, 22 Jan 2012 20:47:14 -0500
Hello MustLive, the Administrator of Websecurity web site of the
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
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
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
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.
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"
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.
On Sun, 22 Jan 2012 20:41:53 +0200, "MustLive"
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
already about this vulnerability last year.be
As about this Persistent XSS in Drupal - SecurityVulns ID: 11748
http://seclists.org/fulldisclosure/2011/Jun/501), as about similar
Reflected XSS in Drupal - SecurityVulns ID: 11750
http://seclists.org/fulldisclosure/2011/Jun/529). These XSS attacks can
done as via FCKeditor/CKEditor, as via TinyMCE and any other richeditors
(with preview functionality).informing
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
about them at 11.12.2010 and detailed informing at 13.04.2011 to Drupalyou've
developers, they were ignored and not fixed (so it's no wonder that
found them). I've announced these vulnerabilities at 12.04.2011 andwere
13.04.2011, and after giving enough time for developers to fix, they
disclosed at 24.06.2011 and 25.06.2011.(http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-October/008056.html).
About such XSS vulnerabilities in forms with rich editors I've wrote in
April 2011 in my article "Cross-Site Scripting vulnerabilities in forms"
No claims to you concerning that you've found the same hole, as I've
in 2010. Such things happen (and quite often people found holes, whichI've
already found and disclosed earlier), and if you've missed these myreminded
findings, about which I wrote in my advisories and article, then I
you. But, please, draw attention to above-mentioned reflected XSS attackXSS,
via forms with rich editors in Drupal (which is similar to persistent
but much more forms are affected and the attack is easier to conduct,CKEditor
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
developers, but only Drupal developers. So from your side, you've didsome
job to also draw their attention to this issue (and maybe if Drupal isthen
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
Taking into account, that I've disclosed this hole at 24th July 2011,
it was available for the public from that time.
Best wishes & regards,
Administrator of Websecurity web site
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/
- Prev by Date: Re: [Full-disclosure] Linux Local Root -- CVE-2012-0056 -- Detailed Write-up
- Next by Date: Re: [Full-disclosure] Linux Local Root -- CVE-2012-0056 -- Detailed Write-up
- Previous by thread: Re: [Full-disclosure] Drupal CKEditor 3.0 - 3.6.2 - Persistent EventHandler XSS
- Next by thread: [Full-disclosure] Exploit Pack - New release