If you have additional questions not covered in the blog post please use this forum post dedicated to this topic.

Umbraco HQ is monitoring questions on this topic closely for the next few days.

You can subscribe to email notifications for this forum post (hit the "follow" button at the top right) to receive updates.

We will not be answering questions on how the vulnerability can be exploited in order to give everyone a fair chance to get their sites updated first.

Note: we expect similar questions to the previous security update for ClientDependency, try to see if you can find an answer to your question in the older topic first: https://our.umbraco.com/forum/using-umbraco-and-getting-started//93808-security-update-for-september-2018

Regarding this tweet:

https://twitter.com/FyinInc/status/1239814202400759809

We posted a dll for .NET 3.5, 4.0 and 4.5 the last time ClientDependency needed to be updated. This turned out to be unnecessary, we have only posted the .NET 3.5 version of the dll this time, which works with all other .NET configurations. There was no need to differentiate the three frameworks.

Hi Seb,

Has the location where files generated by the ClientDependency changed at all?

It hasn't, why do you ask?

I'm noting that some patched sites don't create a ClientDependency folder in ~/AppData/Temp

Those files only get created when compilation debug="false" in the web.config and DependencyHandler.axd actually gets used. This should happen after you go to the login screen for the backoffice or to the frontend of your site if CDF is used on the in your frontend templates.

It is possible that with some configuration settings in web.config that the App_Data/TEMP folder is being located somewhere else. For example: https://our.umbraco.com/documentation/getting-started/setup/server-setup/load-balancing/file-system-replication#non-replicated-files

Additionally, you might want to check ClientDependency.config since the storage directory is configurable:

<!-- A file map provider stores references to dependency files by an id to be used in the handler URL when using the MappedId Url type -->
<fileMapProviders>
  <add name="XmlFileMap" type="ClientDependency.Core.CompositeFiles.Providers.XmlFileMapper, ClientDependency.Core" 
      mapPath="~/App_Data/TEMP/ClientDependency" />
</fileMapProviders>

I was looking to answer a similar question.

We're running a site as an Azure Web App. The ClientDependency.config file lists:

~/App_Data/TEMP/ClientDependency

But we have no such folder.

Links to JavaScript dependencies are still using with DependencyHandler.axd (and working) - just can't find the files.

In a separate question.

I noticed when I've used the nuget update method the web.config is modified

Mainly

<add verb="*" path="DependencyHandler.axd" type="ClientDependency.Core.CompositeFiles.CompositeDependencyHandler, ClientDependency.Core " />

The verb is changed to: verb="GET"

And a few other bits. Do these need manually merging if you just copy the dlls in?

When I try to use the new ClientDependency it throws an error. "This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms."
System.Security.Cryptography.MD5CryptoServiceProvider..ctor()

Is there another version that is FIPs compliant?

We have a shared server with a number of Umbraco sites hosted on it. For the security patch in September 2018 I wrote a PowerShell script to automate replacing the dll and deleting the cached files. Luckily I could just reuse the script for this new patch.

Here it is if anyone is in a similar situation.

You need to have the new dll in the same directory as the powershell script (save it as a .ps1). Run PowerShell with Administrator rights to have access to IIS, you may also need to modify your execution policy (ask Google).

It grabs all started sites from IIS, checks if they are umbraco sites (by looking for the folder "umbraco"), then checks if they are using a different version of the dll, if so replaces it and deletes the cache folder(s). I note that the new security advisory recommends backing up the cache folder to check for any data breaches - this script does NOT do that, it just deletes them.

After each site it has actioned, it asks you to confirm with Enter. I wrote it that way as the sites restart immediately and if there are lots of sites this could max out the CPU on the server, so just keep an eye on CPU and do a few at a time.

Obviously use at your own risk, so please make sure you understand what the script does.

Script has been used with Umbraco 7 and 8

Import-Module Webadministration

# copy the current version of ClientDependency.Core.dll into the folder that this script is executed in!
$UpdatedCdPath = Join-Path $PSScriptRoot 'ClientDependency.Core.dll'
$UpdatedCdVersion = (Get-Item $UpdatedCdPath).VersionInfo.FileVersion

function GetCms([parameter(Mandatory=$true)]$website)
{
    $cms = ""
    if (Test-Path $(Join-Path $($webapp.physicalPath) "umbraco/"))
    {
        return "umbraco"
    }
    else
    {
        return "other"
    }
}

function GetUmbracoVersion([parameter(Mandatory=$true)]$website)
{
    $umbracoVersion = ""
    $webConfigPath = Join-Path $($webapp.physicalPath) "web.config"
    if(Test-Path $webConfigPath)
    {
        [xml]$webConfig = Get-Content -Path $webConfigPath
        if($webConfig.configuration.appSettings)
        {
            $appSettings = $webConfig.configuration.appSettings
            if($appSettings.configSource)
            {
                [xml]$appSettingsXml = Get-Content -Path $(Join-Path $($webapp.physicalPath) $appSettings.configSource)
                $appSettings = $appSettingsXml.appSettings
            }
            foreach($setting in $appSettings.add)
            {
                If($setting.key -eq "umbracoConfigurationStatus")
                {
                    $umbracoVersion = $setting.value
                }
                If($setting.key -eq "Umbraco.Core.ConfigurationStatus")
                {
                    $umbracoVersion = $setting.value
                }
            }
        }
    }
    return $umbracoVersion
}

function UpdateClientDependency([parameter(Mandatory=$true)]$website, $item)
{
    $clientDependencyPath = Join-Path $($webapp.physicalPath) "bin\ClientDependency.Core.dll"
    if(Test-Path $clientDependencyPath)
    {
        $item.CdVersionPre = (Get-Item $clientDependencyPath).VersionInfo.FileVersion
        if($item.CdVersionPre -ne $UpdatedCdVersion)
        {
            $binFolder = Join-Path $($webapp.physicalPath) "bin"
            #Copy-Item $UpdatedCdPath -Destination $binFolder -WhatIf
            Copy-Item $UpdatedCdPath -Destination $binFolder

            $tempFolder = Join-Path $($webapp.physicalPath) "App_Data\TEMP\ClientDependency"

            #Get-ChildItem -Path $tempFolder -Include *.* -File -Recurse | foreach { Write $_.Name }
            Get-ChildItem -Path $tempFolder -Include *.* -File -Recurse | foreach { $_.Delete()}
            $item.TempFolderItems = (Get-ChildItem -Path $tempFolder | Measure-Object ).Count;

            # some sites seem to have this folder as well
            $tempFolder2 = Join-Path $($webapp.physicalPath) "App_Data\ClientDependency"
            if(Test-Path $tempFolder2)
            {
                Get-ChildItem -Path $tempFolder2 -Include *.* -File -Recurse | foreach { $_.Delete()}
            }

            $item.CdVersionPost = (Get-Item $clientDependencyPath).VersionInfo.FileVersion

            Read-Host "Updated $($website.name). Press ENTER to continue..."
        }
    }
}

function PatchWebsites()
{
    $list = @()
    foreach ($webapp in get-childitem IIS:\Sites\)
    {
        $cms = GetCms $webapp
        if($cms -eq "umbraco")
        {
            $item = @{}
            $item.WebAppName = $webapp.name
            $item.CmsVersion = GetUmbracoVersion $webapp
            UpdateClientDependency $webapp $item

            $obj = New-Object PSObject -Property $item
            $list += $obj
        }
    }
    return $list
}


$websites = PatchWebsites

Write $websites | Format-Table WebAppName,CmsVersion,CdVersionPre,CdVersionPost,TempFolderItems -autosize

As for the TEMP folder location, Kevin's package source gives us the correct way to find it. Unfortunately, the package currently has no files so we can't use it for now.

I've whipped up a little class you can drop into App_Code with 3 WebApi endpoints: https://gist.github.com/nul800sebastiaan/2dfb053cc5523e735e48afbed456f091

https://{yoursite}/Umbraco/Api/TempFile/GetCDFFiles

Lists all the ClientDependency TEMP directory and all the files in it.

https://{yoursite}/Umbraco/Api/TempFile/GetCDFTempFiles

Zips and downloads all the files in the ClientDependency TEMP directory

https://{yoursite}/Umbraco/Api/TempFile/DeleteCDFTempFiles

Deletes all the files in the ClientDependency TEMP directory and lists the files that have been deleted.

⚠⚠⚠ Warning: these are PUBLIC endpoints that anybody can use!

Make sure to delete the file from App_Code once you're done!

We have a few old solutions running Umbraco 7.2.4. Installing the DLL and wiping the ClientDependency folder resulted in Umbraco backoffice not loading, with the following Javascript error:

Don't you need to update your advisory - you are just directing everyone to the ~/App_Data folder.

As discussed here - that isn't always where the files are - sometimes they will be placed in your environment temp directory - and you can also configure this.

The advisory should probably be updated - to detail how to find your client dependency generated files. There is a link to this thread, but I think it is a bit of a stretch to imagine that everyone will follow through and find the details above.

Hi all,

Just seen the post on the update.

Could someone please help on confirming my steps to update my site.

I'm running Umbraco 7.8.1.

Are these steps correct

• Download dll (http://umbracoreleases.blob.core.windows.net/securitypatches/ClientDependency.Core.dll.1.9.9.zip) and paste into bin directory of my Umbraco CMS, and replace the old client dependency dll with the new one.

• Stage, check-in and push new dll to source control

• Delete ~/App_Data/Temp/ClientDependency

Thanks,

Wayne

Cool, will do, was just double-checking committing the dll to source control.

Thanks,

Wayne

I could have sworn the original post mentioned deleting all files in ~/AppData/ClientDependency or ~/AppData/Temp/ClientDependency after the BIN file upgrade. But I don't see that advice anymore. Is it still current?

Dear Seb,

I'm trying to apply the 1.9.9 version of ClientDependency, however I couldn't find any later version than my current one (1.8.4) in NuGet, do you know the reason behind this?

Dears, I Upgraded from V 7.7.6 to V 7.15.3 in both versions i got blank page with the attached error if debug=false in pre production or production environment but in testing environment it works fine Note : i replace new ClientDependency.Core.dll but the same issue still appears.

is working on a reply...