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

 


Forgot your password?
Close
typodupeerror
×
Bug Networking Security Apache

Apache Flaw Allows Internal Network Access 99

Posted by samzenpus from the protect-ya-neck dept.
angry tapir writes "A yet-to-be-patched flaw discovered in the Apache HTTP server allows attackers to access protected resources on the internal network if some rewrite rules are not defined properly. The vulnerability affects Apache installations that operate in reverse proxy mode, a type of configuration used for load balancing, caching and other operations that involve the distribution of resources over multiple servers."
This discussion has been archived. No new comments can be posted.

Apache Flaw Allows Internal Network Access More

Apache Flaw Allows Internal Network Access

Comments Filter:

  • bug confirmed on slashdot.org server (Score:5, Funny)

    by Anonymous Coward on Monday November 28, 2011 @06:12AM (#38188336)
    it allowed me to get frist post

  • Yawn (Score:3, Insightful)

    by Anonymous Coward on Monday November 28, 2011 @06:19AM (#38188366)
    Improper regex usage causes intended consequences, news at 11.

  • Use nginx? (Score:5, Interesting)

    by mhh91 ( 1784516 ) on Monday November 28, 2011 @06:23AM (#38188388)

    Why would anyone use Apache as a reverse proxy anyway?

    I mean, there's nginx, and it runs circles around Apache as far as I know.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      On RHEL and CentOS "yum search nginx" says "No Matches found". Do I need to say more? :)

      • Re:Use nginx? (Score:4, Informative)

        by CmdrPony ( 2505686 ) on Monday November 28, 2011 @06:37AM (#38188470)
        It's on EPEL. And if you're running websites that need fast reverse proxying and caching on the web server side, you should be able to build it yourself too. nginx is specifically designed for this kind of stuff, and is much faster and more secure than Apache. It's Russian lightweight quality, while Apache is bloat as hell (for this kind of stuff).

        • I thought if you need fast reverse proxying/caching you used the big name appliances (F5)

          • That depends entirely on the specs of the machines you are aquiring from F5. For most of their offerings, it is worth more to buy a better switch and a server to run nginx. For most of their clients, that also applies.

            But, yes, there are some really good appliances you can buy for reverse proxy/caching. You just probably don't need them.

        • Re: (Score:1)

          by Anonymous Coward

          Yeah. Nginx is also missing some important functionality Apache has. Like digest authentication.

      • Re: (Score:1)

        by Anonymous Coward

        Learn to search "http://rpm.pbone.net". It's very handy for finding personally built packages that can be brought into the mainline or useful third party repositories like EPEL and RPMforge.

        And get *off* of CentOS, it's violating all the basic principles that caused people to discard WhiteBox. Closed developer group, no hint of their over tarfy release dates, and they refuse to even discuss what's holding them up, accept help, or discuss their build structure so other testers can replicate their problems. A

      • Re: (Score:2)

        by shish ( 588640 )

        On RHEL and CentOS "yum search nginx" says "No Matches found". Do I need to say more? :)

        This is exactly the example I use when suggesting Debian as a server OS. How can you live with such a shit default repository? Even the tools needed to build good software from source aren't included >:| (And last I attempted it a couple of years ago, CentOS had the nerve to tell me (after I'd formatted my drive) that I needed to go back to my previous OS and download another 3 CDs, because one CD can't contain the massive number of packages for an everything-disabled blank install...)

    • Why would anyone use Apache as a reverse proxy anyway?

      Because Apache zealots will tout this [flaw] as a feature and not a flaw.

      Remember what we had a few years ago with dependency hell? [wikipedia.org] in rpm based distros?

      This 'hell' was fronted as a feature then. All complainants were 'put in their place' by saying they did not know what they were doing in the first place. Sad to say.

      • Remember what we had a few years ago with dependency hell? [wikipedia.org] in rpm based distros?

        This 'hell' was fronted as a feature then. All complainants were 'put in their place' by saying they did not know what they were doing in the first place. Sad to say.

        Happy to say, RPM distro users are still using rpm and there is no dependency hell at all.

        Dependency hell was a feature of most early generation package management systems. They all had it, most improve over time. deb based systems had it too.

        You might want to update your fanboi examples for the new millennium.

    • Re: (Score:3, Insightful)

      by KiloByte ( 825081 )

      nginx requires you to proxy everything, with Apache you can serve most of the website on that server and proxy away only a small part. Damn useful if you want to run something that needs its own http server (like, python-tornado) yet you don't want to give it a separate subdomain.

      • I think that's not true. You can delegate every location you want to a different server or serve it directly. You know there's this "location" directive in config. Nginx is very flexible.

        • Re:Use nginx? (Score:4, Informative)

          by KiloByte ( 825081 ) on Monday November 28, 2011 @08:00AM (#38188906)

          If you do that, you pay full passthrough costs for every single URL -- parsing, 587598237592 (approximately) context switches, ferrying data between two userspace processes, etc. With Apache, you suffer that only for URLs you actually need to proxy.

        • But if you had a regular http server running Apache (don't tell me it's not the norm) and then a single app needed to be put on different server, like the python-tomato mentioned or .NET or JEE site. Do you reconfigure whole server or do you just add proxy to it?

          Just because using it in big deployments is stupid doesn't mean it isn't used in small systems (few dozen thousand hits a day) with room to spare.

    • Re: (Score:2)

      by rev0lt ( 1950662 )
      With apache, you can use mod_security to filter many types of attacks before they reach the actual webservers. But yes, for many of my applications, nginx is awesome :)

    • Re: (Score:2)

      by tero ( 39203 )

      A lot of third-party security related products (especially in the Authorization/Authentication/Access business) are still tied to Apache since it's been dominating the free-software space for such a long time.

    • Re: (Score:2)

      by Karzz1 ( 306015 )
      nginx does not support reverse-proxy to AJP as far as I know.

    • Re: (Score:2)

      by Lennie ( 16154 )

      Even Apache has a project called http://trafficserver.apache.org/ [apache.org] if performance is what you need.

    • Because we've been using it in that role for most of a decade, it's never caused a single problem, and its performance has been completely satisfactory. nginx might be better in every other way but I've not had any reasons to replace a working, time-tested Apache installation with something new.

    • Re: (Score:2)

      by micheas ( 231635 )

      In my experience, the difference between apache and nginx is pretty small if you make an apples to apples comparison.

      Apache can run as either a threaded or non-threaded server. IF you are running apache as a reverse proxy, and have everything else stripped out and are running the Event Multi-Processing Module, the difference between apache and nginx tends to be reasonably small, in my experience.

      I use NGINX, and like it, but the awsome performance improvement is something that seems to apply to people t

      • Re: (Score:2)

        by DavidTC ( 10147 )

        Yes, but if you do that, you can't use PHP compiled in. You have to do fastcgi, just like nginx.

        More specifically, if you're planning on tearing down the entire apache config and rebuilding it, and stripping out all the features that apache has, I'm a bit unsure why you'd use apache anyway.

        Use apache if you need something that nginx can't do well, like webdav. Otherwise, don't spend the time trying to make it work like nginx, just use nginx.

        • Re: (Score:2)

          by micheas ( 231635 )

          Sometimes you have the choice of:

          a) run NGINX as a reverse proxy and rewrite all your rewrite rules

          or

          b) run apache as a reverse proxy and configure it so it runs quickly and keep your rewrite rules.

          The size and complexity of the existing rewrite rules generally makes one of them the obvious choice.

          • Re: (Score:2)

            by DavidTC ( 10147 )

            I've found that having massively complicated rewrites is just an exercise in annoyance. Especially when you have rules working at both server and directory level.

            About the only rewrite rules that makes sense in 99% of the circumstances are things like 'Alias an entire directory into the site so there's a webmail dir or whatever' and 'Send all not-found requests to this specific script'. (And strictly speaking, you can do the first with a symlink, although sometimes that's not workable.)

            Yes, I'm sure there

  • Garbage out. What else is new?

    • Re: (Score:1, Funny)

      by Anonymous Coward

      Apache is garbage! Upgrade to IIS!

    • Re:Garbage in, (Score:5, Insightful)

      by Eraesr ( 1629799 ) on Monday November 28, 2011 @06:29AM (#38188410) Homepage
      Pretty stupid thing to say. Garbage in should never mean "protected resources out".

      • Re: (Score:3)

        by garry_g ( 106621 )

        How can an automated system recognize whether an input is "not what the user meant to type"? As long as an input is syntactically correct, it's not up to the system ... granted, the double colon might not fall under the "syntactically correct" inputs, though it would have to be checked whether it may indeed be allowed or not ...

      • Re:Garbage in, (Score:5, Insightful)

        by Sqr(twg) ( 2126054 ) on Monday November 28, 2011 @08:39AM (#38189096)

        Pretty stupid thing to say. If the person who inputs the garbage is the admin (which is the case here, since only an admin can create rewrite rules) then it's not surprising that security might be compromised. There's no way you can make software safe from incompetent people with admin privileges.

        • Re: (Score:3)

          by Eraesr ( 1629799 )
          I do not agree.
          Software should prevent people, including even the most experienced admins, from making such mistakes. The fact that it's possible to make such a mistake is a flaw in the software.

          • Re: (Score:2)

            by Pieroxy ( 222434 )

            I do not agree.

            Software should prevent people, including even the most experienced admins, from making such mistakes. The fact that it's possible to make such a mistake is a flaw in the software.

            Beware, you're one step away from advocating iOS here. At least on iOS, it's harder for users to break things by typing nonsense in the configuration section.

          • Re: (Score:2)

            by Shatrat ( 855151 )
            What if the admin wants to do this intentionally to make internal resources available? Do you propose to limit the abilities of the regex in question to only make certain things possible? That doesn't seem like an improvement.

            • Re: (Score:2)

              by Eraesr ( 1629799 )
              Like korgitser mentions in this comment [slashdot.org], exceptions can be made, but by default it shouldn't be possible. I'm not saying it should be absolutely impossible to do this, but add another layer of protection which prevents admins from accidentally doing something like this. If an admin intentionally wants to do this and sets a specific configuration flag which allows him to do so, then that's a different story.

          • Software should prevent people, including even the most experienced admins, from making such mistakes. The fact that it's possible to make such a mistake is a flaw in the software.

            Thin ice here... The unix world seems to think, and usually it is the case, that by preventing the user from doing stupid things, you also prevent him from doing clever things. Yes there are exceptions, but it is important on which side you default.

    • Re:Garbage in, (Score:5, Interesting)

      by Anonymous Coward on Monday November 28, 2011 @07:05AM (#38188600)

      Garbage out. What else is new?

      GI/GO is bullshit, you should never output garbage no matter how fucked up the input is. If you can't process it normally, you kick out an error condition of some sort you don't just throw up your hands and say "Oh well, the user entered the wrong password so we'll just have to give him access to everything".

      • GI/GO is bullshit, you should never output garbage no matter how fucked up the input is

        *whoooosh*

        No, the computer has no way of reading your mind to know that the garbage isn't the perfectly processed output expected from the given input. The computer doesn't understand intent or context, and thankfully it just does what it's told instead of deciding to give you some stupid error, "The output wouldn't have looked pretty to computers. Error."

        Before tossing out grampa's words of wisdom, at least try to understand them. And if you can't, the get off my lawn!!!

  • Linux security flaw discovered (Score:4, Funny)

    by xyph0r ( 1153429 ) on Monday November 28, 2011 @06:31AM (#38188434)
    If you set the root password to 'password' and allow root login via ssh, attackers could compromise your system.

  • This is a fairly minor vulnerability at best, in order for it to matter to you at all:

    1, you have to be using reverse proxy mode
    2, you have to have misconfigured your rewrite rules
    3, you have to actually have some internal resources that are private

    The webservers I run, aside from not using Apache in reverse proxy mode...

    Some of them are in isolated dmz networks, so the only data you could get at is part of the public website anyway...
    The others are standalone webservers connected direct to the internet, a reverse proxy wouldn't get you anything you couldn't get to directly.

    What percentage of apache users will actually fulfil all the criteria for this issue to even matter to them at all?

    • Re:Probably not worthy of a front page article... (Score:4, Insightful)

      by CmdrPony ( 2505686 ) on Monday November 28, 2011 @06:43AM (#38188504)
      Just because you don't run such large sites doesn't mean it's not going to be a problem for anyone. When it's about some Microsoft vulnerability, there's new stories even for some minor things. I think Apache vulnerability is a big thing.

      It's easy to misconfigure those rewrite rules, and trust me, larger companies have internal resources that really should stay private. That Apache allows access to such resources is a huge flaw.

      • Re:Probably not worthy of a front page article... (Score:5, Insightful)

        by ledow ( 319597 ) on Monday November 28, 2011 @07:13AM (#38188626) Homepage

        If you have internal resources that need to stay private, have a large IT budget, run many Apache servers in reverse proxy modes and one of your admins is STUPID enough to not only mis-write their regular expressions like this (even if it wasn't obvious to an amateur), but they also fail to keep up on the security lists that have been discussing this for weeks, ignore all the advice given and have to find out via Slashdot that they need to do something - you are REALLY employing the wrong IT people.

        Everyone else? It doesn't actually affect them.

      • If a large company has resources that need to stay private, they don't mix private resources with public services. Why is an Apache server even allowed to look at private resources in the first place?

      • IIS has a URL Rewrite module that does the same as this with Reverse Proxy ..... does this suffer from the same issues?

        • For that matter, Apache has mod_proxy_http which does the same thing without rewrite rules. I have one external IP addresses and several subdomains running on my personal server that point to other hosts via mod_proxy_http. Works fairly well for me. Why would you use mod_rewrite for this unless you're only doing a subfolder?

    • Re:Probably not worthy of a front page article... (Score:4)

      by FBeans ( 2201802 ) on Monday November 28, 2011 @06:43AM (#38188508)
      • 4. You have to be attacked by somebody, who knows how to access these private resources.
      • 5. They have to do some thing with those resources (perhaps just read)
      • 6. You have to actually care that all of this just happened.

      I think it's good these security risks are highlighted, It can only bring about a faster fix. Of course in reality their are more problems with Apache, with IIS, with "ngix"(meh!) and all software. We don't know about these and they won't cause to much fuss.

      Bad Joke of the day: What do you do if your http server is broken? Just apply A-patch-e!!! (sorry)

    • What percentage of apache users will actually fulfil all the criteria for this issue to even matter to them at all?

      Considering the ubiquity of apache webserver i'd say even a very low percentage of installs would still be a lot.

      Also it's always good to know about existing vulnerabilities if only to update documentation.

  • OLD NEWS (Score:4, Informative)

    by Anonymous Coward on Monday November 28, 2011 @06:39AM (#38188484)

    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3368 [mitre.org]

  • Wait a minute... (Score:5, Insightful)

    by supersat ( 639745 ) on Monday November 28, 2011 @06:47AM (#38188530)

    Let me get this straight... IF you run Apache as a reverse proxy AND you misconfigure your mod_rewrite rules, then people can unintentionally access internal resources? I'm SHOCKED! SHOCKED, I tell you!

    That being said, I did RTFM and it's kind of a cute attack. It probably should be patched to protect people from shooting themselves in the foot, but I'm not sure I'd actually call it a vulnerability...

    • Re: (Score:3)

      by upuv ( 1201447 )

      I'm stunned this made the front page. This has been known for a long time actually. I had my CIO ring me up on this. He was freaking. He's seriously pissed at me for not fixing something we don't have a vulnerability too. "We use apache so why are you not fixing this!!!!!!!!"

      I actually have a meeting with him and the security team on this, this week. I'm going to walk through the defect and walk through our config. I'm still going to be ordered to get my people to patch this. Even though the patc

      • Don't even respond with NGINX been trying to win that for awhile now.

        This could be a good time to push for it...

    • Re:Wait a minute... (Score:5, Interesting)

      by Tomato42 ( 2416694 ) on Monday November 28, 2011 @08:08AM (#38188944)
      It would be like patching rm against usage of -rf. Just because you can cut your finger with a knife doesn't mean that the knife is a badly made tool, it just means you failed as a knife user.

      The Apache vulnerability isn't part of normal config, let alone the default one. Non story.

      • Re: (Score:1)

        by archen ( 447353 )

        If this is so common that it happens a lot and there is no reason people would write rules this way, then I'm not sure why you wouldn't patch it. Protecting the user base from pitfalls should be a goal of software. But yeah, non story.

        most implementations of rm now refuse to remove / (root directory), so yes even rm has been patched for safety at some point.

    • That's what I was thinking... if this is a vulnerability, what would be the expected behavior instead? "I'm sorry, Dave, but I can't let you do that?" hard-coded restrictions that will have to be worked around whenever they get in the way?

      No thanks. If I wanted to deal with software that insists it's smarter than I am, I'd be on Windows, OS X, or fighting with the new GNOME. I have a better idea: give me the gun and the sandals, and I'll be okay.

      Anyone who isn't might want to see if they can get back their

      • Why would it need to be hard-coded, no way to turn off restriction? Just show a warning and ask if the user really wants to do that.

    • Pretty much, yeah. The first thing I thought when I saw the rewrite rule you need to have to allow the vulnerability is "Hey, that's not right! There ought to be a slash before the $1 there, if you don't want unexpected weirdness in the incoming URL to mess things up.". I can see why a naive admin might want to do that, but it's dangerous and to be avoided because it's making a lot of assumptions about people playing by the rules that you just can't make (at least not on a publicly-accessible server, and yo

  • assbackwards is a variable.

  • Did Apache Flaw finally get promoted out of incubation?

  • Linux - Good Apache HTTP - Not so good MySQL - Currently doing no evil PHP - For the love of god, why?

Slashdot Top Deals

E = MC ** 2 +- 3db

Close