AUTHOR: Marin Bratanov
DATE POSTED: June 26, 2017
A third party organization has identified a cryptographic weakness (CVE-2017-9248) in Telerik.Web.UI.dll that can be exploited to the disclosure of encryption keys (Telerik.Web.UI.DialogParametersEncryptionKey and/or the MachineKey).
Knowledge of these keys in web applications using Telerik UI for ASP.NET AJAX components can lead to:
To ensure your application is not exposed to such a risk, there are three mitigation paths:
Use a patch for versions between Q1 2013 (2013.1.220) and R2 2017 (2017.2.503)
Use a patch for some versions between Q1 2011 (2011.1.315) and Q3 2012 SP2 (2012.3.1308)
If you are on active maintenance, upgrade to R2 2017 SP1 (2017.2.621) or later.
Prevent access to the Telerik Dialog Handler
NOTE: The patches are not available on the Telerik NuGet feed.
NOTE: If you are targeting .NET 3.5, review the FIPS Compatibility article , because the encryption issue it describes also pertains to these patches.
Download a patched version from your Telerik.com account after the 26th of June 2017:
The patched version shows "Telerik.Web.UI.Patch" in the File Description under Properties in Windows Explorer:
How to spot a patched version of Telerik.Web.UI.dll:
Source code for building a patched version and protecting the Telerik.Web.UI assembly is available after 14 Jul 2017.
If you are on active maintenance, upgrade at least to Q1 2013 (2013.1.220) and follow the same approach for Using a patch for versions between Q1 2013 (2013.1.220) and R2 2017 (2017.2.503).
Due to technical feasibility, the following versions do not have patches for this issue:
If your version lists a SecurityPatch_<your_version>.zip file, you can follow the same approach for Using a patch for versions between Q1 2013 (2013.1.220) and R2 2017 (2017.2.503).
An alternative to a fix or a patch is to prevent access to the Telerik DialogHandler. Note that this will make it impossible to use Telerik built-in dialogs for RadEditor and RadSpell.
There are different ways to do that, for example:
Add a firewall rule that rejects traffic to the handler.
Add a URL redirect rule that returns an error page instead of the handler. Note that this will merely redirect the requests to a page of your choosing, usually with a 301 status code. Here is a basic example:
Remove the handler from the web.config:
<!-- You may have either of the following lines, depending on the extension you use -->
<!-- Remove this line -->
<!-- Ensure you have this line -->
For SharePoint sites, delete the Telerik.Web.UI.SpellCheckHandler.ashx and Telerik.Web.UI.DialogHandler.aspx files that correspond to these handlers. You can find them in the following folders:
SharePoint 2010: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\wpresources\RadEditorSharePoint\6.x.x.0__1f131a624888eeed\Resources
SharePoint 2013: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\wpresources\RadEditorSharePoint\7.x.x.0__1f131a624888eeed\Resources
SharePoint 2016: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\wpresources\RadEditorSharePoint\7.x.x.0__1f131a624888eeed\Resources
You can test whether the handler is available by requesting the following URL under you application root: Telerik.Web.UI.DialogHandler.aspx?checkHandler=true
When the handler is not available, you will get an error similar to the following:
We would like to thank Erlend Leiknes, security consultant in Mnemonic AS, and Thanh Van Tien Nguyen, for responsibly disclosing this vulnerability to us and helping in its resolution.