ASP.NET MVC security patch to version 3.0.0.1 breaks build [duplicate]
Asked Answered
T

4

107

After installing the ASP.NET MVC 3 security update KB2990942 it appears the MVC version increased from 3.0.0.0 to 3.0.0.1. This causes Visual Studio to no longer find the reference.

<Reference Include="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

Resharper does not show any problems but the build fails with lots of unresolved MVC types and a warning:

Warning: Could not resolve this reference. Could not locate the assembly "System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

This kind of makes sense. This version no longer exists on my machine.

I cannot guarantee the exact MVC version on dev machines, build servers and production servers. They might have 3.0.0.0 or 3.0.0.1 and this might change at any time. Windows Update might release new MVC versions at any time. Also, I don't want to increase the version number in all *.csproj files whenever an MVC update is released.

Multiple versions are affected by the update:

The security bulletin: MS14-059: Vulnerability in ASP.NET MVC Could Allow Security Feature Bypass (2990942)

What's the best way to deal with this situation? How can I unbreak build and production and be safe regarding future MVC updates?

Truckle answered 16/10, 2014 at 14:27 Comment(9)
Same issue today with 4.0.0.1, we just re-referenced System.Web.Mvc. Would be nice to have a more robust referencing solution.Appendage
You should at least be able to guarantee that your build servers and production servers run in an identical environment. Dev machines can run out of sync, but you can deal with such problems when they arise. Your build servers should uncover any issues.Pastry
@Stijn I plan to do that but I cannot guarantee that updates happen at the exact same time. The development process must work on its own for a few weeks without manual attention.Truckle
That being said, this could be an annoying issue. The updates haven't hit our machines yet, do you know if it breaks production? And I see in Windows Update that MVC 2, 3, 4 and 5 are affected.Pastry
It did not break production with MVC 3. In the GAC I found a "System.Web.Mvc.dll.config" that has a binding redirect. Apparently, this file is being used by the CLR.Truckle
We had the exact same behavior, but none of the patches listed are installed on our machines...odd.. patches were installed just not those numbers listed.Cush
@Eric those patch numbers are for a Windows 7 x64 system, they may be different for other systems.Pastry
Not the issue, (I'm on w7 64, btw), it does not show up under installed updates at all, turns out it shows up as reinstalling asp.net mvc #.. the installed date and file version # change.Cush
Related: System.Web.MVC not copied to bin folder since MS14-059Lowrance
B
66

I fixed this by:

  • Removing the MVC reference and add the correct reference to the project.
  • Changing the Copy Local property of the reference to true.
  • Update the bindingRedirect setting in web.config:

web.config runtime section:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
            <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.1" />
        </dependentAssembly>
    ...

Changing the Copy Local setting will include the System.Web.MVC.dll file in the bin folder when you publish the project, so that it works even if the server is not updated with the new version.

Note that updates like this rarely happens. This is the first time that MVC 3 has been patched since it was released. You should be able to change Copy Local back to false once the servers has been updated. The next time Microsoft makes an update like this, they will probably know to fix issues like this first.

Birdbath answered 16/10, 2014 at 16:15 Comment(7)
I did the same apart from changing the copy local property of the reference. This seems to make my project work.Bootery
Be aware, these patches do not show up as installed updates, you have to go look at the Asp.Net MVC # shown under normal add remove programs, it will have a date of install when the patch was applied (for me 10.15.2014)Cush
@EricBrown-Cal: Do you mean the server version update? On my computer it shows up as an installed update.Birdbath
Setting CopyLocal=true did not help us; see: System.Web.MVC not copied to bin folder since MS14-059Lowrance
For me, if you open add remove programs/features and click on view installed updates, the KBs don't show up. If you go back to add remove, goto asp.net MVC (3 in my case) it will show it installed with a new date (in my case 10/15/14). That was the only way to detect it on my machine except file/path compares.Cush
@EricBrown-Cal: Yes, that list doesn't show all updates for some reason. If I open PC Settings, go to Update and recovery, and click View your update history, it shows all updates.Birdbath
This partially solved the problem for me as in that my solution buids once again. However, it now shows me several warnings: Assuming assembly reference 'System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' matches 'System.Web.Mvc, Version=3.0.0.1, Culture=neutral, PublicKeyToken=31bf3856ad364e35', you may need to supply runtime policyFinding
H
27

I installed Microsoft.AspNet.Mvc package in my project using Nuget.

Install-Package Microsoft.AspNet.Mvc -Version <version> -Project PROJECTNAME 

MVC 4 version: 4.0.40804.0

MVC 3 version: 3.0.50813.1

This fixed the problem. Details here: http://blogs.msdn.com/b/webdev/archive/2014/10/16/microsoft-asp-net-mvc-security-update-broke-my-build.aspx

Hypertrophy answered 21/10, 2014 at 15:33 Comment(1)
Thank you, this was the best solution for us and it removed the dependency of the correct version in the GAC on build agentsMongo
S
12

Your production system should be fine as the hotfix delivers a config file (System.Web.Mvc.dll.config) into the following folder:

%SystemRoot%\assembly\GAC_MSIL\policy.3.0.System.Web.Mvc\3.0.0.1__31bf3856ad364e35

The config file contains an assembly redirect to the new version, this will override anything you have in your web.config:

<?xml version="1.0"?>
<!-- http://msdn.microsoft.com/en-us/library/7wd6ex19.aspx#BKMK_Redirectingassemblyversionsbyusingpublisherpolicy -->
<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                <bindingRedirect oldVersion="3.0.0.0-3.0.0.1" newVersion="3.0.0.1"/>
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

Follow the advice by @Guffa for your build system, or use nuget to update. I believe the solution which works depends on how you deliver the MVC binaries to your system (either bin deploy or GAC).

Stripe answered 17/10, 2014 at 8:26 Comment(3)
Can't find this file on my system. Any reference for this information?Lithium
@julian as it's the gac you might have to traverse the directory using an elevated command prompt. Also I believe this only applies if you installed mvc, if you nuget (bin deploy) mvc this may not be present on your system.Stripe
What's interesting is that one can (1) apply the update and get this config file, then (2a) go back and update his NuGet package to the newest version and (2b) forget or fail (such as from a bad revert) to update the binding redirect in your web.config file. The result? The existing serveris fine, but if you try to deploy to a new server that doesn't have the update installed (and it wouldn't be offered till it sees the old version loaded), you'll bomb because your bindingRedirect was wrong all along and you didn't realize it -- you were saved by this extra redirect supplied by the update.Roxyroy
S
1

What worked in my case was to change the Reference element in project file so Version=3.0.0.0 is now Version=3.0.0.1. I also updated the System.Web.Mvc.dll file sitting in _bin_deployableAssemblies folder to the new version and added a HintPath element in the Reference element pointing to said dll so it's picked up even when in GAC we still have version 3.0.0.0.

The tricky part is to not forget to update reference in all projects referencing System.Web.Mvc (e.g. including test project).

Sinciput answered 12/11, 2014 at 19:35 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.