I want to inform you about multiple vulnerabilities in jPlayer. These are Cross-Site Scripting and Content Spoofing vulnerabilities used by tens of thousands of web sites and in multiple web applications.
-------------------------
Affected products:
-------------------------
Vulnerable are versions before jPlayer 2.2.23. Version 2.2.23 and the last released version 2.3.0 are not vulnerable to mentioned XSS, except CS via JS and XSS via JS callbacks. Also there are other bypass methods which work in version 2.3.0, but the developers haven't fixed them besides attack via alert. About that I've wrote to developers already in March and reminded again. So wait for new version with fixing of these vulnerabilities.
-------------------------
Affected vendors:
-------------------------
Happyworm
http://www.jplayer.org
----------
Details:
----------
Cross-Site Scripting (WASC-08):
In different versions of jPlayer there are different XSS vulnerabilities.
0.2.1 - 1.2.0:
http:/site/Jplayer.swf?id=%22))}catch(e){}if(!self.a)self.a=!alert(document.cookie)//
2.0.0:
http:/site/Jplayer.swf?id=%27))}catch(e){}if(!self.a)self.a=!alert(document.cookie)//
2.1.0:
http:/site/Jplayer.swf?jQuery=)}catch(e){}if(!self.a)self.a=!alert(document.cookie)//
http:/site/Jplayer.swf?id=%27))}catch(e){}if(!self.a)self.a=!alert(document.cookie)//
In version 2.2.0 these XSS vulnerabilities were fixed (the developers was informed about hole in jQuery parameter and made a fix, which protected from both attacks). But Malte Batram (in version 2.2.19) and I (in version 2.2.20) have found new ones.
2.2.0 - 2.2.19 (and previous versions):
Attack works in Firefox (all versions and browsers on Gecko engine), IE6 and Opera 10.62.
http:/site/Jplayer.swf?jQuery=document.write&id=%3Cimg%20src=1%20onerror=alertu0028document.cookieu0029%3E
2.2.20 - 2.2.22 (and previous versions):
http:/site/Jplayer.swf?jQuery=alert&id=XSS
Content Spoofing (WASC-12):
It's possible to conduct CS (inclusion of audio/video files from external resources) via JS and XSS via JS callbacks. This requires HTML Injection vulnerability at the site. The attack is similar to XSS attacks via callbacks in JW Player (http://securityvulns.ru/docs28176.html).
Because this attack vector requires separate vulnerability at target site to conduct CS and XSS attacks with using of jPlayer, the developers didn't do anything to fix it. The same as developers JW Player. So protection from this attack scenario lies solely on web sites owners.
------------
Timeline:
------------ 2013.01.31 - found vulnerabilities in jPlayer at multiple web sites (in version 2.1.0).
2013.03.14 - announced at my site.
2013.03.19 - informed developers.
2013.03.19-30 - discussed with developers different vulnerabilities in different versions of jPlayer and at their sites. 2013.03.21 - developers was informed by Malte Batram's about XSS hole in 2.2.19. 2013.03.21 - developers fixed Malte's XSS hole in 2.2.20 in github (CVE-2013-1942).
2013.03.22 - informed developers about new hole, which works in 2.2.20.
2013.03.23 - sent details of new XSS and warned about possibility for other XSS attacks and gave recommendations about proper fixing of XSS to prevent any future XSS.
2013.03.30 - reminded developers about last hole.
2013.04.12 - developers fixed my XSS hole in 2.2.23 in github.
2013.04.20 - developers released jPlayer 2.3.0 (http://www.jplayer.org/2.3.0/release-notes/) and informed me. 2013.04.20 - disclosed at my site about jPlayer (http://websecurity.com.ua/6379/). 2013.04.21 - tested version 2.3.0 and found that developers fixed only one attack vector and didn't make complete fix, as I recommended in March, so I reminded them and sent them examples of two new XSS.
Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua
//The information contained within this publication is
//supplied "as-is"with no warranties or guarantees of fitness
//of use or otherwise. Bot24, Inc nor Bradley Sean Susser accepts
//responsibility for any damage caused by the use or misuse of
//this information