Microsoft to patch ASP.NET mess even if you don't Microsoft has taken the final step in sunsetting a dangerous server setting, announcing that all future versions of ASP.NET will enforce the deprecation of EnableViewStateMac=“false”. Since December 2013, when this security advisory landed, Redmond has warned sysadmins that the setting had a privilege escalation vulnerability …
So, does this mean that even if you don't install the updates on your server, this will still happen?
Not that I use this feature, but it sets a worrying precedent and nightmare for giving any sort of low-cost long-term support for "complete" projects if Redmond will just deprecate things as security holes are found in them.
Well, the article title says MS will do it even if we won't, and they allegedly have previous for updating some things without the users permission.
http://www.informationweek.com/microsoft-updates-windows-without-user-permission-apologizes/d/d-id/1059183?
Also, my concern was more along the lines of, in most places there is a difference between the person developing the application and the person managing the server. In shops where products last five, six, seven years and staff typically don't last that long, there's no way for a server owner to know what a patch might just disable / break under the broad "security fixes" heading without having knowledge of the code for all the products in their care -- which while it may be ideal is an unrealistic expectation to have.
They're doing it via their new and wonderful invention: Quantum Entanglement (®, TM, pat. pend). If they enable the flag on their server, it gets disabled on yours. Large scale deployments are also possible - in order to disable it in our universe, it has to be enabled in the parallel universe, where, as an added bonus, it might actually work well.
There is a downside, though. Every time the switch is flipped, a cute cat with a German-sounding name will be either dead or alive.
/the one with QT for Dummies in the pocket, thank you/
AC: It _was_ set to the secure setting by default! MS are admitting they never should have allowed the mentally incompetent to de-secure it.
And there's no valid reason for it to be an option. Learn to do servers securely (both devs and admins) or not at all, and just bloody deal with it properly. About the only thing left to do is scour stackexchange / serverexchange for all references to it, and down-vote to hell any answer which says to set the option.
Microsoft's commitment to rapid product releases and bundling security patches with behavior changes is going to assure that we have these problems more frequently. In The Real World, it's not uncommon for an "enterprisey" business system to be deployed that takes advantages of certain "features" in an OS, browser, etc. Said system is usually one-off, costs tons of money to replace or fix, and can't easily be extracted from day to day business operations. Yes, running something like IE 6 or unpatched JRE 1.4 is awful, but sometimes it's necessary. The consultants who build said systems are already long gone and often demand huge sums when they are called back to update these kinds of applications.
I'm hoping that if Microsoft stops releasing discrete "versions" of their products, as they're rumored to be considering, they'll at least do a Long Term Stable branch like some of the Linux distributions do. That LTS branch can have the old patch framework -- patches are patches and feature updates are optional.
We're currently dealing with this fun combined feature/patch...identifying and fixing this on a universal basis for everyone in our organization is going to be fun.
http://blogs.msdn.com/b/ie/archive/2014/08/06/internet-explorer-begins-blocking-out-of-date-activex-controls.aspx
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
