Slashdot Mirror


Microsoft Issues Ominous ASP.Net Security Warning

An anonymous reader writes "A security flaw in Microsoft's ASP.NET apparently allows access to password-protected areas just by altering a URL. There's no patch yet, but in the meantime Microsoft is telling ASP.NET developers they can rewrite their applications to prevent exploits. About 2.9 million web sites run on ASP.NET according to Netcraft." Some more links: another Microsoft article, NTBugtraq, K-Otik and Heise.

31 of 554 comments (clear)

  1. How Dogbert would handle this by mfh · · Score: 5, Funny

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

    --
    The dangers of knowledge trigger emotional distress in human beings.
    1. Re:How Dogbert would handle this by nizo · · Score: 5, Funny
      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".

    2. Re:How Dogbert would handle this by Timesprout · · Score: 5, Informative

      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.

      --
      Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
      What truth?
      There is no dupe
    3. Re:How Dogbert would handle this by Gentoo+Fan · · Score: 5, Insightful

      It sounds better to yell "rewrite!" for the knee-jerk Slashbots rather than "five line patch!"

    4. Re:How Dogbert would handle this by Saeed+al-Sahaf · · Score: 5, Insightful
      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.

      --
      "Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
    5. Re:How Dogbert would handle this by ThePatrioticFuck · · Score: 5, Funny
      "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 :)
    6. Re:How Dogbert would handle this by hruntrung · · Score: 5, Insightful

      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.

    7. Re:How Dogbert would handle this by badriram · · Score: 5, Informative

      Comparing PHP 4.3.x series to ASP.NET (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.

    8. Re:How Dogbert would handle this by deadlinegrunt · · Score: 5, Insightful

      Rewrite - yes; too extreme
      "five line patch" - too simple

      There are companies that have to research, document, code, document, test, document, release from development to production, document, etc...

      A better description lies somewhere between "rewrite" and "five line patch". Proprietary or OSS will have bugs; this release cycle still has to be done if it is a "rewrite" or a "patch".

      Just something to think about.

      --
      BSD is designed. Linux is grown. C++ libs
    9. Re:How Dogbert would handle this by coolgeek · · Score: 5, Insightful

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

      --

      cat /dev/null >sig
    10. Re:How Dogbert would handle this by Crashman_pnc · · Score: 5, Insightful

      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.

    11. Re:How Dogbert would handle this by jafomatic · · Score: 5, Insightful
      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? :)

      --
      ::jafomatic
    12. Re:How Dogbert would handle this by Anonymous Coward · · Score: 5, Insightful

      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.

  2. Same old, same old. by gregarican · · Score: 5, Interesting

    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?

  3. How simple! by AndroidCat · · Score: 5, Funny
    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?

    --
    One line blog. I hear that they're called Twitters now.
  4. Rewrite the code! by Mr.+Flibble · · Score: 5, Funny

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

    --
    Try to hack my 31337 firewall!
  5. Details... by JoeLinux · · Score: 5, Funny

    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.

  6. This is getting tiresome. by whyne · · Score: 5, Informative

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

  7. Don't panic just yet by bigtallmofo · · Score: 5, Interesting

    Anyone that's familiar with .Net has probably never used this technique to secure a page on their site. I believe most people would consider it more secure to set up a virtual folder within your web site and protect the pages within that virtual folder with either Basic or Windows Integrated Authentication. I've never used the web.config file technique to attempt to secure pages that really needed to be secure, and I doubt many other people have either. If you did without taking any other security steps, well... time to re-think that situation. This security vulnerability will prove to be a dud; nothing along the lines of the old ::$DATA exploits and what-not.

    --
    I'm a big tall mofo.
  8. Bulls$%^!!! by PincheGab · · Score: 5, Interesting
    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.
  9. Finally! by Garabito · · Score: 5, Funny

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

  10. Re:I still don't get... by Timesprout · · Score: 5, Informative

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

    --
    Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
    What truth?
    There is no dupe
  11. This isn't a bug really by Jakhel · · Score: 5, Funny

    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!

  12. Re:Lost productivity by GSloop · · Score: 5, Interesting

    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

  13. Re:How Dogbert would handle this (Furthermore...) by Ingolfke · · Score: 5, Funny

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

  14. Except for by plopez · · Score: 5, Insightful

    the fact that all the expensive licensing that the clients pay to MS because the product is 'supported'. If you have to rewrite your applications while waiting for a fix, you may as well use an open source solution because MS is neither giving you the quality product they promised nor the quality support they promised.

    --
    putting the 'B' in LGBTQ+
  15. Re:What's new? by Frag-A-Muffin · · Score: 5, Interesting

    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?

    --

    AirSpeak - http://itunes.com/apps/AirSpeak
  16. The two faces by Swamii · · Score: 5, Interesting

    Today an issue was discovered with Mozilla Firefox which, in the rare case a .config file was used to manage the security and permissions of a folder on a web server, a specially crafted URL could access the contents of the folder. Users are recommened to apply a small code patch to fix the issue.

    about face

    Today, yet another huge security hole was found in Microsoft software in which blows open all websites running ASP.NET. Microsoft's response? Re-write your code to fix the problem! Just another example of Microsoft's "blame the victim" mentality, when oh when will the madness end?!! We should all switch to Linux and Mozilla and Apache today because those apps never have bugs.

    --
    Tech, life, family, faith: Give me a visit
  17. It ain't just asp.NET by ajs318 · · Score: 5, Interesting

    It's not just asp.NET that's affected by bad programming. We use proper computers on our Intranet, not these silly Windows toys. Doesn't mean we're immune to the effects of sloppiness, though. The other day I found an application written by a subordinate of mine, where you could defeat an authentication check by setting a variable in a query string. You could say it's my fault really, for leaving register_globals on; but I find that 90% of the time it's a PITA having it off -- you might just as well be using something old-fashioned like perl if you're going to do that. When you have to read your variables "by hand" you can be sure what order you do 'em in. Sessions - who needs 'em? Just store a filename in a cookie and put the variables in the file, that's exactly how ASP and PHP do it! (Wonders: does having learned to do something the "hard way" first make you less likely to foul up when you come to do the same kind of thing a slightly easier way?) If you're going to be living in a house, you want housey stuff like electricity and plumbing, otherwise you may as well be living in a bender ..... if I'm going to be using PHP, I want PHP-like stuff otherwise it may as well be perl, but with far too many unnecessary round brackets {I grew up on British BASIC dialects which were similarly unfussy; SIN theta was as good as SIN (theta) but it saved you two whole precious bytes}.

    I'll be having a word with him about it when he gets back. I distinctly remember telling him to be careful where certain variables came from. I haven't checked his code too closely yet, because I've had other things to deal with; but if I find $auth=$_SESSION["auth"] commented out, I just might have to kill him.

    --
    Je fume. Tu fumes. Nous fûmes!
  18. 'Just a patch' is something of a misnomer by sempf · · Score: 5, Informative


    OK, I am an independant programmer that writes most of my code in ASP.NET. I'll give a taste of what this does to people like me.

    Remember, there are actually TWO vunerabilities that affect programmers in Microsoft right now - the GDI+ JPEG overflow and the new canonicalization overflow. Microsoft has fixed neither effectively, so the coders have to fix both.

    I manage eleven ASP.NET sites and five C# Windows Forms applications. Between those sixteen apps, I need to:

    - load them up in Visual Studio
    - Go back to the last stable build in SourceSafe
    - fix the reference to GDI+
    - add the mappath check to the Global.asax file
    - munge the global error handler so I don't get 12,434 error emails when the hacks start coming
    - compile
    - regression test the app
    - redeploy

    Now, admittedly, that only took about 20 hours for all 16 apps, but for CRYING OUT LOUD can't they just test this stuff BEFORE they send it out? I have the highest respect for the ASP.NET team, I have worked with many of them on the many books I have written on the topic. Nonetheless, I now have to spend 12 precious, non-billable hours on a problem that is covered at length in 'the bible' - Howard and LeBlanc's Writing Secure Code 2.

    Why do I write in ASP.NET? It is FAST - much much much faster than Java or perl or CF any other middleware out there. It is perfect for what I do. But how many of these are there? How many security flaws that the black hats know about that we don't?

    It's a little frustrating.

    S

    --
    /usr/bin/grep -i -E meaning life.txt
  19. The war on the web server front by WebCowboy · · Score: 5, Insightful

    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.