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.

How Dogbert would handle this

[mfh]

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?

Dilbert: "Microsoft says we need to pull 20 programmers away from their current workloads to focus on fixing ASP .NET in all our websites. C-c-canon-ical-ization [reference.com] is what they are calling it."

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

[nizo]

Microsoft is telling ASP.NET developers they can rewrite their applications to prevent exploits.

My first thought was, "yes, rewrite them in perl or PHP".

Re:How Dogbert would handle this

[badriram]

Comparing PHP 4.3.x [secunia.com]series to ASP.NET [secunia.com] (both 1 and 1.1) at secunia. It seems to me that the vulnerabilities are 10 to 3. If you were recommending a product, at least do some research before you do.

Re:How Dogbert would handle this

[coolgeek]

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

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.

Re:How Dogbert would handle this

[pc486]

Really? [php.net]

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

[Pieroxy]

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 scre will be tightened and the car given back

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

[FyRE666]

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?

Cue: Dialogue from "Fight Club"

Narrator: A new car built by my company leaves somewhere traveling at 60 mph. The rear differential locks up. The car crashes and burns with everyone trapped insi

Asp.net is free

[ad0gg]

Uh.. Asp.net is free, they don't charge for it. Download the free SDK. No where does microsoft charge for asp.net.

SDK Download [microsoft.com]

Re:How Dogbert would handle this

[Anarchofascist]

Problems with PHP, as with almost all security issues in all software, can be fixed with a patch to the execution environment. The difference here is that the reccomended fix is to patch everybody else's code.

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:How Dogbert would handle this

[jsin]

This was much easier to fix than the GRUB/Fedora Core 2 multiboot bug...

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

[Timesprout]

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.

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

Re:How Dogbert would handle this

[Gentoo Fan]

I'm not defending Microsoft, I'm simply saying that the actual fix for the problem isn't what the Slashdot write-up implies ("rewrite their applications"). Adding a few lines in Global.asx is NOT a "rewrite".

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

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

Re:How Dogbert would handle this

[Not_Wiggins]

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 thr

Re:How Dogbert would handle this

[ThePatrioticFuck]

"All thats required is a couple of lines in Global.asax. Thats hadly a rewrite."

No no no, I'm afraid we can't allow that. This is a MS bashing story, you can only submit such insightful and logical suggestions on *Nix flaw stories :)

Re:How Dogbert would handle this (Furthermore...)

[Ingolfke]

Unfortunately, the few lines required to implement the patch has already been copyrighted by Brian Connolly [slashdot.org].

Re:How Dogbert would handle this

[orasio]

A couple lines in Global.asax.
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

[Black Parrot]

> 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

[sempf]

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

[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:'Just a patch' is something of a misnomer

[AndroidCat]

Isn't that part of your job description?

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

[sempf]

Not when they are my problems. But for a broken product? You bet! I whine like crazy!

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

[KilobyteKnight]

you know if software development is too frustrating for you, you can give a shot at flipping burgers at mcdonalds. You sound like an engineer who whines about having to do fixing and testing. Isn't that part of your job description?

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

[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

[pbranes]

Netcraft confirms it - asp.net is dying. Thank you, thank you. I'll be here all week.

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

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

Granted

[mfh]

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.

Re:Too much blame on MS

[node 3]

*However*, this is not a Microsoft- or closed-source- specific problem. It could happen just as easily to, say, the perl community.

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

[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

[Spoing]

A slight re-write;

1. Dilbert: "Microsoft says we need to pull 20 programmers away from their current workloads to focus on fixing ASP .NET in all our websites. C-c-canon-ical-ization [reference.com] is what they are calling it."

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

[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

[Aumaden]

Tell that to the Enron shareholders!

Re:How Dogbert would handle this

[ceswiedler]

Clearly you don't have much experience with the sort of systems where absolutely nothing takes a 'few hours' of testing.

Lost productivity

[BWJones]

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!

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.

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.

Re:Lost productivity

[Jim_Maryland]

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.

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:Lost productivity

[AJWM]

There is a patch coming, but it's not available yet.

It'll be fixed in Longhorn.

Re:Lost productivity

[GSloop]

Perhaps this will fix things.

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.

[gregarican]

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?

Here's the link to the BugTraq Article

[xxxJonBoyxxx]

Here's the link to the September 14 BugTraq Article

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

[gregarican]

Let's all go to http://www.billgates.com/files\private\How Can I Repackage the Same Old Shit in a New Wrapper.doc

How simple!

[AndroidCat]

Microsoft is telling ASP.NET developers they can rewrite their applications to prevent exploits.

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!

[Mr. Flibble]

They don't have to worry. All the people with black hats will rewrite the code for them... Free of charge!

What's new?

[Anonymous Coward]

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

Re:What's new?

[Frag-A-Muffin]

Although I agree with you in general, I would have been more specific. You should always be checking your GET/POST vars.

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

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

Details...

[JoeLinux]

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.

Obligatory

[Anonymous Coward]

Asp.NOT or asp.Nyet!

This is getting tiresome.

[whyne]

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

Re:This is getting tiresome.

[tshak]

This is _only_ if you protect at the file level via the web.config (something that is not a best practice in the first place). If you use ASP.NET Forms Authentication and put a security check on an aspx itself (or in your base page class), or if you use any other form of authentication and authorization, this exploit is useless.

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

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

[Timesprout]

Right, because historically PHP has been an absolute bastion of security.

Re:I still don't get...

[Lehk228]

PHP is fine, the problem is that many PHP developers are new to web based programming and don't know how to write secure code.

Re:I still don't get...

[DAldredge]

It may have something to do with the fact that PHP changes too much between minor verions. Or at least it used to.

Re:I still don't get...

[GregWebb]

If you're building stuff to run your own systems, go for it. If you're building stuff to resell to corporate / government clients that they want to be able to install as a turnkey, _you_ try getting them to install PHP...

(Speaking as an ASP coder. Complex monopolies in action, guys...)

Re:I still don't get...

[FortKnox]

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

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

[gregmac]

Yeah. It's not like any large websites [com.com] use php. I was at a PHP conference about two weeks ago, where Rasmus Lerdorf (the lead developer, who happens to work at Yahoo now) was talking about their infrastructure. He didn't give an exact number, but said it was in the area of 10,000 servers (running FreeBSD), and handles literally billions of hits a day.

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 .NET or something.

but good luck convincing a large financial institution to use PHP on their giant web apps.

The only problem here is reputation. Microsoft pushes .NET as a large enterprise system, same thing with Sun and Java. No one really pushes PHP, besides people that use it.

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 .NET, because Microsoft gives them lots of free software when they do. When all your developers - espessially the lead developers and CIO's making language and platform decisions - are trained on a certain platform, that's what they'll choose.

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 .NET). It can connect to any major DBMS. It runs on a ton of web servers, most importantly Apache. It's lightweight, has probably the lowest learning curve of any language (read: your designers can use it), easily extensible with C, and it's open source (so you never have vendor lock-in, and you're never stuck with a problem that can't be solved).

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

[FortKnox]

Think of it like templates. A (struts) taglib will be something like so:

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

[mgkimsal2]

Funny you say that. I was recently working at a bank that was using PHP for all front end and middleware stuff. The 'bank' code itself (which calculated interest and all that jazz) was Oracle and thousands of stored procedures and triggers, but everything else was in PHP. A large contingent of PHP people left at the same time, however, so I'm not sure they'll stick with PHP long term, but that's a business/resource issue, not a technology issue. PHP can talk SOAP to external systems as well as .net or j

How about this?

[gregarican]

Here's a vulnerability or two right here [securityfocus.com]. Too bad they are in the revered PHP platform. Just to show that no one is immune.

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 about this?

[hackstraw]

The $show example is not PHP specific. That is just bad web programming, and that can be done in C, ASP, Perl, shell, or any language. If the web developer blindly uses user input unchecked to access a resource on the webserver, then that web developer made a mistake.

Granted there have been PHP issues, but this is not one of them.

Re:I still don't get...

[FTL]

> I still don't get...
> ...why people refuse to use PHP. How far are you
> 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...

[someonehasmyname]

Actually, it's very simple and can be handled a multitude of ways. Here's two examples:

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/:/t mp/:/var/tmp/"
</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

[bigtallmofo]

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.

Bulls$%^!!!

[PincheGab]

Microsoft is telling ASP.NET developers they can rewrite their applications to prevent exploits

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:

if (Request.Path.IndexOf('\\') >= 0 ||
System.IO.Path.GetFullPath(Request.PhysicalPath) != Request.PhysicalPath) {
throw new HttpException(404, "not found");
}

By the way, these 4 lines of code can be made into one line of code... Hardly an application re-write.

The two faces

[Swamii]

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.

Your example doesn't make sense

[DunbarTheInept]

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.

Re:Bulls$%^!!!

[huge colin]

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 differ

Still a problem!

[Spoing]

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

Actually, those 4 lines do not fix the problem, they help.

Look here for a good explanation. [slashdot.org]

Re:Bulls$%^!!!

[mborland]

By the way, these 4 lines of code can be made into one line of code... Hardly an application re-write.

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?

[Doc Ruby]

I wonder how many US government websites in Iraq and Washington are running these soft targets? This is the kind of thing that's forced all our Cybersecurity chiefs to resign in disgust [slashdot.org].

Amazing Immunity

[ryanw]

Microsoft has had so many bugs and security flaws over the years that companies are completely immune to bad press for Microsoft. I wonder how much more of this people will finally take until they switch to MacOSX / Linux. I would highly suggest the MacOSX route ....

Finally!

[Garabito]

No more [registration required] articles on ASP.net servers!

This isn't a bug really

[Jakhel]

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!

OWA?

[kcurtis]

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.

Re:OWA?

[erobillard]

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.

Re:OWA?

[Knightmare]

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.

My favorite...

[someonehasmyname]

That's pretty funny, but my favorite is still this one [insecure.org]

It ain't just asp.NET

[ajs318]

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.

For the record, the fix is pretty low impact.

[kevlar]

The fix is pretty low impact wrt webapps. Its merely a matter of adding an event handler to the Global.asax file. The vast majority of webapps do not even touch that file because its mostly auto-generated.

Saying that they need to "rewrite their applications" is incredibly misleading.

It's nost *just* the coding required...

[infinii]

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.

Word mangled by unpatched security hole

[AndroidCat]

It just gets better and better. [infoworld.com]

By Laura Berrill, Techworld.com October 07, 2004

A highly critical and unpatched security hole in Microsoft (Profile, Products, Articles) Corp.'s ubiquitous Word software could be used to launch a denial of service attack and give system access.

Discovered by HexView, the hole affects Microsoft Office 2000, Microsoft Office XP, Microsoft Word 2000 and Microsoft Word 2002. It was discovered Thursday and is currently unpatched. [snip]

I guess the idea is to completely numb people about secuity problems. "Oh dear, another highly critical security bug, yawn."

Defense in Depth

[sirshannon]

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.

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 .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 [hdconsultants.us] that shows how I check authentication/authorization at the page/function/control level.

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)

[Vic Metcalfe]

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.

Microsoft's attacks on Unix/Linux caused this

[spitzak]

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.

Re:This is the American corporate way:

[GoofyBoy]

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

Re:This is the American corporate way:

[node 3]

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

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

[gregarican]

If you'd read the KB article you simply a few lines of code to a global file that resides at the root directory of the web application. While I'll admit the vulnerability is sadly elementary and has existed in previous Microsoft implmentations it's not like Microsoft has asked developers to completely recode every single file of a web application. It's like saying, hey Samba has this really basic flaw. But if you add an entry in your smb.conf file it's okay. It's not the end of the world. It's crazy to thi

Re:heh

[Grishnakh]

It's very unlikely. Pr0n sites are usually big users of OSS software; almost all run on Apache with Linux.

Re:Time to rewrite alright...

[hkb]

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.