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.

Comments

What's new?

[Anonymous Coward]

In *any* server-side scripting language, you should doublecheck each string you get from an URL, POST, etc.

Re:Lost productivity

[wankledot]

Re-writing can happen today, the patch might not. I think it's pretty obvious that the best way to prevent it is to re-write your apps, maybe while you're in there re-writing them you can choose a better platform :)

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.

I still don't get...

[halivar]

...why people refuse to use PHP. How far are you going to trust Microsoft to get it right? How many vulnerabilities does it take?

Re:I still don't get...

[FortKnox]

Absolutely, I mean, PHP in a large enterprise system? WHY NOT! Scales great, right?

Honestly, saying "why don't people use J2EE?" would have been a bit more plausible... but good luck convincing a large financial institution to use PHP on their giant web apps.

Re:How Dogbert would handle this

[Gentoo Fan]

It sounds better to yell "rewrite!" for the knee-jerk Slashbots rather than "five line patch!"

Re:Lost productivity

[athakur999]

What makes you think MS isn't going to issue a fix for this? Everyone seems to be overlooking this part of that sentence:

There's no patch yet, but in the meantime Microsoft is telling ASP.NET developers they can rewrite their applications to prevent exploits.

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.

Re:How Dogbert would handle this

[Saeed al-Sahaf]

There's no patch yet, but in the meantime Microsoft is telling ASP.NET developers they can rewrite their applications to prevent exploits.

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.

Re:How Dogbert would handle this

[hruntrung]

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."

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 .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.

Except for

[plopez]

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.

Too much blame on MS

[0x0d0a]

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.

That is not the issue

[spideyct]

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.

Re:How Dogbert would handle this

[deadlinegrunt]

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.

Re:How Dogbert would handle this

[coolgeek]

I believe the difference is the PHP leaks have been resolved.

Re:How about this?

[UfoZ]

Did you even look at what you're linking?

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:

if(isset($show)){

if($show == "new" || $show == "pop" || $show == "cool"){

include("include/show.php");
} else {

include("include/$show.php");
}
}

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.

Re:How Dogbert would handle this

[Crashman_pnc]

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.

The war on the web server front

[WebCowboy]

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.

Re:The war on the web server front

[AJWM]

there's a great deal of irrational hatred of Microsoft among technically inclined individuals,

Really? Technically inclined individuals tend to look at things with a logical, rational approach. Most non-technically inclined individuals tend not to understand the technically inclined.

Therefore, it's more likely that technically inclined individuals have a rational hatred of Microsoft, but most people are lacking sufficient clue to understand why.

As for crackers and script kiddies, yeah, there's something irrational about their thought processes (if any).

Re:How Dogbert would handle this

[jafomatic]

This sounds more like the product of 3 lines of code and 2.9 million updates, so let's not jump on the "Microsoft not so BAD" bandwagon either.

Maybe we should stay away from bandwagons entirely? :)

Re:'Just a patch' is something of a misnomer Reall

[Nom du Keyboard]

Why do I write in ASP.NET? It is FAST

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?

Re:How Dogbert would handle this

[Anonymous Coward]

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.

Re:How Dogbert would handle this

[Knightmare]

Yep.... sure is a huge fix too, it would probably take days to retrofit your applications. Or just put the following code in Global.asax:

<script language="C#" runat="server">
void Application_BeginRequest(object source, EventArgs e) {
if (Request.Path.IndexOf('\\') >= 0 ||
System.IO.Path.GetFullPath(Request.PhysicalPath) != Request.PhysicalPath) {
throw new HttpException(404, "not found");
}
}
</script>

P.S. - I am not a microsoft supporter, I am a security guy by profession, and they have caused numerous headaches for me. But this doomsday talk is just silly. Do we need to stop and enumerate the vulns that have been seen in open source alternatives? How about back when php didn't make you distinguish between user variables and server side variables, ya that was secure. And if you tried to look up info on any of the frameworks that are within light years of asp.net (good luck finding them) you would find vulns in them as well. ASP.NET so far has fared really well, do I think this is an amature mistake to miss, yes, do I think it's as dramatic as you make it out to be, no.

Re:How Dogbert would handle this

[badriram]

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.