As announced last week, we advise you to update your Umbraco sites for a security patch. You should update to ClientDependency version 1.9.7 now. More details in our blog post:
Umbraco HQ monitors this thread and will provide answers where possible.
If you're logged in to Our Umbraco you have a "Follow" button at the top right of this thread which will send you email updates of new replies to this topic.
Just as an FYI: the new Umbraco versions we're pushing out now contain nothing at all new, only the updated CDF version so that people who do fresh installs are safe by default.
Hey Sebastiaan, just to confirm - if I were to download Umbraco now which of these will be patched? i.e. only the most recent 7.12.2 version or are we going back further than that? Thanks!
Hi, I have an Umbraco 7.3.8 website where Umbraco does not work (white screen) after replacing the ClientDependency.Core.dll file (Console gives SyntaxError in a JS file). I have cleared the caches in App_Data and have checked the dll is for the correct .NET version. If I restore the old version, everything works fine again. Any ideas how to fix this?
Yes that works! On our test environment it was working, and when I changed debug to false in the web.config it stopped working. However, we would rather not have our production site running under debug mode. How do we best tackle this?
Hmm, the site does not seem to be running NuPickers.. The issue might be another old package if I understand your link correctly. I have applied the 'enableJsMinify=false' workaround from that thread for the moment while I work on patching our other sites, will research this further on later today..
In this case it was caused by an old version of the MultiUrlPicker (https://our.umbraco.com/packages/backoffice-extensions/multi-url-picker/) which had a syntax error in its JS (no ; after "use strict"), which causes ClientDependency to trip. Updating to the latest 1.x version worked for us.
No, it is relevant to all .NET versions, this is just so that we could build a version compatible with .NET 3.5 which some people still use on their Umbraco v4 installs.
what is the easiest way to verify that you've installed the correct patch?
I've installed the 4.5-patch on a website that is not 4.5 (it's a pretty old 4.x-website), but it doesn't give me any errors, YSOD's or anything like that.
After that I copied in (for testing purposes) the 4.0 dll and later even the 3.5 dll. But I never see any error pages or errors in the console... So how can I verify that I picked the correct one?
FYI: Umbraco releases 7.10.5, 7.11.2 and 7.12.3 are now available for download and the only change from 7.10.4, 7.11.1 and 7.12.2 is that the version of CDF has been updated.
7.12.3 is now the recommended release for starting new projects with.
Your application pool has a .NET version and that is the minimum version you should put in your site, if there's no ysod with a higher version then you're good to go. Usually MS doesn't make breaking changines in minor released so should be fine.
"The vulnerability is exploitable by any unauthenticated user
requesting resources from your public website, a vulnerability of type
“Local File Inclusion”. The resources that can be requested includes
configuration files and other sensitive internal files not intended
for public access."
Could this potentially be any configuration file, including the web.config?
I'm just trying to gage how potentially serious this could be so as to know what resources to allocate (we host a lot of Umbraco sites, so this will be a big job for us).
Sorry, that was a bit cheeky, but yes this includes the web.config file and you should be worried about other files in predictable paths that an attacker could know about (also files in the config folder for example).
Thanks, Seb :) I know it might seem dumb, but I was just trying to see if there was a distinction between Umbraco specific config files (ie. /config/ ) and any .config file in the web root.
We want to deploy the security patch on all of our websites, without opening them in Visual Studio (we want to do that later).
How can I tell on a deployed website which version on .NET it uses? I can see which version of Umbraco it uses in the web.config. Where can I find the .NET version?
I know of targetframeworkversion in csproj, but that file is not present. Thanks
Hi,
We've done the patch to our sites okay but are having a problem updating our local development instances via Nuget. It appears CDF 1.9.7 is not compatible with ClientDependency-Mvc5 1.8.0 (which we use) and I can't seem to select a lower version of ClientDependency-Mvc5 to around this impass. Here's the Nuget error:
Update-Package : Unable to resolve dependencies. 'ClientDependency 1.9.7' is not compatible with 'ClientDependency-Mvc5 1.8.0 constraint: ClientDependency
(>= 1.8.0)', 'UmbracoCms.Core 7.12.3 constraint: ClientDependency (>= 1.9.7 && < 2.0.0)'.
At line:1 char:1
+ Update-Package ClientDependency -Version 1.9.7
Sorry, its all good. Ensure you delete your files from /App_Data/Temp/ClientDependency folder before doing this in Visual Studio.
Hmmm, no idea, can you ignore dependencies during the NuGet update, it is definitely compatible as we also have that same dependency in Umbraco itself.
Technically you shouldn't need to update 7.2.x-7.10.4 except if you've upgraded CDF before.
In general it is recommended that you use the very latest version of CDF so that you know that you're secure and benefit from the latest bug fixes and performance improvements.
Nope, CDF can be used on the frontend as well and is accessible through a public URL (DependencyHandler.axd). We haven't investigated this but if you can block the usage of that path then you might be safe.
Hi @Tim! Yeah, there IS a folder where these files are stored, I think it will use the Azure TEMP variable, in Kudu's debug console you can ask for echo %TEMP% to find the folder and in there you should find the UmbracoData folder and dig in some deeper to find the CDF caches.
FYI, I was looking into that this morning as the majority of our sites are on Azure.
"Another important note is that the Main site and the scm site do not share temp files. So if you write some files there from your site, you will not see them from Kudu Console (and vice versa). You can make them use the same temp space if you disable separation (via WEBSITEDISABLESCM_SEPARATION). But note that this is a legacy flag, and its use is not recommended/supported."
Edit: Should have mentioned that the best option appears to be restarting the app service. This is from the same link referenced above.
"A number of common Windows locations are using temporary storage on the local machine. For instance
%APPDATA% points to something like D:\local\AppData.
%TMP% goes to D:\local\Temp.
Unlike Persisted files, these files are not shared among site instances. Also, you cannot rely on them staying there. For instance, if you restart a web app, you'll find that all of these folders get reset to their original state."
I'm curious about forensic options for determining if a site has been exploited. Would it be true to assume that if a site's web.config was compromised we'd be able to find the contents of the web.config in one of ClientDependency temp files?
I've run into a backoffice whitescreen issue after performing the update. Framework version 4.5, Umbraco 7.2.1.
A single CDF related message is generated in the log file:
2018-09-21 10:33:47,183 [101] ERROR Umbraco.Web.UI.CdfLogger - [Thread 102] Could not load file contents from /umbraco/developer/RelationTypes/TreeMenu/ActionNewRelationType.js. EXCEPTION: This operation is not supported for a relative URI.
System.InvalidOperationException: This operation is not supported for a relative URI.
at System.Uri.get_PathAndQuery()
at ClientDependency.Core.CompositeFiles.Providers.BaseCompositeFileProcessingProvider.WritePathToStream(ClientDependencyType type, String path, HttpContextBase context, StreamWriter sw)
EDIT: Only difference so far between this and our other sites is that this is one of the only ones that has the Umbraco backoffice URL changed. Maybe this is related?
@Sebastiaan Janssen Seems this was related to the JS error in the RJP.MultiUrlPicker package mentioned elsewhere. Updating the package or manually patching MultiUrlPicker.js fixes the issue.
As an FYI to anyone who may come across this issue whilst installing the new update via NuGet, the install added the following to my web.config file, which caused the site to fail.
Hi, I just updated the client dependency manually using the 4.5 framework. For some reason I cannot get into the back end admin console now. Are there any known issues updating manually that would have caused this? when I go to the site/umbraco the backend page does not even load.
Security update for September 2018
As announced last week, we advise you to update your Umbraco sites for a security patch. You should update to ClientDependency version 1.9.7 now. More details in our blog post:
https://umbraco.com/blog/security-advisory-patch-for-your-site-is-now-available/
Umbraco HQ monitors this thread and will provide answers where possible.
If you're logged in to Our Umbraco you have a "Follow" button at the top right of this thread which will send you email updates of new replies to this topic.
https://umbraco.com/blog/security-advisory-patch-for-your-site-is-now-available/
Just as an FYI: the new Umbraco versions we're pushing out now contain nothing at all new, only the updated CDF version so that people who do fresh installs are safe by default.
Hey Sebastiaan, just to confirm - if I were to download Umbraco now which of these will be patched? i.e. only the most recent 7.12.2 version or are we going back further than that? Thanks!
The upcoming versions 7.10.5, 7.11.2 and 7.12.3.
Gotcha, thanks!
Hi, I have an Umbraco 7.3.8 website where Umbraco does not work (white screen) after replacing the ClientDependency.Core.dll file (Console gives SyntaxError in a JS file). I have cleared the caches in App_Data and have checked the dll is for the correct .NET version. If I restore the old version, everything works fine again. Any ideas how to fix this?
That is strange, we have tested on 7.3.8. Does it help to set
debug=true
in your web.config (when using CDF version 1.9.7)?Yes that works! On our test environment it was working, and when I changed debug to false in the web.config it stopped working. However, we would rather not have our production site running under debug mode. How do we best tackle this?
@Rowan - I'm afraid you're probably using NuPickers and that one needs to be updated too: https://www.google.dk/search?q=clientdependency+nupickers&oq=clientdependency+nupickers&aqs=chrome..69i57.5820j0j4&sourceid=chrome&ie=UTF-8
@Rowan Ah, I'm afraid you're probably using an old version of NuPickers and that needs to be updated too: https://our.umbraco.com/forum/umbraco-7/using-umbraco-7/61145-Packages-only-work-in-debug-mode
Hmm, the site does not seem to be running NuPickers.. The issue might be another old package if I understand your link correctly. I have applied the 'enableJsMinify=false' workaround from that thread for the moment while I work on patching our other sites, will research this further on later today..
That's an odd one @Rowan, but you should hopefully be able to get some clues with
debug=false
and having a look in the javascript console.In this case it was caused by an old version of the MultiUrlPicker (https://our.umbraco.com/packages/backoffice-extensions/multi-url-picker/) which had a syntax error in its JS (no ; after "use strict"), which causes ClientDependency to trip. Updating to the latest 1.x version worked for us.
Is the security issue itself only relevant to environments running .NET 3.5? Regarding this commit: https://github.com/Shazwazza/ClientDependency/commit/d353cc1369e052ab2dfb06bbf3c0eabcb1124dde#diff-74b40b5893da1f6bb4bdd4713b769464
No, it is relevant to all .NET versions, this is just so that we could build a version compatible with .NET 3.5 which some people still use on their Umbraco v4 installs.
We are manual patching, we have a couple of sites built on 4.5.2, will the 4.5 patch work as expected?
Thanks
Yes it will work with the 4.5 patch.
So:
Hi Sebastiaan,
what is the easiest way to verify that you've installed the correct patch?
I've installed the 4.5-patch on a website that is not 4.5 (it's a pretty old 4.x-website), but it doesn't give me any errors, YSOD's or anything like that.
After that I copied in (for testing purposes) the 4.0 dll and later even the 3.5 dll. But I never see any error pages or errors in the console... So how can I verify that I picked the correct one?
Kind regards, Jeffrey
Thanks
We also have one site on 4.6
Thanks If we have a site using 4.6, should we use the 4.5 download?
FYI: Umbraco releases 7.10.5, 7.11.2 and 7.12.3 are now available for download and the only change from 7.10.4, 7.11.1 and 7.12.2 is that the version of CDF has been updated.
7.12.3 is now the recommended release for starting new projects with.
If it works then you did it right! :)
Your application pool has a .NET version and that is the minimum version you should put in your site, if there's no ysod with a higher version then you're good to go. Usually MS doesn't make breaking changines in minor released so should be fine.
Hi Seb,
The advisory states:
Could this potentially be any configuration file, including the
web.config
?I'm just trying to gage how potentially serious this could be so as to know what resources to allocate (we host a lot of Umbraco sites, so this will be a big job for us).
You've correctly interpreted the word "any". 🙂
Sorry, that was a bit cheeky, but yes this includes the web.config file and you should be worried about other files in predictable paths that an attacker could know about (also files in the config folder for example).
Thanks, Seb :) I know it might seem dumb, but I was just trying to see if there was a distinction between Umbraco specific config files (ie.
/config/
) and any.config
file in the web root.We want to deploy the security patch on all of our websites, without opening them in Visual Studio (we want to do that later).
How can I tell on a deployed website which version on .NET it uses? I can see which version of Umbraco it uses in the web.config. Where can I find the .NET version?
I know of targetframeworkversion in csproj, but that file is not present. Thanks
@Sven you'd need to figure out what the application pool is configured as. I would think that the .NET 3.5 version should work everywhere.
Thank you for the answer. We read out all web.config files and use targetFramework
In
<system.web>
you should have a<httpRuntime>
element that may have atargetFramework
attribute that specifies this. For example:Thanks. We've used that setting
Hi, We've done the patch to our sites okay but are having a problem updating our local development instances via Nuget. It appears CDF 1.9.7 is not compatible with ClientDependency-Mvc5 1.8.0 (which we use) and I can't seem to select a lower version of ClientDependency-Mvc5 to around this impass. Here's the Nuget error: Update-Package : Unable to resolve dependencies. 'ClientDependency 1.9.7' is not compatible with 'ClientDependency-Mvc5 1.8.0 constraint: ClientDependency (>= 1.8.0)', 'UmbracoCms.Core 7.12.3 constraint: ClientDependency (>= 1.9.7 && < 2.0.0)'. At line:1 char:1 + Update-Package ClientDependency -Version 1.9.7
Sorry, its all good. Ensure you delete your files from /App_Data/Temp/ClientDependency folder before doing this in Visual Studio.
Hmmm, no idea, can you ignore dependencies during the NuGet update, it is definitely compatible as we also have that same dependency in Umbraco itself.
This patch upgrade is not needed for 7.2.x -7.10.4 right?
It affects all Umbraco sites. Dll depends on version of .NET the project uses. https://umbraco.com/blog/security-advisory-patch-for-your-site-is-now-available/
Technically you shouldn't need to update 7.2.x-7.10.4 except if you've upgraded CDF before.
In general it is recommended that you use the very latest version of CDF so that you know that you're secure and benefit from the latest bug fixes and performance improvements.
Thanks. We will continuew with the upgrade. So we can confirm our sites will be secured.
3 down 136 to go here.
Here's a tool that will list all Umbraco websites under a particular folder and allow you to apply the patch individually with a few keystrokes:
https://github.com/emanuelgaspar/UmbracoPatch20180920
You could change it to run automatically for all websites it finds after a few tests.
Hope it helps.
Just wanna thank HQ for the professional approach in the way the found security issue has been addressed!
Awesome job guys!
1141 from 1141 Umbraco installations Updated!
Hi Sebastiaan,
the issue is somewhere in the ClientDependency and as far as I know ClientDependency is only used in /Umbraco/.
We lock all our /umbraco/-paths on IP-address. Would it safe to say, that it wouldn't impact our websites?
Regards, Jeffrey
Nope, CDF can be used on the frontend as well and is accessible through a public URL (DependencyHandler.axd). We haven't investigated this but if you can block the usage of that path then you might be safe.
Comment author was deleted
Hey Seb,
Small q, we are hosting most of our sites on azure with the setting
So there is no ~/AppData/ClientDependency or ~/AppData/Temp/ClientDependency folder... is there anything else we need to clear in this case?
Hi @Tim! Yeah, there IS a folder where these files are stored, I think it will use the Azure
TEMP
variable, in Kudu's debug console you can ask forecho %TEMP%
to find the folder and in there you should find the UmbracoData folder and dig in some deeper to find the CDF caches.Comment author was deleted
Ok thanks for the input!
FYI, I was looking into that this morning as the majority of our sites are on Azure.
"Another important note is that the Main site and the scm site do not share temp files. So if you write some files there from your site, you will not see them from Kudu Console (and vice versa). You can make them use the same temp space if you disable separation (via WEBSITEDISABLESCM_SEPARATION). But note that this is a legacy flag, and its use is not recommended/supported."
Source: https://github.com/projectkudu/kudu/wiki/Understanding-the-Azure-App-Service-file-system
Edit: Should have mentioned that the best option appears to be restarting the app service. This is from the same link referenced above.
"A number of common Windows locations are using temporary storage on the local machine. For instance
%APPDATA% points to something like D:\local\AppData.
%TMP% goes to D:\local\Temp.
Unlike Persisted files, these files are not shared among site instances. Also, you cannot rely on them staying there. For instance, if you restart a web app, you'll find that all of these folders get reset to their original state."
I'm curious about forensic options for determining if a site has been exploited. Would it be true to assume that if a site's web.config was compromised we'd be able to find the contents of the web.config in one of ClientDependency temp files?
Thanks y'all! Moving all of my sites to a single instance of Umbraco last year just paid off.
I appreciate that you take the effort to proactively deal with security issues.
Keep up the good work!
Timothy
Hi,
I've run into a backoffice whitescreen issue after performing the update. Framework version 4.5, Umbraco 7.2.1.
A single CDF related message is generated in the log file:
EDIT: Only difference so far between this and our other sites is that this is one of the only ones that has the Umbraco backoffice URL changed. Maybe this is related?
@Mick Does the backoffice work for you however?
Do you have different results when setting
debug=false
in the web.config?@Sebastiaan Janssen Seems this was related to the JS error in the RJP.MultiUrlPicker package mentioned elsewhere. Updating the package or manually patching MultiUrlPicker.js fixes the issue.
Hi all,
I am having .Net 4.5. Just wanted to confirm the steps if I am manually applying for security patch.
In local .Net project
On live project,
@hrg Make sure to delete the temp files from your live site too (make a backup first).
Yes.
Thanks
Hi Sebastiaan,
We upgraded a 7.2.6 site using the nuget update method, but it also modified the web.config by replacing this line:
with this:
Also this was added to the
<pages>
section:Also the verb changed from * to GET on this line inside
<httpHandlers>
:And these lines got added into
<handlers>
:Are these changes expected? Or should we roll them back?
Thanks, Andy
+1
+2
Happens sometimes! You can roll those back, no problem.
The effect of the update should be that the dll is updated nothing else needs to change.
Then of course on your live site, update CDF version and delete temp files after backing them up.
As an FYI to anyone who may come across this issue whilst installing the new update via NuGet, the install added the following to my web.config file, which caused the site to fail.
All I had to do was remove it again from the web.config file and all was well again.
Comment removed
If we have extra class library projects in our solution, will we need to update the Client Dependency for them also?
You should update all references in all your projects, yes.
Hi all
We have a problem with Newsletter Studio after updating ClientDependencyCore.dll
We have tried updating newsletter studio to latest version also.
When we open the module we get the following error in console, and the module does not work.
Error: Argument 'NewsletterStudio.Dashboards.NewsletterMainDashboardController' is not a function, got undefined
Anyone got an idea on how to solve this problem?
Did you try clearing all of the CD temporary files/cache?
Do you mean the cache folder in App_data ?
I have tried clearing all data in the browser.
Yeah it will be the files in APP_DATA\TEMP\
Yeah. That might do it.
Hi, I just updated the client dependency manually using the 4.5 framework. For some reason I cannot get into the back end admin console now. Are there any known issues updating manually that would have caused this? when I go to the site/umbraco the backend page does not even load.
See the comments above, there was a known issue with nuPickers that may apply to your situation. https://our.umbraco.com/forum/using-umbraco-and-getting-started/93808-security-update-for-september-2018#comment-296594
is working on a reply...