MS emergency fix plugs ASP.Net web development hole Microsoft has released an out-of-cycle patch designed to address a serious flaw in its ASP.Net web application development toolkit. The vulnerability, which has been under active attack for several weeks, creates a mechanism for attackers to read any file on a web application server. Microsoft rates the flaw as only "important …
It took MS weeks to provide a fix which would have taken two days in the OS community. Meanwhile the miscreants messed with other people's data on unprotected servers, as everybody could read about the exploit weeks ago.
Also, MS apparently has zero security competence, assessing all their cock-ups. One of the best was using RC4 to encipher Word documents without using different IVs. Now we all know what Bill Gates meant with "Security Development Lifecycle".
FAIL.
Hanselman tweeted a great article a while back (which I can no longer find, sorry - if anyone knows it please send it on, it was a great article) which demonstrated how long it takes Microsoft to change one line of code.
The reason they take so long is because one change affects thousands of developers, who's code then affects thousands more end users, so the QA has to be rediculously high, including regression testing to make sure a patch will not somehow break someone else's codebase.
Then, after this the process has to go through localization which again, includes testing but this time in dozens more frameworks which are localized.
Ten days ain't bad considering the standards to which MS adhere to.
I know I sound like a MS whore (ok, I'm a C# Developer so I AM a MS whore) but credit where credit is due.
"The reason they take so long is because one change affects thousands of developers, who's code then affects thousands more end users, so the QA has to be rediculously high, including regression testing to make sure a patch will not somehow break someone else's codebase."
Handling changes is not new. Especially for the open source world. I get updates daily. Never had an update mess something up. Which is incredible considering all those 10 thousands of developers changing a lot of lines of code.
As a programmer you must have heard about modular system design, interfaces and that kind of stuff. That makes it possible to change code without affecting the work of other people.
I really want to read that article now. How is it possible, if you design software the right way, that a single line of code can affect 10*10^4 other developers? Surely Microsoft must have some design goals, preventing this scenario.
I understand that there are QA procedures, but this is a bit far fetched.
What they could do is to push out a hotfix two days after recognizing a problem and skip extensive testing for that. Users would make the deployment/non-deployment decision themselves.
Competent users have a sandbox where they can test a patch without affecting production.
Two weeks later the "highly tested/officially sanctioned" version of the patch would be distributed as an automatic update.
The bigger issue here is that ScriptResource.axd can read ANY file from the file system (it's like a SQL injection on crack), as this is a patch I can't find out from the .NET source code, and Microsoft are being quite silent on the issue - could you find out please whether this fix is just to the encryption weakness or if it closes the rather rediculous ability for ScriptResource to pull any file it chooses off of the file system.
There is a pint in it for ya,
Ta,
C.
Don't need it for the base Framework, but of course, I could reflect the patch - thanks man good call.
I slapped an semi-patch idea over here: http://forums.asp.net/p/1603799/4088646.aspx#4088646 - I'd prefer just to shut down the feature that allows it to read the file system completely.
To be hoenst though, it would just be better if MS fixed the issue themselves, save hacking something over the top of it.
I know that quite a few careers depend on MS, so I should expect some flaming. Still, Adobe, MS and Oracle display a truely soviet-style-bureaucratic behaviour when it comes to patching. And their developers are badly trained in security subjects.
I would expect every MS developer attend a two-week seminar on crypto and security subjects. They should know what a symmetric cipher, a public-key cipher, a strong hash, buffer overflows, SQL injections, message authentication, security/lackof of stream ciphers, weak random numbers& session hijacking are. Apparently other stuff is more important to MS management. Like pushing out new features which will drive sales ($$$!) as quickly as possible.
Most developers are lazy bastards who don't educate themselves. So management has to drag them into trainings. Apparently MS doesn't manage. Linux and BSD do. Without centralized management.
"The vulnerability stems from a cryptographic weakness, specifically involving improper error handling during encryption padding verification.".
I wish the IT press would get it's facts straight instead of bandying around sensationalist crap like this .
This has nothing to do with a cryptographic weakness, this is about ASP.NET revealing too much useful information when a CryptographicException is thrown.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
