All versions of the popular UI for ASP.NET AJAX RadEditor Control product by Telerik may be affected by a high-risk stored attribute-based cross-site scripting (XSS) vulnerability that is assigned CVE-2014-4958 by MITRE, NVD, by OSVDB as ID 112083, and covered in the news. This WYSIWYG rich text editor is “…what Microsoft chose to use in MSDN, CodePlex, TechNet, MCMS and even as an alternative to the default editor in SharePoint.”
Personally tested and confirmed are versions: 2014.1.403.35 (much newer) and 2009.3.1208.20 (much older) using Internet Explorer 8, version 8.0.7601.17514. However, all versions from Telerik at this time may be vulnerable and will continue to be until a patched is released. A workaround may be available.
What makes this discovery interesting are two parts:
Let’s now look at the example payload as it needs to be submitted to the server from a proxy such as PortSwigger’s Burp Suite for this to work. Ensure that you place this payload somewhere within the parameter value used for the editor window’s contents:
%253cdiv STYLE=”background-image: expression(alert(‘XSS’))”%253e%253c%2fdiv%253e
<div STYLE=”background-image: expression(alert(‘XSS’))”></div>
At the time of discovery the only available XSS protection on the server side was to use the RemoveScripts filter to strip out script tags, which is why attribute-based XSS is necessary here.
Carte blanche output encoding will not fix this issue, but instead may actually break the HTML that is rendered in the WYSIWYG editor window if the wrong encoding type is chosen. Troy Hunt explains the nuance of validating rich text input best by pointing out that markup is being stored in the data layer. Both data and HTML need to be handled by the same input vector here and so looking for script tags is irrelevant in this case because this problem is not that simple. Encoding everything would ensure that user input is displayed only as data and not executed as code by the web browser. However in this case some of the user-supplied content of the rich text editor needs to execute to achieve formatted text.
Previous guidance on the general issue of XSS in the Telerik forums quietly placed the responsibility of sanitization on developers, but this is likely overlooked in most implementations. Further, the obscure nature of attribute-based XSS leveraging an HTML attribute to achieve execution instead of using the popular script tag route makes this harder to filter against. HTML sanitization involves inspection at a deeper level. Read more about HTML escaping.
Remediation: Telerik states: We have applied a patch to the editor that will be delivered with our Q3 edition of the controls that should be released towards the end of October. A blog post on the issue has been published here.
Additional credit goes to Tyler Hoyle and the rest of my team in CGI Federal’s Emerging Technologies Security Practice for their hard work. This is the original Bugtraq announcement.
Questions? Email me today: main at gsmcnamara dot com.
— Threatpost (@threatpost) September 29, 2014
Researcher details nasty XSS flaw in popular web editor http://t.co/IApXxIorYO
— The Register (@TheRegister) October 1, 2014