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.
http://www.pr0nsite.com/loggedin.asp&sneaky&url&ba ckdoor
~S
This is the American corporate way: blame the victims!
Put the burden of fixing the problem on the end-users...
In *any* server-side scripting language, you should doublecheck each string you get from an URL, POST, etc.
Microsoft says we need to pull 20 programmers away from their current workloads to focus on fixing ASP .NET in all our websites.
No, they say you have to copy/paste a few lines of code into your primary web assembly. That's one programmer for a few hours if you take into account testing and deployment.
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!"
What about Red HAt, SuSe and others who may distribute Open Source program while being accountable according to your definition ?
Trolling using another account since 2005.
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
Whatever else it is, like maybe a silly joke, possibly insightful, it is not offtopic.
Put identity in the browser.
What amazes me is that so many people still fail to recommend to their customers alternatives to IE and IIS. Are they just too lazy to learn about the alternatives, or do they really think these products are safe to use in mission critical environments?
I know it takes an investment of time to learn to implement viable alternatives, but if you're worth your salt in this business, shouldn't you at least know how to use products from more than one vendor?
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
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.
From the article : "c:\dir\test.dat, test.dat, and ..\..\test.dat might all refer to the same file."
Now I could understand how c:\dir\test.dat and test.dat might be the same file - but, prey, assuming a hierarchical file system, how can all three be identical given that Windows file systems don't support hard-links? The test.dat is the same as the c:\dir\test.dat file if we are in c:\dir - but then the parent of the parent could not be c:\dir as well.
Tell that to the Enron shareholders!
Wow! Are you describing the Bush Administration? No matter how much they fuck up or fuck us all over, nothing sticks to them!
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+
Your professor is an idealistic, ivory tower academic. Remember "Those who can't, teach". That tends to be true. The reality is that their software has a level of complexity that is relatively unmatched in computing. Add together the amount of things that their software does, for the amount of people, on all different kinds of hardware, and you have an insanely complex application/platform. Compare against, say, Oracle, which writes software that does very specific things, not for end users, and is optimized for only certain hardware and platforms. Even Oracle's stuff isn't bug free, or close to it.
I don't respond to AC's.
Can anyone confirm this vulnerability in OWA?
No, I haven't managed to exploit it. But I've only thrown a couple of minutes at it.
The mailbox pages probably store your credentials somewhere in their state so simply bypassing the login page won't be enough.
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
...if this flaw was discovered in JSP, PHP or Perl, would we see the same degree of venom? ;-) ./ has some really smart readers. Too bad there's so much platform religion. It's all the same crap in different packages. ASP.Net, JSP, PHP and Perl all suck and shine, differently but equally.
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
Having read the bug description, cause of the bug, and solution to the bug, I have the definiteve response. On one side, you have the idiots saying 'OHMYGODYOUHAVETOREWRITEAEVERYTHING!'. ON the other side, you have the idiots saying 'This is nothing'.
1) The problem isn't incredibly awful in and of itself. Fixes would take roughly two minutes and could actually be automated. Simple as that
2) The problem is indicitive of Microsoft's biggest problem. Security. This is not an unknown issue. I check my code for similar issues. It is the most fundamental thing abou security: Check the damn inputs. They should have white papers (they do actually) on this. They have trained every employee on this (they took a few weeks off just to schedule clases on this and other security issues). It is a very basic problem. Yet it recurs too often.
Granted -- it is easier to say than do. The people who say a bug like this should NEVER happen have never coded in a real work environment. Things do slip through the cracks. But it happens to Microsoft too often (admittedly less than five years ago, but still too often).
Bottom line. It ain't the end of the world. But it is indicative of a deep cultural problem that Microsoft has to overcome before someone overcomes Microsoft.
Sincerely,
AC
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.
The linked MS article has a reference to a very well written security guideline, just as many home router/gateway manufacturers have documentation in their user manuals about WEP/WAP. If a businessman/woman or grandma/pa is expected to RTFM about their home network, I suggest programmers and web designers have at least an equal responsibility to follow manufacturer's security-related advice.
I'm not totally clueless. I realize this is /. and the article is the obligatory, daily, "let's bash MS" post.
No man's an island, unless he's had too much to drink and wets the bed.
Actually, those 4 lines do not fix the problem, they help.
Look here for a good explanation.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
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.
It's their new security feature: Security through Stupidity.
One line blog. I hear that they're called Twitters now.
Firefox is a browser. If a web server is allowing access to a file on the server that it shouldn't, then that's isn't a bug in Firefox - it's a bug in the web server. Any server that is dependant on the client playing nice in order to get proper security (like most online games) is broken by design.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
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."
And, frankly, it's a welcomed change from the usual positive Microsoft bias common to so much of the press-release-as-a-news-story industry media.
So instead of the glossy MS corporate spin you welcome fanatical, bash-MS-no-matter-what spin?
I'm sure "SlashdotMedia" will improve on all the wonders that Dice Holdings blessed us all with
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.
I'm no fan of Microsoft, but as a software developer who has worked with overloaded QA folk, it doesn't surprise me that bugs like this slip through the cracks.
;)
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 throat to extend into further monopolies guide your judgement about their products, then I'd say you're on the right track.
Diplomacy is the art of saying, "Nice doggie!" until you can find a rock.
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.
Hi...
Microsoft didn't say they would "never fix it". They said that a patch isn't yet available and here is a workaround (like that's never happened in F/OSS before...) until a patch is ready. In any case, it isn't rewriting your whole application and the fix is pretty easy and even after a patch is provided, the "work around code" will still work fine and have correct behavior.
Geesh... some folks will jump onto any bandwagon that comes down the street.
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.
I'm not Microsoft so I can't say there is no problem for OWA but the whole idea behind OWA is that it uses the user's kerberos ticket and is "trusted for delegation" and contacts exchange with that kerberos ticket to retrieve the mailbox requested. Just "exploiting" the pathing problem won't give you access to anything within exchange.
At least this is how I remember it working, someone please correct me if I am wrong.
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.
...2 weeks of QA testing and deployment in production.
Maybe its not a big deal to some of you kids who think you can code a patch and have it in production that day because MS said so.
To the rest of us, you have to test the thing thoughly because the business's revenue comes through that site.
There is a patch coming, but it's not available yet.
It'll be fixed in Longhorn.
-- Alastair
If you are to compare products, why don't you compare the latest versions of both?
The difference is that the exercise machine was 'some assembly required' and the car is not. So, given that ASP is some assembly required, it might be reasonable for MS to push the fix to the code monkeys.
The hitch might be that MS does have responsibilty to put the fix in kit form. I was not required to buy the wire and hooks, cut and crimp, and then test. It was all there. MS may or not be provided the proper level of kit.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black