Bug 918054 (CVE-2013-1808) - CVE-2013-1808 stapler-adjunct-zeroclipboard: XSS via copying XSS payload into buffer
Summary: CVE-2013-1808 stapler-adjunct-zeroclipboard: XSS via copying XSS payload into...
Alias: CVE-2013-1808
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1008812 1008814
Blocks: 918058
TreeView+ depends on / blocked
Reported: 2013-03-05 11:57 UTC by Jan Lieskovsky
Modified: 2021-02-17 07:58 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-02-13 01:26:17 UTC

Attachments (Terms of Use)

Description Jan Lieskovsky 2013-03-05 11:57:33 UTC
Multiple cross-site scripting flaws were reported: 

  [1] http://seclists.org/fulldisclosure/2013/Feb/103

in ZeroClipboard, a library that provides an easy way to copy text to the clipboard using an invisible Adobe Flash movie, and a JavaScript interface. A remote attacker could provide a specially-crafted URL that, when visited by an unsuspecting ZeroClipboard user would lead to arbitrary HTML or webscript execution in the context of ZeroClipboard user's session.

Comment 2 Jan Lieskovsky 2013-03-25 09:41:42 UTC
Further issue details from MustLive (original issue reporter):
[from http://www.openwall.com/lists/oss-security/2013/03/25/1]:

Date: Sun, 24 Mar 2013 23:51:55 +0200
From: "MustLive" <mustlive@...security.com.ua>
To: <submissions@...ketstormsecurity.org>,
Subject: XSS vulnerabilities in ZeroClipboard and multiple web applications

Hello list!

In February I've wrote about Cross-Site Scripting vulnerabilities in 
ZeroClipboard and multiple web applications. This is additional information 
on this topic.

XSS vulnerabilities in ZeroClipboard
XSS vulnerabilities in YAML, Multiproject for Trac, UserCollections for 
Piwigo, TAO and TableTools for DataTables for jQuery
XSS vulnerabilities in em-shorty, RepRapCalculator, Fulcrum, Django and aCMS

SecurityVulns ID: 12910
CVE: CVE-2013-1808

During my conversation with old ZeroClipboard developer (Joseph Huckaby) and 
new developers (Jon Rohan and James Greene) last month, I've recommended 
them to prevent downloading of ZeroClipboard's files (swf and sources) from 
repository at Google code. To prevent spreading of vulnerable versions of 
software. After my second letter at 19th of February, Joseph agreed with me 
on this and gave full control for new developers to make necessary changes 
at http://code.google.com/p/zeroclipboard/. About added warnings and 
disallowing of downloads Joseph informed me and later James confirm it too.

But it was not sufficient enough, since I found that it was possible to 
download files directly from repository (and there are many web sites which 
are referencing on these files). So I've suggested Jon and James to 
completely prevent downloading of all vulnerable files from old repository. 
After my letters from 3rd, 16th and 24th of March, they at last did it and 
made complete closure of old repository.

XSS vulnerabilities in zClip and other web applications.

In addition to all those web applications, which I've wrote earlier and 
hundreds of webapps on which I've referenced via google dorks, there are 
tens or hundreds additional vulnerable web applications with ZeroClipboard. 
These are such webapps, which have no swf of ZeroClipboard in their bundles, 
but referencing on it at their sites or in documentation. I have found many 
webapps with such approach (for different flash-files, like all those flash 
video players, about vulnerabilities in which I wrote) for last years and 
wrote about such case. E.g. in 2010 I've wrote about Blogumus - a WP-Cumulus 
fork for Blogger, where there was swf-file at the site, from which users can 
download last version or embed it from that site (like from CDN).

There are such web developers, like developers of zClip and many other web 
applications, which are not bundling vulnerable swf of ZeroClipboard, but 
they referencing to it in old repository and asking all users to manually 
download last version of swf-file from repository (i.e. last vulnerable 
version). I've wrote to zClip developers about it at 6th of March, but they 
just ignored it. So to protect all future users of zClip and any other 
similar software, which are referencing to old repository at Google Code 
(with vulnerable versions of ZeroClipboard), and to force a fix to all such 
software, it was needed to close old repository completely. And today 
ZeroClipboard developers have done it.

XSS (WASC-08):

For zClip the path will be the next. XSS via id parameter and XSS via 
copying payload into clipboard (as described in my first advisory).


All versions of zClip are referencing to vulnerable versions of 
ZeroClipboard. So all current users of zClip (including developer of zClip 
at their site) are using vulnerable swf-files and have XSS vulnerabilities 
at their sites. But since today all future users of zClip are protected. 
After I've forced developers of ZeroClipboard, it will prevent spreading of 
vulnerable versions of swf-files and will protect future users of all 
software (like zClip) from downloading vulnerable versions of ZeroClipboard. 
>From now all web developers and users need to download ZeroClipboard only 
from new repository (https://github.com/jonrohan/ZeroClipboard). Everyone 
who is using old versions of ZeroClipboard or software, which are bundled 
with old versions of it, needs to update to the last version 1.1.7 from new 

Best wishes & regards,
Administrator of Websecurity web site

Comment 7 Vincent Danen 2013-05-02 21:16:34 UTC
This issue affects and has been fixed in jenkins.

External references:


Comment 11 David Jorm 2014-02-13 01:21:00 UTC
This issue has been addressed in following products:

  Red Hat OpenShift Enterprise 1.2

Via RHEA-2013:1032 https://rhn.redhat.com/errata/RHEA-2013-1032.html

Note You need to log in before you can comment on or make changes to this bug.