Slashdot Mirror
Microsoft Issues Ominous ASP.Net Security Warning
An anonymous reader writes "A security flaw in Microsoft's ASP.NET apparently allows access to password-protected areas just by altering a URL. There's no patch yet, but in the meantime Microsoft is telling ASP.NET developers they can rewrite their applications to prevent exploits. About 2.9 million web sites run on ASP.NET according to Netcraft." Some more links: another Microsoft article, NTBugtraq, K-Otik and Heise.
In *any* server-side scripting language, you should doublecheck each string you get from an URL, POST, etc.
Seriously though, until MS issues a patch, telling people to change their code makes the most sense. There isn't another option except to wait for MS to get its poop in order... which could take a little while. It sucks, but what else are they going to tell people? You can wait for the patch and be insecure, shut down your site, or re-write the code.
My sig is blank, I typed this by hand.
...why people refuse to use PHP. How far are you going to trust Microsoft to get it right? How many vulnerabilities does it take?
It sounds better to yell "rewrite!" for the knee-jerk Slashbots rather than "five line patch!"
There is a patch coming, but it's not available yet. Application writers can (and should) fix their applications to address the issue until the patch is available, but those who can't or don't want to won't be unprotected forever.
"People that quote themselves in their signatures bother me" - athakur999
And that's why Microsoft is going to eventually lose the war against open source. Can you imagine the heated boardroom discussions going around the table now?
Unfortunately, no this probably will not happen (this way). The PHBs will simply say to the IT department: "We have a Support Agreement, right? Good. Get on it!" And, unless someone actually compromises the system, all will be forgotten. Even then, at most the typical boardroom response will be "damn Linux using Dirty Hippies (tm)."
The problem is, you assume that the corporate top layer cares about the details of implementation, when in fact, their world is a world of charts and graphs and executive summaries that don't hit these kinds of points.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
You know, even "5 line patch" says to me "We got bitten in the ass by a bug we've been bitten in the ass by numerous times in the past, and our core web framework is affected."
.NET and the company that produces it, that the flaw should never have been there. They should have worked to cover their flank in a previously sensitive area. That they havent indicates that their new focus on Trustworthy Computing is largely meaningless.
It's not the first time they've had a cannonicalization issue. It greatly diminishes my confidence in their product, if only because this indicates they didn't think to focus testing on an area which has presented security issues for them in the past.
Yes, the fix is small; the point would be, however you feel religiously about
the fact that all the expensive licensing that the clients pay to MS because the product is 'supported'. If you have to rewrite your applications while waiting for a fix, you may as well use an open source solution because MS is neither giving you the quality product they promised nor the quality support they promised.
putting the 'B' in LGBTQ+
Open Source may provide security *benefits* -- that does not make it immune to holes. The same thing could happen to an Open Source package with a broken API.
Have you ever seen Linux software using tmpnam(), for instance? That's an API bug right there.
Look, this is a darn large security hole. It'll result in some *huge* breakins for years to come. *However*, this is not a Microsoft- or closed-source- specific problem. It could happen just as easily to, say, the perl community.
May we never see th
I understand your reaction, but you are misunderstanding the issue.
Your post seems to implicate the application developers.
The URL based security is a built-in functionality of the framework. The framework handles all of the checking for you, so you don't have to do that checking yourself. If the framework works as advertised, the developer SHOULD NOT be doing these checks. That is the benefit (and problem) with working with a higher abstraction.
Unless you are doing these checks with machine code, you too are depending on some other pre-built library or compiler to do it correctly.
If the library or compiler (or framework) does it incorrectly, don't blame the application developer.
Rewrite - yes; too extreme
"five line patch" - too simple
There are companies that have to research, document, code, document, test, document, release from development to production, document, etc...
A better description lies somewhere between "rewrite" and "five line patch". Proprietary or OSS will have bugs; this release cycle still has to be done if it is a "rewrite" or a "patch".
Just something to think about.
BSD is designed. Linux is grown. C++ libs
Ok so it's not an application rewrite. Ok so it is ONLY a 5 line patch.
Does no one here work in an organized company that has rigid procedures such as TESTING?!?!
What about the downtime of those apps while you do the patching and testing and redeployment?
So what if you don't need 2 weeks to write every ASP.NET application in the company. You do need the resources to test each application. No matter how much you try to play down the crisis, this is going to cost the corporations M-O-N-E-Y.
And what happens when MS gets their act together and releases a patch? Are you simply going to run the patch and leave it at that? No need to test all your applications against that new version of ASP.NET? For those of you who write applications that select * from grommets and display tables on a webpage, this might not be a big deal. But those of us doing heavy duty enterprise development will see a higher impact.
IIRC, Java hasn't had any of these type of problems within their development platform.
Please don't be so self-righteous. There are reasons that MS has earned such a reputation.
When developing software/languages intended for secure communications over the Internet, the authors are obligated to perform very extensive testing (which should probably involve hiring outsiders to try and circumvent any security measures.) This particular security problem just reflects MS's generally carelessness -- after all, what would people do if MS wasn't very enthusiastic about fixing problems? Use a different platform?
If, by "anti-MS slashdotter bullshit", you meant "valid complaints about yet another thing MS has botched", then you can ignore this post.
--Colin
I believe the difference is the PHP leaks have been resolved.
cat
It could happen just as easily to, say, the perl community.
Granted, you are correct, but I might add that while such things might happen to Open Source communities, since we aren't paying for such things, we are less offended when they break. When Microsoft fouls up, we all get mad because we've maybe paid too much money for the product/license to begin with so we believe it should function better than a free solution. Sadly the opposite is often more true!
More often than not, Open Source solutions operate better than Microsoft products for any given circumstance.
The dangers of knowledge trigger emotional distress in human beings.
It's an exploit for a third party PHP project someone has written. Not a core vulnerability in the language. I'd wager that about 95% of PHP vulns are the fault of idiots who write crap like this: But this vulnerability is for a third party application, and also assumes that the attacker already has ftp access to the system he's compromising.
Now I'm not saying that PHP is rock solid, but at least look at what you're linking before posting the kneejerk "PHP is insecure too!!!1" stuff.
There are companies that have to research, document, code, document, test, document, release from development to production, document, etc...
A better description lies somewhere between "rewrite" and "five line patch". Proprietary or OSS will have bugs; this release cycle still has to be done if it is a "rewrite" or a "patch".
I would hope that any company that has a formal release cycle in place would have taken one look at this form of authentication and dismissed it just like most other ASP.NET programmers have.
When I first saw the web.config security I thought to myself, so what I'm still going to have to write a security system on top of this because it doesn't do jack.
I'm not worried about this with any of my sites. You may be able to get to a file in the admin section but you are still going to fail the test that runs inside the code. All the web.config did was stop you before it got to that check. I may program with microsoft tool but I don't trust them to do my security work for me.
Microsoft has pretty much never won a battle against open source on this front. It has never exceeded 35 percent in market share and it seems stalled at about 20 percent with no signs of movement. It got where it is today by putting the smackdown on other proprietary systems (Netscape/iPlanet/Sun), with little or no switching from Linux and BSD.
It seems that any movement above the natural stable point in the low 20s is temporary. Every time IIS makes a big move in market share it only lasts a few months...then a "Code Red" sort of crisis scares people away and they never come back--even if there is a patch offered it seems that deploying the patch is too much trouble for hosting companies ans do they resort to bringing the old Suns back online or switching to Linux or BSD--becasue they never experience disruptions on the scale of those inflicting IIS.
Interestingly, this puts a hole in the MS-friendly argument that "people hate them because they are popular" making it the lead target of crackers. In terms of RATE of attack (percentage of total servers attacked--NOT absolute numbers), market leader Apache is NEVER attacked as much as distant also-ran IIS. If it was ONLY about crackers boasting of their skillz in bringing down big, popular sites, then Apache would be attacked far more often. Sad truth is...IIS is just that much easier to crack.
Maybe we should stay away from bandwagons entirely? :)
::jafomatic
You are assuming that the company/organization running the ASP.NET solution actually developed and maintains the code. If I am a small company that hired company ABC to develop a website for me because I have no web developers, I'm not going to chance updating the application. I'll have to pay ABC to come out and update the application. This may involve creating a contract or burning up support hours. Most likely though, the companies IT staff would be more willing to apply a patch versus a solution modification. In addition to not being able to update code, you could always find that by making an update without the developers approval, you could invalidate a support agreement for making modifications.
You update your own code which uses the MS application.
Yes, you can update your own code pretty easily, but if the code exist at deployed sites, you may have a problem. For simple sites, your right though that an update like this isn't a big deal. To be fair though, even the the eventual MS patch will require effort for install and testing, but most users are more comfortable applying a patch than updating code.
But is it really fast, when you have to deal with problems like these?
It's like saying I own a really fast car, but it's in the shop a lot. Is that still the best car for you?
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
Note that he said unbillable hours. If you're not getting paid for it, it's not much of a job, is it?
One line blog. I hear that they're called Twitters now.
Clearly you don't have much experience with the sort of systems where absolutely nothing takes a 'few hours' of testing.
The difference being that one I payed for and expect support, the other I didn't and expect to provide my own support. If I were an asp.net customer I would seriously write Microsoft for a refund, they aren't doing what they agreed to do in a contract. Telling you to do *anything* to fix a product that is flawed because they did something wrong is just ridiculous. If a car has a screw that becomes loose after 10,000 miles and could potentially let the engine drop out, regardless of how rare it might happen, every car will be recalled and the screw will be tightened and the car given back. Do you really think that a car company would tell its customers to tighten the screw? Why should microsoft tell its customers to fix something? That shouldn't be expected. I'm not saying that you have to go the free road with open source, I'm saying that I wouldn't trust my company with Microsoft and like an above poster stated, go with Java. If you don't need support then java and/or php will work fine. If you do need support, at least I know SUN won't jerk me around like the MS crap.
The vulnerability does not exist in OWA. The vulnerability requires that the web.config file in a subfolder enforces different permissions than those in a root folder.
you did read the pages i linked didnt you. cause if you did you would notice a similar vulnerability on there that has not been fixed.