Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×
Microsoft Security

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.
This discussion has been archived. No new comments can be posted.

Microsoft Issues Ominous ASP.Net Security Warning

Comments Filter:
  • by mfh ( 56 ) on Thursday October 07, 2004 @12:53PM (#10460909) Homepage Journal
    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!
    • by nizo ( 81281 ) on Thursday October 07, 2004 @12:54PM (#10460934) Homepage Journal
      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".

      • by badriram ( 699489 ) on Thursday October 07, 2004 @01:16PM (#10461197)
        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.
        • by coolgeek ( 140561 ) on Thursday October 07, 2004 @01:33PM (#10461396) Homepage
          I believe the difference is the PHP leaks have been resolved.
        • by Anonymous Coward on Thursday October 07, 2004 @02:23PM (#10462050)
          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.
          • by Pieroxy ( 222434 ) on Thursday October 07, 2004 @03:45PM (#10463037) Homepage
            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.
          • 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 (Score:5, Informative)

            by ad0gg ( 594412 ) on Thursday October 07, 2004 @05:08PM (#10464055)
            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]

        • 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.
      • 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.
    • by Timesprout ( 579035 ) on Thursday October 07, 2004 @12:58PM (#10460970)
      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.
      • by Gentoo Fan ( 643403 ) on Thursday October 07, 2004 @01:02PM (#10461024) Homepage
        It sounds better to yell "rewrite!" for the knee-jerk Slashbots rather than "five line patch!"
        • by hruntrung ( 89993 ) on Thursday October 07, 2004 @01:13PM (#10461166)
          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.
          • by Gentoo Fan ( 643403 ) on Thursday October 07, 2004 @01:17PM (#10461204) Homepage
            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".
            • by deadlinegrunt ( 520160 ) on Thursday October 07, 2004 @01:23PM (#10461290) Homepage Journal
              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.
              • by Crashman_pnc ( 191880 ) on Thursday October 07, 2004 @01:42PM (#10461531) Homepage
                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.
          • 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
      • by ThePatrioticFuck ( 640185 ) on Thursday October 07, 2004 @01:12PM (#10461144)
        "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 :)
      • by Ingolfke ( 515826 ) on Thursday October 07, 2004 @01:15PM (#10461188) Journal
        Unfortunately, the few lines required to implement the patch has already been copyrighted by Brian Connolly [slashdot.org].
      • 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:)
      • by Black Parrot ( 19622 ) on Thursday October 07, 2004 @01:29PM (#10461349)


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

      • by sempf ( 214908 ) * on Thursday October 07, 2004 @01:43PM (#10461544) Homepage Journal

        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

    • by Saeed al-Sahaf ( 665390 ) on Thursday October 07, 2004 @01:06PM (#10461067) Homepage
      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.

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

    • by 0x0d0a ( 568518 ) on Thursday October 07, 2004 @01:18PM (#10461224) Journal
      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 (Score:4, Insightful)

        by mfh ( 56 ) on Thursday October 07, 2004 @01:39PM (#10461476) Homepage Journal
        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.
      • by node 3 ( 115640 ) on Thursday October 07, 2004 @02:41PM (#10462293)
        *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...
    • by WebCowboy ( 196209 ) on Thursday October 07, 2004 @01:44PM (#10461549)
      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.
    • 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?"

    • by Knightmare ( 12112 ) on Thursday October 07, 2004 @02:31PM (#10462170) Homepage
      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.
  • Lost productivity (Score:4, Interesting)

    by BWJones ( 18351 ) * on Thursday October 07, 2004 @12:53PM (#10460915) Homepage Journal
    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!

    • by wankledot ( 712148 ) on Thursday October 07, 2004 @12:57PM (#10460960)
      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 (Score:5, Insightful)

        by plopez ( 54068 ) on Thursday October 07, 2004 @01:15PM (#10461193) Journal
        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.
    • by athakur999 ( 44340 ) on Thursday October 07, 2004 @01:03PM (#10461037) Journal
      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.

  • Same old, same old. (Score:5, Interesting)

    by gregarican ( 694358 ) on Thursday October 07, 2004 @12:54PM (#10460921) Homepage
    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?
  • How simple! (Score:5, Funny)

    by AndroidCat ( 229562 ) on Thursday October 07, 2004 @12:54PM (#10460925) Homepage
    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?

  • by Mr. Flibble ( 12943 ) on Thursday October 07, 2004 @12:54PM (#10460929) Homepage
    They don't have to worry. All the people with black hats will rewrite the code for them... Free of charge!
  • What's new? (Score:4, Insightful)

    by Anonymous Coward on Thursday October 07, 2004 @12:54PM (#10460933)
    In *any* server-side scripting language, you should doublecheck each string you get from an URL, POST, etc.
    • Re:What's new? (Score:5, Interesting)

      by Frag-A-Muffin ( 5490 ) on Thursday October 07, 2004 @01:19PM (#10461229) Homepage
      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?
    • by spideyct ( 250045 ) on Thursday October 07, 2004 @01:22PM (#10461269)
      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... (Score:5, Funny)

    by JoeLinux ( 20366 ) <joelinux@gmaiBOYSENl.com minus berry> on Thursday October 07, 2004 @12:55PM (#10460938) Homepage
    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 (Score:4, Funny)

    by Anonymous Coward on Thursday October 07, 2004 @12:55PM (#10460940)
    Asp.NOT or asp.Nyet!
  • by whyne ( 784135 ) on Thursday October 07, 2004 @12:59PM (#10460985)
    "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?
    • 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.
  • by halivar ( 535827 ) <bfelger@gmaiRABBITl.com minus herbivore> on Thursday October 07, 2004 @12:59PM (#10460989)
    ...why people refuse to use PHP. How far are you going to trust Microsoft to get it right? How many vulnerabilities does it take?
    • by Timesprout ( 579035 ) on Thursday October 07, 2004 @01:05PM (#10461055)
      Right, because historically PHP has been an absolute bastion of security.
    • by DAldredge ( 2353 ) <SlashdotEmail@GMail.Com> on Thursday October 07, 2004 @01:07PM (#10461082) Journal
      It may have something to do with the fact that PHP changes too much between minor verions. Or at least it used to.
    • 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...)

    • by FortKnox ( 169099 ) on Thursday October 07, 2004 @01:19PM (#10461233) Homepage Journal
      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.
      • by gregmac ( 629064 ) on Thursday October 07, 2004 @02:03PM (#10461798) Homepage
        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.

      • some banks do... (Score:3, Interesting)

        by mgkimsal2 ( 200677 )
        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? (Score:4, Informative)

      by gregarican ( 694358 ) on Thursday October 07, 2004 @01:22PM (#10461263) Homepage
      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? (Score:4, Insightful)

        by UfoZ ( 680310 ) on Thursday October 07, 2004 @01:41PM (#10461513) Homepage
        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? (Score:3, Informative)

        by hackstraw ( 262471 ) *
        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.
    • by FTL ( 112112 ) * <slashdot@ne[ ]fraser.name ['il.' in gap]> on Thursday October 07, 2004 @01:25PM (#10461309) Homepage
      > 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.

      • by someonehasmyname ( 465543 ) on Thursday October 07, 2004 @01:51PM (#10461634)
        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 (Score:5, Interesting)

    by bigtallmofo ( 695287 ) on Thursday October 07, 2004 @01:01PM (#10461002)
    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$%^!!! (Score:5, Interesting)

    by PincheGab ( 640283 ) on Thursday October 07, 2004 @01:01PM (#10461007)
    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 (Score:5, Interesting)

      by Swamii ( 594522 ) on Thursday October 07, 2004 @01:20PM (#10461238) Homepage
      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.
      • 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$%^!!! (Score:3, Insightful)

      by huge colin ( 528073 )
      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! (Score:3, Insightful)

      by Spoing ( 152917 )
      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$%^!!! (Score:3, Informative)

      by mborland ( 209597 )
      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.

  • by Doc Ruby ( 173196 ) on Thursday October 07, 2004 @01:02PM (#10461014) Homepage Journal
    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 (Score:3, Interesting)

    by ryanw ( 131814 ) on Thursday October 07, 2004 @01:02PM (#10461022)
    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! (Score:5, Funny)

    by Garabito ( 720521 ) on Thursday October 07, 2004 @01:04PM (#10461046)
    No more [registration required] articles on ASP.net servers!
  • by Jakhel ( 808204 ) on Thursday October 07, 2004 @01:05PM (#10461059)
    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? (Score:5, Interesting)

    by kcurtis ( 311610 ) on Thursday October 07, 2004 @01:11PM (#10461138)
    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? (Score:3, Insightful)

      by erobillard ( 820008 )
      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? (Score:3, Insightful)

      by Knightmare ( 12112 )
      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... (Score:4, Interesting)

    by someonehasmyname ( 465543 ) on Thursday October 07, 2004 @01:19PM (#10461236)
    That's pretty funny, but my favorite is still this one [insecure.org]
  • by ajs318 ( 655362 ) <sd_resp2@earths[ ].co.uk ['hod' in gap]> on Thursday October 07, 2004 @01:22PM (#10461273)
    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.
  • by kevlar ( 13509 ) on Thursday October 07, 2004 @01:23PM (#10461291)
    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.
  • by infinii ( 27811 ) on Thursday October 07, 2004 @01:24PM (#10461296) Homepage
    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.
  • by AndroidCat ( 229562 ) on Thursday October 07, 2004 @01:24PM (#10461298) Homepage
    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 (Score:5, Interesting)

    by sirshannon ( 616247 ) on Thursday October 07, 2004 @01:32PM (#10461385) Homepage Journal
    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).
  • by Vic Metcalfe ( 355 ) on Thursday October 07, 2004 @02:03PM (#10461799) Homepage
    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.
  • by spitzak ( 4019 ) on Thursday October 07, 2004 @02:20PM (#10462011) Homepage
    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.

The solution to a problem changes the nature of the problem. -- Peer

Working...