This is a migrated thread and some comments may be shown as answers.

Security vulnerabilities CVE-2017-11357, CVE-2017-11317, CVE-2014-2217: safe if we don't use RadAsyncUpload control?

48 Answers 1541 Views

General Discussions

This is a migrated thread and some comments may be shown as answers.

Jordan asked on 01 Sep 2017, 06:17 PM

This morning, I received the email below about a security vulnerability in the Telerik ASP.NET UI product. Reading through, I don't think we'd be vulnerable, and therefore would not have to apply an update/patch, unless we are using the RadAsyncUpload control. Is that right?

From: Progress [mailto:progresssoftware@businessmaking.progress.net]

Sent: Friday, September 01, 2017 10:44 AM
To:
Subject: Security Alert for Progress Telerik UI for ASP.NET AJAX

Security Alert for Progress Telerik UI for ASP.NET AJAX

In our ongoing effort to provide the highest levels of quality, security and performance of your Telerik UI for ASP.NET AJAX implementation, we are writing to inform you of security vulnerabilities (CVE-2017-11357, CVE-2017-11317, CVE-2014-2217) that exist in all versions of Telerik.Web.UI.dll assembly prior to 2017.2.711.

These vulnerabilities put websites using Telerik.Web.UI.dll at risk for arbitrary file uploads to the server and/or remote code execution. We have investigated and addressed these issues, and, as we consider the vulnerability critical, we strongly recommend you follow one of the steps below for the safety and security of your websites:
For those on active maintenance, upgrade to R2 2017 SP2 (2017.2.711) or a newer version of Telerik UI for ASP.NET AJAX.
Download and promote the security patch provided in your Telerik.com account for versions between Q1 2011 (2011.1.315) and R2 2017 SP1 (2017.2.621). If you have downloaded a patch before, download it again, because the file was updated.
Depending on your use case, you may need to prevent file uploads and/or create a custom handler as explained in the KB articles below.
We urge you to read the details on the mitigation paths and the required actions in the following KB articles:
ASP.NET AJAX Insecure Direct Object Reference
ASP.NET AJAX Unrestricted File Upload
Best regards,
The Progress Team

Terms of Use | Privacy Policy
NOTICE: This is a security alert from Progress Software Corporation or its affiliates ("Progress"), headquartered at 14 Oak Park Drive, Bedford, MA 01730 USA. Please click here to manage your subscriptions or unsubscribe.
Progress, Telerik and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings. Any other trademarks contained herein are the property of their respective owners.
Copyright © 2017 Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved.

48 Answers, 1 is accepted

answered on 04 Sep 2017, 08:38 AM

Hi guys,

If you do not have custom Telerik.AsyncUpload.ConfigurationEncryptionKey and Telerik.Upload.ConfigurationHashKey keys, there could be a potential threat.

Versions prior to R1 2017 will still not use the current improved encryption, so there may still be some risk and I encourage you to download the patch so you can disable the built-in handler via the appSettings switch.

I must also note that the async upload control is used internally by other controls in the suite - some RadEditor dialogs, a specific RadGrid column type, RadFileExplorer. Thus, your application may be using it indirectly. This is the second reason why I would encourage you to download the patched dll and disable file uploads.

Regards,

Marin Bratanov
Progress Telerik

Try our brand new, jQuery-free Angular 2 components built from ground-up which deliver the business app essential building blocks - a grid component, data visualization (charts) and form elements.

answered on 04 Sep 2017, 10:29 AM

We are using Telerik and its AyncUpload control within SharePoint 2010. SharePoint 2010 does not support IE 9 and above (its settings the meta tag to be only compatible with IE8) which is the reason why we can't update to telerik > 2015.3.1111. Neither we can disable the async upload as we use it in many applications. What is the best solution for us without having to rewrite many of our applications? Ive read about writing our own upload handler but in which way is that better than using the provided one by telerik? If we write our own handler, how can we account the security measures which will be needed to not have a security issue again?

answered on 04 Sep 2017, 10:42 AM

Hi Rene,

The custom handler can be better than the built-in one, because you will have full control over its functionality - when, where and how files are written to the disk, what stays in memory and for how long, user permissions, and so on.

For example, you can create a custom handler that "knows" about the current user (e.g., shares the Session), and there you could implement one or more of the following (note that this list is not exhaustive, there are many other measures you can take):

ensure the logged in user is trusted and write uploaded files to their own folder in a secured location (e.g., a shared network drive or some form of database)
perform a virus check
ensure the Windows user that will save the files cannot write inside the web application folder and inside system folders
limit file sizes and types, employ disk quotas, or otherwise limit the potential issue created by an arbitrary file upload to the custom handler
employ any security/authentication/login measures that your application already uses (like checking with a system like ADFS whether the user is trusted and what their permissions are; or ensuring they are currently active on a page that is expected to cause file uploads)
disable chunk uploads so entire files are uploaded only, without temporary folders, so you can always know what is uploaded and employ a threat scan. Note that this can cause difficulties large file uploads due to the maximum request length.

Ultimately, the goal of a custom handler is to allow the developer to plug in the existing application security logic into the RadAsyncUpload file upload process. The exact logic and code will depend on the concrete application.

Regards,

Marin Bratanov
Progress Telerik

Try our brand new, jQuery-free Angular 2 components built from ground-up which deliver the business app essential building blocks - a grid component, data visualization (charts) and form elements.

answered on 05 Sep 2017, 02:45 PM

Thanks for your answer im still somehow confused when reading through the guidelines. As I statted we can not upgrade to a Version higher than 2015.3.1111. Does applying the patch helps to improve the security even though we do not implement our own handler & not deactivate it through the webconfig?

Its somehow confusing that in one article it says the patch is fixing the secuity issue

[quote]

versions from Q3 2012 SP1 (version number 2012.3.1205) onward, must have the Telerik.AsyncUpload.ConfigurationEncryptionKey key set to a strong random value. It improves the control settings encryption. Read more on the required keys and how to generate them in the Mandatory Additions to the web.config section of the documentation. Note that important encryption improvements were implemented in R1 2017 (2017.1.118). Thus, using a patch or upgrading to R1 2017 (2017.1.118) or later is recommended.

[/quote]

and then you post

[quote]

[/quote]

answered on 06 Sep 2017, 01:50 PM

@Rene—Yes, applying the patch improves the security and alleviates this issue. The strongest measure is disabling the built-in handler via the appSettings key - it removes the possibility that a file will be uploaded through our handler. This also the only way to completely fix this one for versions prior to R1 2017. Adding the three Telerik-specific encryption keys also helps but is not a complete solution. The R1 2017 release introduces HMAC validation for the file uploads, which is how the second issue is fixed. Having the encryption keys makes it harder for the attacker for previous versions (after Q3 2012 SP1, of course).

@Jordan—The GridAttachmentColumn uses RadAsyncUpload when editing/inserting. Also, RadFileExplorer uses RadAsyncUpload, and some RadEditor dialogs use it. I would still suggest you apply the patch and set custom encryption keys, though. If you are not using RadAsyncUpload, disable its handler as well.

Regards,
Marin

answered on 07 Sep 2017, 02:50 PM

Hi Marin,

we have more than 400 web-applications using Telerik-Controls prior to 2017.2.711 and it takes us days or even weeks to patch or update them all again. Is there any easier workaround to disable RadAsyncUpload in older versions?

I noted that file uploads with RadAsyncUpload make HTTP-POSTs to /Telerik.Web.UI.WebResource.axd. Would it work to adapt the http-handler in the web.config and change the allowed-verb from * to GET? I know it might have side-effect and some user-interaction could stop working. Is this a safe workaround for the mentioned security issues? (CVE-2017-11357, CVE-2017-11317, CVE-2014-2217)

Thanks,

answered on 07 Sep 2017, 06:31 PM

@Marin (sorry for calling you Martin before) - since we don't use any Telerik control other than RadGrid, and in the RadGrid, we don't use a GridAttachment column, shouldn't we be safe? Or is it possible for an attacker to upload directly using the handlers, even without a UI in place?

According to http://docs.telerik.com/devtools/aspnet-ajax/controls/asyncupload/security#disableasyncuploadhandler, the async upload handler cannot be disabled if you are running a version prior to R2 2017 SP2. Ours is many versions behind that, and I would like to avoid patching or upgrading if a configuration change can mitigate this vulnerability.

I took a look at our web.config file, and found these lines under <system.web> / <httpHandlers>:

I also found these under <system.webServer> / <handlers>:

If I removed all the lines related to Upload stuff, would that keep me safe?

answered on 08 Sep 2017, 03:28 PM

Hi all,

I have updated the KBs to use Daniel's idea on disabling POSTs without a patch. You can find details in either article (link1, link2).

@Jordan - the new information should also answer your question. Yes, you should take action even if you are not using RadAsyncUpload directly, especially if you are on a version prior to R2 2017 SP2. The RadUploadProgressHandler is about tracking progress only and removing its lines will not help in this case.

@Rene - You can just throw an exception in the custom handler and it can be captured in OnClientFileUpladFailed even if it will usually contain only something like "HTTP Error code is: 500". This is the status of the request the server returns, an error from an exception is usually buried in the HTML error page that is returned (the async upload expects JSON).

That aside, I devised for you a different way of doing that and you can find it here: http://www.telerik.com/support/kb/aspnet-ajax/upload-(async)/details/how-to-capture-file-upload-errors-with-custom-handler. I hope it fits your needs.

Regards,
Marin

answered on 12 Sep 2017, 07:14 AM

Hi,

You are correct, for versions prior to R1 2017 there may still be some risk if the async upload handler is not disabled. Having custom encryption keys in place reduces this risk, but cannot eliminate it entirely.

A complete list of controls using RadAsyncUpload does not exist in the current documentation, but the RadEditor dialogs, the grid attachment column and the file explorer control are what uses the async upload internally.

Generally, if you allow file uploads in your application via RadAsyncUpload, you would have added the code to do that - either explicitly add a RadAsyncUpload, or use the GridAttachmentColumn, or configure RadEditor/RadFileExplorer to allow file uploads. I must note again that you should take appropriate measures in any case, even if you are not allowing/using file uploads explicitly in your application.

Regards,

Marin Bratanov
Progress Telerik

Try our brand new, jQuery-free Angular 2 components built from ground-up which deliver the business app essential building blocks - a grid component, data visualization (charts) and form elements.

answered on 13 Sep 2017, 09:48 AM

Hi Mark,

For versions between Q3 2012 and R1 2017 (non-inclusive), the control uses only the Telerik.AsyncUpload.ConfigurationEncryptionKey to improve its encryption. While this makes the attack harder, it is not impossible. R1 2017 improves the encryption to levels that are secure at the present state of the world (as of the autumn of year 2017). R2 2017 SP2 and the patches bring a fix for another issue that does not stem from encryption.

So, the risk remains he same - arbitrary file upload. For versions prior to R1 2017 if the handler is not disabled (either by using the patch, or by using standard ASP.NET techniques), arbitrary file upload risk exists, even though the exploit is more difficult for the attacker.

I do hope this answers your question. I cannot share more specific details as we'd rather keep the exact exploit details and attack vector out of the Internet.

Regards,

Marin Bratanov
Progress Telerik

Try our brand new, jQuery-free Angular 2 components built from ground-up which deliver the business app essential building blocks - a grid component, data visualization (charts) and form elements.

answered on 19 Dec 2017, 09:53 AM

Hi Simon,

The patched dlls tackle three distinct issues:

one in the dialog handler and that is patched fully so you can keep using the dialogs: https://www.telerik.com/support/kb/aspnet-ajax/details/cryptographic-weakness.
one in the async upload that cannot be patched fully, so the patch allows you to prevent the vulnerability by disabling uploads: https://www.telerik.com/support/kb/aspnet-ajax/upload-(async)/details/unrestricted-file-upload.
another in the async upload that can be patched fully so you can keep using custom handlers: https://www.telerik.com/support/kb/aspnet-ajax/upload-(async)/details/insecure-direct-object-reference.

This earlier post in the thread also treats the same question: https://www.telerik.com/forums/security-vulnerabilities-cve-2017-11357-cve-2017-11317-cve-2014-2217-safe-if-we-don't-use-radasyncupload-control#a1EuPa0AHk6O6ALFXJaPKQ.

I hope this explains the situation.

Regards,

Marin Bratanov
Progress Telerik

Try our brand new, jQuery-free Angular components built from ground-up which deliver the business app essential building blocks - a grid component, data visualization (charts) and form elements.

answered on 19 Dec 2017, 11:19 AM

Hi Marin,

Yes, sorry about that, I realised after I posted that there were already some replies pertaining to the same thing.

So I think I have one final question...

I have written our own AsyncUploadHandler and disabled the built-in Telerik one. My upload handler does not save anything to disk, disables chunk upload and disables the permission check. It reads the bytes into memory and stores them in the application cache (with an expiration time) to then process by the page (which clears the cache anyway, even though there is an expiration time, as soon as it's processed them). We're uploading XML data (zipped or unzipped) so it all gets validated during the processing of the uploaded bytes. As I'm not sure how the vulnerability is exploited, will this be enough to secure the application, because we are not saving anything to disk, or can a file still be saved somehow?

P.S. Is there somewhere I can subscribe to get future CVE notifications for the products we use?

answered on 19 Dec 2017, 11:36 AM

Hello Simon,

I advise that you review this section of the documentation to see whether your case may still store a file/chunk to the disk: https://docs.telerik.com/devtools/aspnet-ajax/controls/asyncupload/how-to/how-to-extend-the-radasyncupload-handler#temporary-folder-usage. If you do not use the temp folder, and have disabled the built-in file upload handler, you are OK.

We are working on creating a form of a security center or other types of notifications, information will be posted when details are available.

Regards,

Marin Bratanov
Progress Telerik

Try our brand new, jQuery-free Angular components built from ground-up which deliver the business app essential building blocks - a grid component, data visualization (charts) and form elements.

answered on 19 Dec 2017, 05:47 PM

Marin

We are using an old version of Telerik.Web.UI (v 2012.2.912.35) in our application. We skipped the upgrades because we switched to using Kendo library in all our newer development. Looks like 2012.2.912.35 is one of the few versions where you do not have a patch to disable the upload handler. What is the best option for us to close this security vulnerability? Upgrading to latest 2017 release is out of question because that will be too costly for us as we have many Telerik controls in our pages.

Is there any technical reason why you are unable to provide a patch for the version we are using?

We do not use RadAsyncUpload, but use RadProgressManager & RadUploadContext class in our code. Are RadProgressManager & RadUploadContext also vulnerable to the threat?

Thank you

answered on 20 Dec 2017, 09:37 AM

Hi Matt, Satish,

Your questions are similar and I believe the following will answer both of you.

The progress handler is used for transmitting data for a process status and there are no known vulnerabilities in it, nor are there known issues in RadUploadContext.

Nevertheless, you can simply remove the Telerik.Web.UI.RadUploadProgressHandler handler from your web.config if you are worried about it, and it will not be available any more.

The RadUpload control was made obsolete in mid-2013 and was superceded by RadAsyncUpload. The RadUpload control is quite similar to the asp FileUpload - they both put the file as part of the form POST, as a regular <input type="file"/> does (that's what they are under the covers).

RadAsyncUpload adds more code on top of that and allows you to use the FileAPI or other modules that provide features like uploads towards a handler and chunk upload and this is where the difference comes from.

If you are not using RadAsyncUpload I still advise that you take one of the three approaches to disable POST requests to its handler (two of the three do not require updates to assemblies): https://www.telerik.com/support/kb/aspnet-ajax/upload-%28async%29/details/unrestricted-file-upload#prevent-post.

Regards,
Marin

answered on 21 Dec 2017, 01:15 PM

raduploadhandlererror.png

Thanks Marin for the response. Your response about RadUpload was very assuring. Followed your recommendation and I removed the RadUploadProgressHandler from web.config. After removing the handler, our uploads started failing with the error in the attached file. I believe we are also using RadAjaxmanager in those pages and because of that RadUpload was still using the handler.

Anyway we are not looking to restore the handler in the web.config file. We will be going with alternate solutions for upload. Can you please assure that once we remove the handler from web.config, retaining the Telerik.web.ui.dll file (v 2012.2.912.35) in the bin folder is not vulnerable anymore. The only issues I can think of would be some dialogs in Telerik Editor or any other control could fail when they are dependent on the handler. There will not be any security vulnerabilities. Please confirm.

answered on 21 Dec 2017, 01:40 PM

Hello Satish,

You need to ensure that the following handlers are not accessible in your application, and it will be secured from these vulnerabilities:

the async upload handler (Telerik.Web.UI.WebResource.axd?type=rau). Note that the Telerik.Web.UI.WebResource.axd handler is used by all other controls, so you must block this concrete path that contains the type=rau querystring: https://www.telerik.com/support/kb/aspnet-ajax/upload-%28async%29/details/unrestricted-file-upload#prevent-post
the dialog handler (Telerik.Web.UI.DialogHandler.aspx or Telerik.Web.UI.DialogHandler.ashx depending on how you have it registered in the web.config). You can prevent access to it just by removing them: https://www.telerik.com/support/kb/aspnet-ajax/details/cryptographic-weakness#prevent-access.

By blocking these two handlers, you will not be affected by the aforementioned vulnerabilities.

Regards,

Marin Bratanov
Progress Telerik

Try our brand new, jQuery-free Angular components built from ground-up which deliver the business app essential building blocks - a grid component, data visualization (charts) and form elements.

answered on 29 Nov 2019, 02:38 AM

Hi Team,

We follow this mitigation path and adopt option 2 in step 2. I can see the file description of Telerik.Web.UI.dll is suffixed with 'Patch'. We already have a static machine key for the site, and we directly use it as the value of 'Telerik.AsyncUpload.ConfigurationEncryptionKey' and 'Telerik.Upload.ConfigurationHashKey'. Follow the guide to disable the async handler by setting 'Telerik.Web.DisableAsyncUploadHandler = Ture'. But the uplaod via RadAsyncUpload still works. I can see it fires a HTTP post request to the default handler webresource.axd?type=rau and response 200 received. Any idea why? It is escalated as a critical issue from our customer and kindly looking forward to your assistant. Thanks.

Assembly verison: 2014.1.225.35

answered on 29 Nov 2019, 08:56 AM

Hi Team,

I think I might have found the issue. You are using the default ConfigurationManager.AppSettings. But we store the Configuration in a separate file. And we have our customized configuration provider to load these settings via ConfigurationManager.OpenMappedExeConfiguration into the 'MxConfig' defined in our code base. Then read the AppSettings from there.

That makes the patch failed to lookup the DisableAsyncHandler setting.

Could you please kindly advise what we can do.

Q1. What else we can do as a quick workaround?

Q2. Want to make sure the key has to be identical across all web instance. Cause the upload is just a one time request. is it possible if the upload will work if the web instance has a different machinekey respectively.

answered on 29 Nov 2019, 02:01 PM

Hi Antony,

To begin with a small explanation on the KB - you must also set the encryption keys, preferably different than your machine key, even if you opt to disable the handler. Generally, I will strongly advise that you upgrade to the latest version.

On the issue with a custom appSettings provider - I'm afraid nothing can be done about this, we rely on the standard ConfigurationManager as we can't do anything else. This is the case throughout our codebase, and this means that other keys there will probably not be read for other components as well, and probably the custom encryption keys are not read as well. What I can suggest you look into is encrypting the appSettings section so information from it can still be taken from the default configuration manager of .NET: https://www.telerik.com/support/kb/aspnet-ajax/details/how-to-encrypt-the-telerik-appsettings-keys. If this is not an option, the most secure approach you can take is to upgrade to the latest version.

The only other alternative I can think of for securing this app is to disable all network requests to our webresource handler. Either through a firewall, or by removing its registrations from the web.config. The idea is that IIS will not send any requests for it to the vulnerable codebase. The downside is that you will lose functionality in other places like RadScriptManager, RadStyleSheetManager, RadBinaryImage, certain cases for RadImageEditor, and maybe a few more controls.

On why keys must be in sync - RadAsyncUpload sends the file to that handler as soon as the user selects it, and these are asynchronous requests that need to carry some metadata so the server knows what to do with them. This metadata is encrypted and so the keys used in that cryptographic operation must be the same on the server the encrypted it, and on the server that needs to decrypt it in order to process the file. If they are the same machine things will work, but if one machine generated the .aspx form, and another handled the request to the async handler - that request will fail if the keys are different.

Considering this information,

Regards,
Marin Bratanov
Progress Telerik

Get quickly onboarded and successful with your Telerik and/or Kendo UI products with the Virtual Classroom free technical training, available to all active customers. Learn More.

answered on 29 Nov 2019, 03:15 PM

Hi Marin,

Thank you for your detail explanation. We do plan to upgrade to the latest version but as a long term solution.

The configuration, not just the AppSettings, a bunch of other things as well. That is the design years ago, to separate for better manageability I guess. Anyway, we have decided to add them in web.config since there is no other choice as a short term solution.

About the keys must be in sync, 'but if one machine generated the .aspx form, and another handled the request to the async handler'. Do you mean the metadata is generated/encrypted on aspx page render and decrypted when handle the request to async handler.

Product Bundles

DevCraft

Web

Mobile

Document Management

Desktop

Reporting & Mocking

Automated Testing

CMS

UI/UX Tools

Debugging

Free Tools

Support and Learning

Productivity and Design Tools

Security vulnerabilities CVE-2017-11357, CVE-2017-11317, CVE-2014-2217: safe if we don't use RadAsyncUpload control?

48 Answers, 1 is accepted