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.
There's no patch yet, but in the meantime Microsoft is telling ASP.NET developers they can rewrite their applications to prevent exploits.
.NET in all our websites. C-c-canon-ical-ization is what they are calling it."
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!
The dangers of knowledge trigger emotional distress in human beings.
Oh, yeah. Companies now have to "rewrite their applications to prevent exploits" because of a security flaw in Microsoft's software? Would not it be simpler and easier for Microsoft's customers for Microsoft to fix the flaw? Hey, if I wanted to keep my customers happy, that is the course of action I would suggest. Look, you have 2.9 Million web sites out there that now have to go through and invest a number of hours or work to fix the problem. Let's say the fix is easy and only requires say, three hours to recode and test......that is how many hours of lost productivity to the world's GDP? 8.7 Million hours of lost productivity!
Visit Jonesblog and say hello.
From what I read on it on Bugtraq it appears to be one of the good old directory transversal flaws. E.G. if you don't have access to http://server/directory/file.asp you can simply go to http://server/directory\file.asp to access it. That or else use some unicode equivalent. Isn't it funny how Microsoft's leading edge Trustworthy Computing is still vulnerable to the same old sploits?
Ah, that's easy then. Do they have a suggestion for which web app platform and OS I should rewrite my apps for?
One line blog. I hear that they're called Twitters now.
They don't have to worry. All the people with black hats will rewrite the code for them... Free of charge!
Try to hack my 31337 firewall!
In *any* server-side scripting language, you should doublecheck each string you get from an URL, POST, etc.
I guess when it is assumed that your OS is full of security holes, you can issue a press release that more or less just says, "Our security is sh*tty right now", expect everyone to just do a collective, "Yup", and shuffle off.
Asp.NOT or asp.Nyet!
"If a visitor to an ASP.NET site substitutes '\' or '%5C' for the '/' character in the URL, they may be able to bypass password login screens. The technique may also work if a space is subsituted for the slash." Is it just me, or is this a bit too simple even for script kiddiz?
...why people refuse to use PHP. How far are you going to trust Microsoft to get it right? How many vulnerabilities does it take?
Anyone that's familiar with .Net has probably never used this technique to secure a page on their site.
I believe most people would consider it more secure to set up a virtual folder within your web site and protect the pages within that virtual folder with either Basic or Windows Integrated Authentication.
I've never used the web.config file technique to attempt to secure pages that really needed to be secure, and I doubt many other people have either. If you did without taking any other security steps, well... time to re-think that situation.
This security vulnerability will prove to be a dud; nothing along the lines of the old ::$DATA exploits and what-not.
I'm a big tall mofo.
>Put the burden of fixing the problem on the end-users.
Seriously, isn't this the way OpenSource works, since we are all the end-users?
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
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.Let's all go to http://www.billgates.com/files\private\How Can I Repackage the Same Old Shit in a New Wrapper.doc
No more [registration required] articles on ASP.net servers!
it was a plot by the guys at Microsoft to gain backdoor access to porn sites. Think about it, develop a system for "secure logins" on the internet (whose business HAPPENS to be composed of 70% porn, 30% other) with a bug that lets you bypass the very login that was supposed to be secure? Riiiight. See business plan below.
Step 1: Develop language for use with "secure login"
Step 2: ???
Step 3: Masturbate!
When installing Exchange 2003, a prerequisite is to install asp.net -- so I'm assuming that OWA for Exchange 2003 uses asp.net.
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.
Unfortunately, the few lines required to implement the patch has already been copyrighted by Brian Connolly.
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
Today an issue was discovered with Mozilla Firefox which, in the rare case a .config file was used to manage the security and permissions of a folder on a web server, a specially crafted URL could access the contents of the folder. Users are recommened to apply a small code patch to fix the issue.
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.
Tech, life, family, faith: Give me a visit
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.
It's not just asp.NET that's affected by bad programming. We use proper computers on our Intranet, not these silly Windows toys. Doesn't mean we're immune to the effects of sloppiness, though. The other day I found an application written by a subordinate of mine, where you could defeat an authentication check by setting a variable in a query string. You could say it's my fault really, for leaving register_globals on; but I find that 90% of the time it's a PITA having it off -- you might just as well be using something old-fashioned like perl if you're going to do that. When you have to read your variables "by hand" you can be sure what order you do 'em in. Sessions - who needs 'em? Just store a filename in a cookie and put the variables in the file, that's exactly how ASP and PHP do it! (Wonders: does having learned to do something the "hard way" first make you less likely to foul up when you come to do the same kind of thing a slightly easier way?) If you're going to be living in a house, you want housey stuff like electricity and plumbing, otherwise you may as well be living in a bender ..... if I'm going to be using PHP, I want PHP-like stuff otherwise it may as well be perl, but with far too many unnecessary round brackets {I grew up on British BASIC dialects which were similarly unfussy; SIN theta was as good as SIN (theta) but it saved you two whole precious bytes}.
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.
Je fume. Tu fumes. Nous fûmes!
IIS6 is not vulnerable to this. IIS5 is vulnerable but there are security tools that should be running on IIS5 servers (URLScan and IISLockdown) that will block this attack.
.NET's built-in security checks since those are apparently based on the string path and there is always another way to fake a string (server phishing?). I posted a little piece of code here that shows how I check authentication/authorization at the page/function/control level.
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).
The truth doesn't care what I think.
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.
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
/usr/bin/grep -i -E meaning life.txt
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.
ASP != ASP.NET
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.
I tested the 5 sites I've used this feature on over the last couple of years. Out of those 5 sites, only one proved to be vulnerable. I didn't take the time to find any pattern. None was obvious.
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.
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."
Microsoft actively encourages use of backslashes in URL's in their Web publishing software. This is done so that it is more difficult to move a web site to a non-Windows server, and also to break older non-IE browsers by making them fail to correctly parse relative URL names.
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.
SDK Download
Have you ever been to a turkish prison?