Hello,

Is Telerik.Web.UI, v2011.1.519.40 affected by this vulnerability?

http://www.telerik.com/support/kb/aspnet-ajax/details/cryptographic-weakness?utm_medium=email#partial-patches

Thanks

Hi Brian,

Yes, it is. A patch is not available for it due to technical feasibility.

I advise that you upgrade to R2 2017 SP1 if possible. If not, upgrading to Q1 2013 is the next best option. If this is not feasible for you, you can choose the nearest version - Q2 2011 or Q1 2011 SP1.

Regards,

Hello,

Can you help me find the patch for Telerik.Web.UI.dll 2011.1.315.35?

Thanks,

Brian

Thank you Marin.

Upgraded to 2011.3.1115.40 with Security Patch applied.

BTW, IMHO, I think the wording "technical feasibility" is very vague the way it is being used.

You should instead have on the vulnerability page:

Affected Versions (complete list):

X

Y

Z

Vulernatibilty can be removed by applying a security patch .zip on top of the following versions:

A

B

C

Hi.

I cannot find the patch for Telerik.Web.UI.dll (2013.3.1114.40) that we are currently using.

How do we find it?

thanks,

Bruce

Found it:

https://www.telerik.com/account/product-download?product=RCAJAX

On this page, there is a dropdown with all the patches available listed.

Hi,

we are using DialogHandler.axd not .aspx for RadEditor. Does the vulnerability also exist in .axd or only in .aspx?

Thank you

Mark

One of our legacy applications uses Telerik.Web.UI version 2013.3.1114.45. I've located the security patch download for Version 2013.3.1114, however there is nothing contained in the Bin45 folder which is the version we require. The Bin35 and Bin40 folders both contain patched .dll files. Is the empty Bin45 folder an oversight or deliberate? Will this version be patched?

Many thanks

Our production version of Telerik.Web.UI.dll is 2011.2.915.40. We are not on active maintenance, but we do have existing licensing for the 2016 version.

The notice indicates that the vulnerability is in the ASP.Net AJAX package, but we use the ASP.NET MVC package.  Both packages contain the Telerik.Web.UI.dll library. Should we still upgrade/patch?

Thanks.

Our production version of Telerik.Web.UI.dll is 2011.2.915.40. We are not on active maintenance, but we do have existing licensing for the 2016 version.

The notice indicates that the vulnerability is in the ASP.Net AJAX package, but we use the ASP.NET MVC package.  Both packages contain the Telerik.Web.UI.dll library. Should we still upgrade/patch?

Thanks.

Hi Tim,

The UI for ASP.NET MVC suite does not contain or use Telerik.Web.UI.dll. In fact, the UI for ASP.NET AJAX controls are not supported in an MVC environment and, generally, both should not mix.

Nevertheless, if your application uses Telerik.Web.UI, you should apply the patch by following the KB: https://admin.telerik.com/www.telerik.com/support/kb/aspnet-ajax/details/cryptographic-weakness.

Regards,

Hi,

At the moment we don't have any Telerik.Web.UI.DialogParametersEncryptionKey and MachineKey entries in the web.config

Can you point me in the right direction about MachineKey and will it affect other applications/functionalities ? We have been using cryptography in the solution for other parts.

Rgds

Ole Oscar Johnsen

Hello Ole Oscar,

After applying the patch, you should set the three Telerik-specific keys (see here) and change the Machine Key.

Generally, changing the machine key has the same effect as changing anything in the web.config - it recycles the application pool and thus invalidates old sessions, webresource URLs and other generated URLs.

If you had not had it before, chances are that IIS was generating a new one for you on every application pool recycle. Of course, this depends on the overall system setup.

Regards,

You are indicating that I need three keys. Is it

<add key="Telerik.AsyncUpload.ConfigurationEncryptionKey" />

<add key="Telerik.Upload.ConfigurationHashKey"/>

  <add key="Telerik.Web.UI.DialogParametersEncryptionKey"/>

Hi Martin,

What is the reason to change the machine key ? Just to avoid the case if the server has been compromised? 

Yes, changing the machine key is just a precaution.

--Marin

Hi Marin,

We have a legacy application that is using version: 2009.3.1208.35 Telerik.Web.UI

Is the vulnerability present in this version?

Thanks,

Rick

Hi Rick,

I can confirm that version 2009.3.1208.35 uses Telerik.Web.UI.DialogHandler for RadEditor File Browser dialogs. You need to either Prevent access to the Telerik Dialog Handler, upgrade to one of the patched versions or the latest one.

Hello,

We have both a V6 and a V3.7 site, both running on same server.

We have found and applied the appropriate patch for V6 and assume all is well.

We are struggling to get the V3.7 site sorted. We have (as far as we're aware) amended the web config to remove the Dialog Handler elements, but the test URL still seems to come back error-free (which it shouldn't)

Any help gratefully received.

m.

Hello Martin,

You need to prevent access to the handler for such old versions: http://www.telerik.com/support/kb/aspnet-ajax/details/cryptographic-weakness#prevent-access.

If the handler is still available, the most likely reason would be nested web.config files where one of them still has the handlers defined.

I've just added a sample redirect rule that you can also use as base for changing the page requested to a custom page instead of the dialog handler in case you cannot find where the handler is declared. Note that you should ensure the rule you use fits your application logic and does not break something else before going live.

Regards,

Hi,

Thanks for the reply. The "kb" link is exactly where I've been looking since this issue first came to rise. Because Sitefinity (from a code-pov) is still somewhat alien to me, I have zero idea of nested web.config files. If i look at a local copy of the sites files & folder (that I downloaded as a backup/archive) I can see various config files:

"web.config(pre3.7)", "web.config.orig", "web.config", "Extensionweb.config" and "before doc extensionCopy of web.config"

I assume that the first two are defunct backups, prior to changes being made, as would be the last one. I'm struggling to remember what "doc extension" would be, but it was from 8 years ago... I'm thinking something for handling documents.

Anyway, I am assuming that both "web.config" and "Extensionweb.config" are "live" and I have edited both as per the instructions in the KB document.

You say "I've just added a sample redirect rule that you can also use as base for changing the page requested to a custom page instead..." Where have you added this?

Regards,

m.

Hello Martin,

I added the example in the KB: http://www.telerik.com/support/kb/aspnet-ajax/details/cryptographic-weakness#prevent-access. I am pasting it here for your convenience as well:

Hi,

Thanks for the further reply. I now see what you mean about where you placed it.

I have tried what you suggested (assuming I've done it right) and still no joy. It's starting to get silly.

Step one: Locally, inside the "web.config" file I added an exact duplicate of your example code inside the "handlers" of "system.webServer". I then uploaded this to the "live" server, replacing the previous "web.config" file. In case I needed to restart the Sitefinity system, I did that thing where I made a minor, non-consequential change to the "web.config" file and saved the change... But I don't think the system restarted, as browsing pages continued as normal without a pause.

Step Two: On the "live" server I copied that new redirect code and pasted into the same location within "Extensionweb.config". Again, I did a minor, non-consequential change too and saved it. Then browsing the site's front-end there was an obvious pause as the browser was waiting on the server - presumably doing the system restart.

But, when applying "/Telerik.Web.UI.DialogHandler.aspx?checkHandler=true" onto the end of my domain's URL I was once again greeted with "HandlerCheckOK" as opposed to the "not allowed" web page I was expecting (and yes, I had pre-created a new Sitefinity page that used the same URL as your example).

So I'm somewhat bamboozled.

m.