Microsoft Issues Ominous ASP.Net Security Warning 554
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.
How Dogbert would handle this (Score:5, Funny)
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?
Dilbert: "Microsoft says we need to pull 20 programmers away from their current workloads to focus on fixing ASP
Dogbert: "How long is this going to take? And who is making these words up anyway?"
Dilbert: "Two weeks." (I mean that's the standard response right?)
Dogbert: "Let's give all our programmers a holiday, effective yesterday. Shut the sites down in twenty minutes after I call our contact in Belize. It's time for EULA loophole #27. {{WAG!}}"
So do the math. And tell me, please, all ye Microsoft supporters, why Open Source lowers my ROI again!
Re:How Dogbert would handle this (Score:5, Funny)
My first thought was, "yes, rewrite them in perl or PHP".
Re:How Dogbert would handle this (Score:5, Informative)
Re:How Dogbert would handle this (Score:5, Insightful)
Re:How Dogbert would handle this (Score:5, Insightful)
Re:How Dogbert would handle this (Score:4, Informative)
Re:How Dogbert would handle this (Score:5, Insightful)
Re:How Dogbert would handle this (Score:5, Informative)
You seem to have a rather short memory. 3 years ago, Ford execs knew that the tires they equipped all their Explorer SUVs was defective and could explode when too hot on a highway, effectively killing all its occupants. Lots and lots of emails proved it. Firestone execs knew was well. A lot of people died. Yet, it had to go public through a third-party (a private investigation by a journalist IIRC). Then, they recalled.
In that regard, we can safely say that Microsoft is more fair play than Ford is. And no,I don't think Ford is any exception.
Re:How Dogbert would handle this (Score:3, Funny)
Asp.net is free (Score:5, Informative)
SDK Download [microsoft.com]
Re:How Dogbert would handle this (Score:3, Informative)
Re:How Dogbert would handle this (Score:5, Insightful)
Maybe we should stay away from bandwagons entirely? :)
Re:How Dogbert would handle this (Score:3, Informative)
For those who are interested, the fix is here:
http://support.microsoft.com/?kbid=887459
For those about to rock, we salute you.
Re:How Dogbert would handle this (Score:5, Informative)
Re:How Dogbert would handle this (Score:5, Insightful)
Re:How Dogbert would handle this (Score:5, Insightful)
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
Re:How Dogbert would handle this (Score:5, Interesting)
Re:How Dogbert would handle this (Score:5, Insightful)
"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 (Score:5, Insightful)
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.
Re:How Dogbert would handle this (Score:3, Insightful)
I agree with your assessment of the "5 line patch/ass biting" part, but I wouldn't let something like this diminish your confidence in their product; this really is a normal BAU type of bug.
Now, if you'd rather their business practices and attempts to take open standards, close-source them, and try to use their monopolies to cram them down your thr
Re:How Dogbert would handle this (Score:5, Funny)
Re:How Dogbert would handle this (Furthermore...) (Score:5, Funny)
Re:How Dogbert would handle this (Score:3, Interesting)
If you don't do any funny things with Global.asax.
Plus testing. Plus deployment.
3 hours
Times all affected sites.
A patch would take less time, surely.
Of course, it's nice to have a workaround when you don't have a patch, anyway.
Using a java application server could take much longer, but it should pay in the end:)
Re: How Dogbert would handle this (Score:5, Funny)
> While I think the flaw itself is a concern the 'rewrite their applications' quote is pure drivel. All thats required is a couple of lines in Global.asax. Thats hadly a rewrite.
Since it's trivial, can I expect Microsoft to send someone by to do it for us?
'Just a patch' is something of a misnomer (Score:5, Informative)
OK, I am an independant programmer that writes most of my code in ASP.NET. I'll give a taste of what this does to people like me.
Remember, there are actually TWO vunerabilities that affect programmers in Microsoft right now - the GDI+ JPEG overflow and the new canonicalization overflow. Microsoft has fixed neither effectively, so the coders have to fix both.
I manage eleven ASP.NET sites and five C# Windows Forms applications. Between those sixteen apps, I need to:
- load them up in Visual Studio
- Go back to the last stable build in SourceSafe
- fix the reference to GDI+
- add the mappath check to the Global.asax file
- munge the global error handler so I don't get 12,434 error emails when the hacks start coming
- compile
- regression test the app
- redeploy
Now, admittedly, that only took about 20 hours for all 16 apps, but for CRYING OUT LOUD can't they just test this stuff BEFORE they send it out? I have the highest respect for the ASP.NET team, I have worked with many of them on the many books I have written on the topic. Nonetheless, I now have to spend 12 precious, non-billable hours on a problem that is covered at length in 'the bible' - Howard and LeBlanc's Writing Secure Code 2.
Why do I write in ASP.NET? It is FAST - much much much faster than Java or perl or CF any other middleware out there. It is perfect for what I do. But how many of these are there? How many security flaws that the black hats know about that we don't?
It's a little frustrating.
S
Re:'Just a patch' is something of a misnomer Reall (Score:5, Insightful)
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:'Just a patch' is something of a misnomer (Score:3, Insightful)
Note that he said unbillable hours. If you're not getting paid for it, it's not much of a job, is it?
Re:'Just a patch' is something of a misnomer (Score:3, Informative)
Re:'Just a patch' is something of a misnomer (Score:3, Funny)
I used to do tech support for a local Wendy's franchise. You think that guy was bitching? You should hear the burger flippers bitching about thier headsets. And in their case, it was usually their fault, not the equipment's fault.
Re:How Dogbert would handle this (Score:5, Insightful)
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 (Score:3, Insightful)
Seriously, what kind of nonsensical idea is it for programmers to rewrite their programs to work around a security hole in the **compiler**??!! That's just ridiculous. Microsoft needs to have the patch out front & center right now.
Too much blame on MS (Score:5, Insightful)
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.
Granted (Score:4, Insightful)
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.
Re:Too much blame on MS (Score:4, Insightful)
Water can kill you, so can a hand grenade. Therefore water is just as dangerous as hand grenades.
F/OSS can be compromised, proprietary software can be compromised...
The problem is that if you look with even mild interest into the issue, you'll see major differences.
Such as:
1. Due to the inherent properties of proprietary software, you install today's system with the exact same disk you used 2 years ago. That means a default install today has all the flaws that have been uncovered since the disc went gold. With F/OSS, you are far more likely to have an up-to-date install CD.
2. Update mechanisms for Linux are used far more extensively than for Windows. One of the primary reasons for this is that the goal of F/OSS is to be used, the goal of proprietary software is to make money. For this reason, it's far more likely that a Windows update will come with unacceptable issues than a Linux update.
3. The design philosophy with regards to security between Linux and Windows is night-and-day. Linux tends to disable services unless you specifically enable them, and even then the default options tend to be chosen with security in mind. With Windows (since '95!) you have ports open by default that have been used to crack into the system. With XP, these ports can lead to a compromised system before the install has even finished!
And the list goes on...
The war on the web server front (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:3, Funny)
Dogbert: "With so many companies using ASP .NET, it's unlikely that we will be singled out for attack. Besides, if our admins aren't fighting fires, how do we know that they are doing a good job or not?"
Re:How Dogbert would handle this (Score:5, Insightful)
Re:How Dogbert would handle this (Score:3, Insightful)
Re:How Dogbert would handle this (Score:4, Insightful)
Lost productivity (Score:4, Interesting)
Re:Lost productivity (Score:5, Insightful)
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.
Except for (Score:5, Insightful)
Re:Lost productivity (Score:4, Insightful)
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.
Re:Lost productivity (Score:5, Insightful)
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:Lost productivity (Score:3, Insightful)
It'll be fixed in Longhorn.
Re:Lost productivity (Score:5, Interesting)
However, I'm not reassured by MS's explaination.
I quote:
Microsoft ASP.NET developers can add more checks to help reduce canonicalization issues for a Web application by adding an Application_BeginRequest event handler in their Global.asax file that is stored in the root directory of the Web application. This event handler executes for each Web request and is a convenient location to insert code to help safeguard against canonicalization issues.
The following samples demonstrate how to add an Application_BeginRequest event handler to a Global.asax file. The event handler helps protect against invalid characters and malformed URLs by performing path verifications to help protect against common canonicalization issues.
---
Help is not the same as fix. If these was the only item needed to fix the issue, I'd highly expect different language in giving a work around.
Given MS's past track record, I suspect we'll find this fixes the most obvious part of the problem while still leaving the user vulnerable, but feeling warm and fuzzy in the assurance that the problem is fixed.
Cheers,
Greg
Same old, same old. (Score:5, Interesting)
Here's the link to the BugTraq Article (Score:3, Informative)
http://www.ntbugtraq.com/default.asp?pid=36&sid=1& A2=ind0409&L=ntbugtraq&F=P&S=&P=98 84 [ntbugtraq.com]
Re:Time to go egging... (Score:5, Funny)
How simple! (Score:5, Funny)
Ah, that's easy then. Do they have a suggestion for which web app platform and OS I should rewrite my apps for?
Rewrite the code! (Score:5, Funny)
What's new? (Score:4, Insightful)
Re:What's new? (Score:5, Interesting)
From the article, it looks like it's simply switching a '/' to a '\' or the unicode equivalent in the URL to an asp page. It seems like you (the developer) would never get a chance to doublecheck this url as this would seem like it's parsed by IIS and has nothing to do with your script at all.
Again, I'm NOT a ASP.NET dev. but I do do web programming, and it seems that checking your GET/POST vars wouldn't do it.
Can anyone clarifying this further?
That is not the issue (Score:5, Insightful)
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.
Details... (Score:5, Funny)
Obligatory (Score:4, Funny)
This is getting tiresome. (Score:5, Informative)
Re:This is getting tiresome. (Score:3, Informative)
This is a stupid exploit that should have been caught before 1.0 was released, but the affected install base is probably very small.
I still don't get... (Score:5, Insightful)
Re:I still don't get... (Score:5, Informative)
Re:I still don't get... (Score:3, Insightful)
Re:I still don't get... (Score:4, Informative)
Re:I still don't get... (Score:3, Insightful)
(Speaking as an ASP coder. Complex monopolies in action, guys...)
Re:I still don't get... (Score:5, Insightful)
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:I still don't get... (Score:5, Informative)
It's too bad it doesn't scale: once they get 10 billion hits a day they'll probably have to rewrite and switch to
but good luck convincing a large financial institution to use PHP on their giant web apps.
The only problem here is reputation. Microsoft pushes
There's no reason PHP can't be used to write "enterprise" applications from a technical standpoint. I think the problem comes from the fact that generally schools teach Java, because it was hip during dot com, and
I'd really like to hear the reason you don't think PHP is scalable, or why you don't think it's suited (a technial reason, not by reputation), but to be honest, I don't think you'll be able to give me one because by the way you talk, my guess is the only thing you know about PHP is what you've heard from other people and/or companies who sell a product that competes.
PHP runs on basically every platform (instant cost savings vs
I use PHP for lots of my stuff, and it saves me money and allows me to do things a lot faster than if I was using another language. I don't care if you agree or not, because it doesn't really affect me in the end. It's a competitive advantage for my company - I don't have the overhead of paying extra thousands of dollars per sever for licences, for one thing.
Re:I still don't get... (Score:3, Insightful)
>html:text name="myForm" property="someProperty" length="12"
So it looks like a text box (the name, and property are struts specific)
Tapestry is even trickier. It uses things like <span> tags, which don't "show up" on your page, but exists in the html. So your code can actually double as a prototype. All the code lies back in java files and xml's point the java file to the appropriate jsp/html file.
So, yes, its
some banks do... (Score:3, Interesting)
How about this? (Score:4, Informative)
Re:How about this? (Score:4, Insightful)
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.
Re:How about this? (Score:3, Informative)
Granted there have been PHP issues, but this is not one of them.
Re:I still don't get... (Score:4, Interesting)
>
> going to trust Microsoft to get it right?
> How many vulnerabilities does it take?
Maybe you could help me with this one. I've never figured out how one could make a secure PHP program on a multi-user system. All PHP scripts run using the web server's perms, not the programmer's. Which means all data files must be writable and all SQL passwords must be readable by the web server. Which means other people's PHP scripts on the same server also have permission to write to those files or read those passwords.
[blink] [blink]
What am I missing? As far as I can see, there's zero inter-user security when using PHP. CGI scripts on the other hand get to take advantage of suEXEC which allows them to run under the programmer's perms instead of the web server's. But PHP is left out.
Re:I still don't get... (Score:5, Informative)
Build PHP as a CGI, and print #!/path/to/php at the top of every php file. (Like you do with Perl)
Now wrap it with suExec and you're all set.
Observe the *slight* performance hit.
or include:
<Location
php_admin_value open_basedir "/home/username/public_html:/usr/local/lib/php/:/
</Location>
into each VirtualHost on your PHP server and it will not allow any file operations to take place outside of the listed directories.
On some sites you may need to add a few other dirs to the open_basedir for whatever you're trying to accomplish.
eg: I shell out to ImageMagick's "convert" a lot, so I add it's path to the open_basedir for that particular VirtualHost.
Don't panic just yet (Score:5, Interesting)
Bulls$%^!!! (Score:5, Interesting)
In typical anti-MS slashdotter bullshit, the use of the word "re-write" is used quite liberally. A grand total of four lines of code are required per application so no matter how bog the web site is, only four lines of code (typed once in a single source code file) take care of the problem:
By the way, these 4 lines of code can be made into one line of code... Hardly an application re-write.The two faces (Score:5, Interesting)
about face
Today, yet another huge security hole was found in Microsoft software in which blows open all websites running ASP.NET. Microsoft's response? Re-write your code to fix the problem! Just another example of Microsoft's "blame the victim" mentality, when oh when will the madness end?!! We should all switch to Linux and Mozilla and Apache today because those apps never have bugs.
Your example doesn't make sense (Score:3, Insightful)
Re:Bulls$%^!!! (Score:3, Insightful)
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 differ
Still a problem! (Score:3, Insightful)
Actually, those 4 lines do not fix the problem, they help.
Look here for a good explanation. [slashdot.org]
Re:Bulls$%^!!! (Score:3, Informative)
But this just checks the presence of the one known overlooked character, and performs one 'smell-test' check on the path. What about unicode variations? What about dot-dot variations? How often will this need to be tweaked before a patch comes out?
I agree, it's no re-write...it's a PITA production workaround.
Where do you want to get carjacked today? (Score:3, Funny)
Amazing Immunity (Score:3, Interesting)
Finally! (Score:5, Funny)
This isn't a bug really (Score:5, Funny)
Step 1: Develop language for use with "secure login"
Step 2: ???
Step 3: Masturbate!
OWA? (Score:5, Interesting)
Can anyone confirm this vulnerability in OWA? If it is a problem, is there anything for an administrator to do? I am not a programmer/developer - the MS links didn't seem to have any helpful preventive info.
Re:OWA? (Score:3, Insightful)
Re:OWA? (Score:3, Insightful)
At least this is how I remember it working, someone please correct me if I am wrong.
My favorite... (Score:4, Interesting)
It ain't just asp.NET (Score:5, Interesting)
I'll be having a word with him about it when he gets back. I distinctly remember telling him to be careful where certain variables came from. I haven't checked his code too closely yet, because I've had other things to deal with; but if I find $auth=$_SESSION["auth"] commented out, I just might have to kill him.
For the record, the fix is pretty low impact. (Score:3, Informative)
Saying that they need to "rewrite their applications" is incredibly misleading.
It's nost *just* the coding required... (Score:3, Insightful)
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.
Word mangled by unpatched security hole (Score:3, Informative)
Defense in Depth (Score:5, Interesting)
Unfortunately, it appears that many (most? all?) shared hosting providers are not running IISLockdown nor URLScan because all of the hosted sites of mine that I tested were vulnerable (except for the ones hosted on Win2k3). So, for those of us doing the shared hosted thing, we needed a fix.
Defense in depth is always a good practice but ASP.NET's directory security was just so dang easy that many of us used it and didn't do security checks on the individual pages and functions like we should have. I admit I am/was guilty of that about 50% of the time (estimated Frida based on the work I did to correct every ASP.NET site I've ever done). I have code in each page now that checks authentication instead of relying on
Microsoft's suggested workaround is easier because you put the 3 lines of code in 1 place, but after this security scare, I don't think I will ever rely on ASP.NET directory security (nor should I have ever relied on it).
Total impact for 5 sites: 15 minutes (so far) (Score:5, Interesting)
The test took about 10 minutes. Then I applied the work-around from MS, and uploaded that to the server. That took about a minute. Then I tested the site in question, ensured that the hole was closed and the site still functioned correctly. The site isn't too complicated, so that took less than 5 minutes.
So the total impact to me so far was less than the time spent reading the replies to this post on slashdot!
That said, I agree that an open source solution where a patch could be released right away would have been much better.
Microsoft's attacks on Unix/Linux caused this (Score:5, Interesting)
If they had written this correctly, IIS would, at a very low level, have checked any URL and translated it to a legal Windows filename. This would mean turning any backslash into some other escape sequence before using it to identify the file in the file system (forward slashes could be left alone). This would have been trivial and in fact most original 3rd-party software for serving web pages from Windows did this. This would have immediately stopped the exploit of putting '\' or %5c into the URL.
IIS certainly checks and cooks the URL in many other ways before producing the filename, so lazyness is not an excuse. It is pretty obvious that they wanted to intentionally allow URL's on the web that were non standard and would not work correctly on Unix servers.
Re:This is the American corporate way: (Score:5, Interesting)
Seriously, isn't this the way OpenSource works, since we are all the end-users?
Re:This is the American corporate way: (Score:3, Interesting)
Seriously, isn't this the way OpenSource works, since we are all the end-users?
Your comparison is flawed.
In Open Source software, the burden is on the programmers, it's just that any end user has both the right, and are provided with the means, to become a programmer. With Proprietary Software, the burden is quite often put on the end user who is provided with limited or inequitable means to do so.
Re:just rewrite (Score:3, Informative)
Re:heh (Score:4, Informative)
Re:Time to rewrite alright... (Score:4, Informative)
They are *completely* different languages/technology. Perhaps you should spend more time actually learning than bashing stuff you have no clue about.
PS: How did this get modded up, when it was an obviosu flame? Oh right. It's Slashdot.