Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Apache Vulnerability Announced

Posted by krow on Mon Jun 17, 2002 03:53 PM
from the lame-DOS-attacks dept.
Security Apache
Aaron writes "Versions of the Apache HTTP Server up to and including 1.3.24 and 2.0 up to and including 2.0.36 contain a bug in the routines which deal with invalid requests which are encoded using chunked encoding. In some cases it may be possible to cause a child process to terminate and restart, which consumes a non-trivial amount of resources. See the official announcement and stay tuned here for updated versions." This is in response to the rather uninformed and questionable security notice by ISS X-Force, about a bug that has already been mentioned on the public mailing lists for Apache and is fixed in CVS for Apache 2.0. I am also told that their patch doesn't fully solve the problem. I am sure though that by awaking us to the problem they will get a lot of great press just like any of the other companies currently using useless bug announcements as press releases.
This discussion has been archived. No new comments can be posted.
Apache Vulnerability Announced | Log In/Create an Account | Top | 307 comments | Search Discussion
Display Options Threshold:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • Switch to IIS (Score:4, Funny)

    by l33t j03 (222209) <l33tj03@hotmail.com> on Monday June 17 2002, @03:56PM (#3717905) Homepage Journal
    Proof positive that IIS is a better web server than Apache. You don't see IIS vulnerabilites spouted all over the internet every day.

  • Enough Already (Score:5, Insightful)

    by zpengo (99887) on Monday June 17 2002, @03:56PM (#3717907) Homepage
    Boy, it's a good thing these problems only affect Micro$oft server software, because it sure would be a pain in the neck if...

    ...oh, wait.

    You mean *nix admins actually have to worry about patches and service packs too?

    Don't get me wrong, I don't intend this to be an "I told you so!" from the MS camp to the *nix camp, but rather a polite reminder that all admins have to keep up with their patches, service packs, and whatever. You can't just install Apache and let it go. You need to know what you're doing.

    There's a difference between an "admin" and "someone who installed some software".

  • A lot of noise? (Score:1)

    by rector (580924) on Monday June 17 2002, @03:57PM (#3717908)
    "Useless bug announcements" are a special topic. May be, some bugs appear intentionally to make a lot of noise of it?
    • 1 reply beneath your current threshold.

  • Not enough time!! (Score:2, Funny)

    by dpete4552 (310481) <slashdot AT tuxcontact DOT com> on Monday June 17 2002, @03:57PM (#3717916) Homepage
    Hey, it's not Apache org's fault that the bug is around. If those damned security news sites wouldn't release the exploits so soon then it wouldn't be a problem. It's those irresponsible bastards that are the problem here. Sheesh, the nerve.

  • A bug in open source code? (Score:2, Funny)

    by Anonymous Coward on Monday June 17 2002, @03:59PM (#3717927)
    That's unpossible!

  • Useless bug announcements-- My turn! (Score:3, Funny)

    by rocjoe71 (545053) on Monday June 17 2002, @03:59PM (#3717934) Homepage
    The Rocjoe Institute is reporting that under some conditions, Windows *may* crash...

  • Finally... (Score:1)

    by RAMMS+EIN (578166) on Monday June 17 2002, @04:00PM (#3717935) Homepage Journal
    Good to know that some Grey Hats are working on finding holes in Apache, too. That way it can stay ahead of IIS, which gets patched on a rather regular basis.

    echo Patch apache >> todo.txt

  • Debian (Score:1)

    by mackstann (586043) on Monday June 17 2002, @04:00PM (#3717937) Homepage
    so how long before i need to apt-get update && apt-get upgrade? :)
    • 1 reply beneath your current threshold.

  • It's still better than IIS (Score:2, Insightful)

    by Anonymous Coward on Monday June 17 2002, @04:01PM (#3717949)
    Despite the existence of a flaw, it's going to be less serious than a comparable flaw in IIS. No, I'm not an anti-MS bigot; Apache typically runs an an unprivledged user. Thus, you can't root the box because of this flaw. If it were IIS, you'd have system level privledges.

  • Apache team not trusted (Score:5, Interesting)

    by neoThoth (125081) on Monday June 17 2002, @04:02PM (#3717954) Homepage
    I posted this as a story earlier...

    Turns out the ISS X-Force team doesn't trust the Apache crew to fix what seems to be a very serious exploitable bug in the http code. They just released an advisory to the Bugtraq mailing list here [securityfocus.com] and provided some 'patch code'. The patch code (which attempted to typcast the vulnerable area) doesn't seem to fix the issue.
    So in effect there are a bunch of Apache servers out there with a possibly remote exploitable buffer overflow. Was this a big ooops on the part of ISS?
    One has to wonder why they didn't go to the Apache team first with this? Rumor has it that ISS feels that Red Hat has burned them (ISS) in the past and since the Apache team has some Red Hat employees they shouldn't be trusted.
    Another rumor that has been floating is that the ISS team doesn't consider Apache to be "a vendor" and therefore doesn't need to follow the normal disclosure rules. This sets a pretty bad precedant of not working with vendors just because you don't get along with them. A companies personal pettiness should not be allowed to override the security of a majority of the internets websites. The patch has offically made it into the Apache CVS but again why the hell didn't ISS talk with Apache? I noticed another post by NGGS (referenced in link above) that they already had a CVS number so they appeared to have gone through the proper channels and got 'beat to the punch' by ISS. Sounds like a motive to me....

  • Thoughts on this hole (Score:4, Interesting)

    by ajrez (99515) on Monday June 17 2002, @04:02PM (#3717955) Journal
    (A) Bugtraq and associated lists perhaps have held off on posting this, MAYBE, but then this brings us back to the Full Disclosure arguement.

    (B) Better question: Why is ISS releasing a poorly researched hole (they didn't even know that Apache 2.x had it) and a worthless patch prior to contacting the vendor? Premature ejaculation here or WHAT?

    I fail to see what their hurry was, lest their market share is dipping and they really needed to beat someone (such as David Litchfield?) to the punch.

    This is completely irresponsible. There are scores of devices that use Apache embedded. These manufacturers and THEIR clients now need to come up with something *fast* to get locked down.

    F'n genius....

    • Full disclosure and reputations... (Score:4, Interesting)

      by sterno (16320) on Monday June 17 2002, @04:28PM (#3718140) Homepage
      Well, I think it can be safely reasoned that ISS cannot be considered a reputable security organization. Do you really want to give these guys any money when:

      1) They are unable to fully understand the nature of a discovered flaw

      2) They are unable to release a patch that solves the problem (demonstrating a lack of a good QA process)

      3) They have demonstrated an inability to work effectively with industry leading software developers

      I don't know about you, but I'd be hard pressed to trust my business or even my home data to the security of an organization that is so apparently incompetent. They have a lot of 'splaining to do.
      [ Parent ]
      • 1 reply beneath your current threshold.
    • Re:Thoughts on this hole by drzhivago (Score:1) Monday June 17 2002, @04:45PM
      • 1 reply beneath your current threshold.
    • 1 reply beneath your current threshold.

  • Bugs Apply To All Software (Score:1)

    by jaxon6 (104115) on Monday June 17 2002, @04:03PM (#3717962)
    Every large piece of software has bugs. It is inevitable. The difference is that if a piece of software is written with security in mind, it will have less bugs. If a piece of software is written with backward-compatibility, ease of use, performance at any cost, etc.., it will have more bugs.

  • Impact on *nix platforms (Score:5, Informative)

    by jukal (523582) on Monday June 17 2002, @04:03PM (#3717964) Journal
    From the bulletin [apache.org]:
    Due to the nature of the overflow on 32-bit Unix platforms this will cause a segmentation violation and the child will terminate. However on 64-bit platforms the overflow can be controlled and so for platforms that store return addresses on the stack it is likely that it is further exploitable. This could allow arbitrary code to be run on the server as the user the Apache children are set to run as.

    It seems that thanks to the *nix way of handling processes and their childs, this represents minor threat than on other platforms, in which it is even more easily exploitable as a DOS attack. However, this is not minor news eve for us using *nix breeds.

  • ISS patch is not complete (Score:5, Interesting)

    by btellier (126120) <btellier@gm[ ].com ['ail' in gap]> on Monday June 17 2002, @04:04PM (#3717969)
    As noted by valcu.gheorghe@caatoosee.ro on Bugtraq:

    ----
    The patch that mentioned casting bufsiz from an int to an unsigned int
    failed to do a few things:

    1) There are 2 instances of the same code in http_protocol.c that need
    to be fixed, as both suffer from the same problem
    2) The cast to unsigned int was only done in comparison, and was not
    done in assignment, which could possibly lead to problems down the road
    with the int value?

    I haven't checked any of this, just noticed it and was really just
    wondering "why wasn't this done?".

    The code that is apparently "buggy" is this:

    len_to_read = (r->remaining > bufsiz) ? bufsiz : r->remaining;

    The code was mentioned to be changed to this:

    len_to_read = (r->remaining > (unsigned int)bufsiz) ? bufsiz :
    r->remaining;

    However, this doesn't assign that casted value to len_to_read, it just
    uses the cast for comparison and then passes on the possibly bogus data
    on to len_to_read.

    So, should the fix not be to change it to:

    len_to_read = (r->remaining > (unsigned int)bufsiz) ? (unsigned
    int)bufsiz : r->remaining;

    Also, like I mentioned, there are two places where this happens in
    http_protocol.c, one at line 2062, and the other (the one mentioned in
    the patch) at 2174.

    -----

  • Double standard (Score:2, Insightful)

    by bluegreenone (526698) on Monday June 17 2002, @04:04PM (#3717970) Homepage
    This is in response to the rather uninformed and questionable security notice by ISS X-Force, about a bug that has already been mentioned on the public mailing lists for Apache and is fixed in CVS for Apache 2.0.

    So your company publicizes a bug for IIS, you're a hero. Publicize one for Apache, you're now "uninformed and questionable"? Geez.

  • It's not just a DoS (Score:2)

    by btellier (126120) <btellier@gm[ ].com ['ail' in gap]> on Monday June 17 2002, @04:06PM (#3717985)
    This is a memory mismanagement issue, AKA a sort of buffer overflow. In this case, under certian platforms and implementations it can be exploited to execute arbitrary code with the web server's UID (usually nobody/www/nopriv/etc). It's worse than you think.
  • It claims that it's a 32 bit overflow problem - and in unices it will cause the child process to terminate. This post almost got me thinking i had to upgrade to a new version... ;)
    If you're running on a sane OS, The bug seeme negligable.. so a few people will have to hit reload if they try to do funny stuff.
    (It's not easy foreseeing 'issues' with dealing with a non-open or standardized OS)
    isnt using a good server software on an OS that really WAS NOT made for server functions sort of like using a bandaid to cover up leporacy? (sp?)

  • Oh lovely (Score:1)

    by sheepab (461960) on Monday June 17 2002, @04:07PM (#3717998) Homepage
    Here come all the 'Linux death watch'/'Linux is evil' trolls with their nonsense about how Linux is more insecure than Windows. Death to all trolls!

  • What happened to disclosure lead times? (Score:5, Interesting)

    by Builder (103701) on Monday June 17 2002, @04:15PM (#3718061)
    WTF!?!?!

    What happened to the lead time given to a software vendor before publishing a vulnerability ? I thought that all professional 'sploit hunters honoured this.

    The idea is to give the vendor time to produce a patch so that when you announce the vulnerability there is an official patch available. It's 22:16 here now and I'll be sat up half the night waiting to see if Apache release a patch because I have around 20 servers that run Apache, and I can't sleep until I know they're secure.

    I'm all for full disclosure, but I much prefer RESPONSIBLE full disclosure. If anyone from IIS is reading this, you're a bunch of immature mornons. Play by the rules or fuck off!

  • Scuse me (Score:1)

    by Second_Derivative (257815) on Monday June 17 2002, @04:18PM (#3718090)
    In Apache 1.3 the issue causes a stack overflow. Due to the nature of the overflow on 32-bit Unix platforms this will cause a segmentation violation and the child will terminate. However on 64-bit platforms the overflow can be controlled and so for platforms that store return addresses on the stack it is likely that it is further exploitable. This could allow arbitrary code to be run on the server as the user the Apache children are set to run as. We have been made aware that Apache 1.3 on Windows is exploitable in this way.

    Ok can someone PLEASE explain what this report is about? Can you or can you not cause a stack overwrite on x86 Linux? it says that 32 bit unices it won't work; how is the stack handling different from 'doze? it then goes on to say that 64 bit architectures can be exploited and that "Apache 1.3 on windows is exploitable in this way". Apache on windows == 32 bit != 64 bit!

    Someone care to clarify?

    • Re:Scuse me by Old Wolf (Score:2) Monday June 17 2002, @06:36PM
      • Re:Scuse me by Second_Derivative (Score:1) Monday June 17 2002, @08:03PM

  • Most can wait for a patch (Score:2)

    by Lxy (80823) on Monday June 17 2002, @04:29PM (#3718141) Journal
    From the ISS article:

    "X-Force has verified that this issue is exploitable on Apache for Windows (Win32) version 1.3.24. Apache 1.x for Unix contains the same source code, but X-Force believes that successful exploitation on most Unix platforms is unlikely."

    Sounds to me like it's nothing more than your basic overflow. While the article from Apache mentions the possible execution of code, I think they're referring to the Windows platform. Since all daemons have full security (root) on Windows, it makes sense that an attacker could run malicious code on a Windows machine. With *nix, Apache runs as nobody (by default, anyway) so attackers can't run any code as root, greatly reducing the amount of damage other than a DoS.

    It also mentions that the overflow consumes more resources on Windows, since on *nix it's only a child process restarting rather than the ENTIRE process restarting.

    Since there's no proof of concept issued yet, it's unlikely that a widespread attack will occur before a patch is issued.

  • Don't point the finger at ISS. (Score:1, Troll)

    by dave-fu (86011) on Monday June 17 2002, @04:32PM (#3718162) Homepage Journal
    What they did (unilaterally going ahead and releasing a bug they discoverd) is shady, but you should instead point the finger of blame at the Apache group for distributing a buggy product (IIS had a similar problem with chunking way back when... what's that cliche about forgetting history?) and, if you're the one who's pimping open source as the best thing since sliced bread to anyone who will or won't listen, point the finger right back at yourself for blindly trusting the code you're running.

    • The fact is, I do trust the Apache group... (Score:5, Insightful)

      by HopeOS (74340) on Monday June 17 2002, @06:11PM (#3718801)
      The fact is, I do trust the Apache group. And for good reason. I know the code is flawed because I write software for a living. All code is flawed, and to believe otherwise is folly. I also know that the competing products are also flawed. What Apache offers that none of their major competitors provide is access to the code. Give me the patch, and I'll apply it myself. If I'm still concerned, I can have a look around the code. And most importantly, they do a much better job at getting the fixes out in a timely manner.

      Unfortunately, the exploit clock is now actively running which, no thanks to ISS, was an otherwise unnecessary hassle. That said however, I am confident that hundreds of very concerned and capable open source programmers will be able to outpace the dozen or so overworked and underpaid software engineers who have the misfortune of handling Microsoft's IIS holes.

      Lastly, the vendors who provide Apache in their distributions do not have a monopoly on the market place. Their response time is critical to their relationship with their customers. Microsoft, by comparison, has no such relationship with their customers. Having personally been on the receiving end of many thousands of hours of Microsoft's service contracts, partnership deals, inside promotions, and developer support, I can safely say that we spent a lot of money for nothing. Microsoft ignores their preferred partners and Fortune 500 customers just as much as they discount the average desktop user. Through various positions, I've participated directly in all three cases, and after years of poor support from Microsoft, Linux has become a necessary and major factor in how I do business.

      -Hope
      [ Parent ]

  • Too good (Score:3, Funny)

    by selectspec (74651) on Monday June 17 2002, @04:36PM (#3718188)
    From the official announcement:

    Please note that the patch provided by ISS does not correct this vulnerability.

    Will upgrading to 32-bit color on my hard drive fix it or do I need to upgrade my monitor refresh rate to 512MB?

  • ISS posts a response (Score:1)

    by neoThoth (125081) on Monday June 17 2002, @04:43PM (#3718217) Homepage
    Nothing about their motive to release this without notifying the vendor (apache dev team) but sheds light on remotely exploitable aspects of this find.

    ----------

    This vulnerability was originally detected auditing the Apache 2.0 source
    tree. Apache 2.0 uses the same function to determine the chunk size, and
    has the same vulnerable signed comparison. It is, however, not vulnerable
    (by luck?) due to a signed comparison deep within the buffered reading
    routines (within core_input_filter).

    This issue is no more exploitable or unexploitable on a 32-bit platform than
    on a 64-bit platform. Due to the signed comparison, the minimum size passed
    to the memcpy() function is 0x80000000 or about 2gb. Unless Apache has over
    2gb of contiguous stack memory located after the target buffer in memory, a
    segmentation fault will be caused. If you understand how the stack is used,
    you will understand that this is an impossibility.

    Apache on "Win32" is not exploitable due to any "64-bit" addressing issues.
    It is easily exploitable due to the nature of structured exception handling
    on Windows and the fact that exception handler pointers are stored on the
    stack.

    If the DoS vulnerability is related to the overflow then the ISS patch will
    work to prevent it. The unsigned comparison prevents any stack overflow and
    as a result any related DoS issue is prevented. If the DoS issue is
    unrelated, then of course the ISS patch will not be of any help.

    ISS X-Force

  • Updates (Score:1)

    by Ace905 (163071) on Monday June 17 2002, @04:47PM (#3718246) Homepage
    Updates to this story can also be found here [myhometechie.com]

  • IIUC (Score:2)

    by rjamestaylor (117847) <rjamestaylor@gmail.com> on Monday June 17 2002, @05:10PM (#3718452) Homepage Journal
    If I understand correctly, my i686 boxes running Linux are vulnerable to the DOS attack using the invalid remote request IF the default "chunk encoding" response is enabled. But I'm not vulnerable to the stackoverflow remote vulernability because I (1) don't have a 64 bit processor and (2) don't run Windows.

    Question: where do I change the default "chunk encoding" response to an invalid request?

    • Re:IIUC by shogun (Score:2) Monday June 17 2002, @07:08PM
      • Re:IIUC by Electrum (Score:2) Monday June 17 2002, @10:52PM
        • Re:IIUC by shogun (Score:2) Tuesday June 18 2002, @12:25AM
      • 1 reply beneath your current threshold.

  • Some more data (Score:3, Interesting)

    by Florian Weimer (88405) <fw@deneb.enyo.de> on Monday June 17 2002, @05:11PM (#3718464) Homepage
    Some more data has become public: Some one close to the Apache team claimed that the IIS patch is wrong [uni-stuttgart.de], and there's a response from IIS [uni-stuttgart.de]. Maybe the IIS patch does fix the problem, but it is certainly not the most obvious and reader-friendly way to do it.

    And, by the way, we have extrated the critical patch [uni-stuttgart.de] from the 1.3.x CVS (currently skipping mod_proxy), created a Debian package [uni-stuttgart.de] containing it, and written a German notice [uni-stuttgart.de] (still preliminary) for our free security newsletter [uni-stuttgart.de]. (The Debian package will be updated as new changes appear in the Apache CVS .)
  • None of the behind the scenes politics (or non-politics) matters here. ISS has tarnished themselves, badly.

    Really bad move there, many people are going to see things from them in the future and think "Hey, these assholes again, ..."

    Smooth move.
    • 1 reply beneath your current threshold.

  • Apache means quality. (Score:5, Insightful)

    by rice_burners_suck (243660) on Monday June 17 2002, @05:24PM (#3718543) Journal

    I have to say, the Apache web server is quite a high quality piece of work. The fact that an obscure security issue has been found is a good sign that developers and users are on top of things in the constant struggle against remote exploiters.

    I am confident that a fix will be available very shortly. Serious sysadmins will have their servers patched sooner than any serious damage takes place. I don't have the same confidence when it comes to Microsoft's products.

  • ISS Responds (Score:4, Informative)

    by btellier (126120) <btellier@gm[ ].com ['ail' in gap]> on Monday June 17 2002, @05:27PM (#3718558)
    from Bugtraq a few minutes ago:

    ---
    ISS has requested that I forward this response to the list.

    ----------

    This vulnerability was originally detected auditing the Apache 2.0 source
    tree. Apache 2.0 uses the same function to determine the chunk size, and
    has the same vulnerable signed comparison. It is, however, not vulnerable
    (by luck?) due to a signed comparison deep within the buffered reading
    routines (within core_input_filter).

    This issue is no more exploitable or unexploitable on a 32-bit platform than
    on a 64-bit platform. Due to the signed comparison, the minimum size passed
    to the memcpy() function is 0x80000000 or about 2gb. Unless Apache has over
    2gb of contiguous stack memory located after the target buffer in memory, a
    segmentation fault will be caused. If you understand how the stack is used,
    you will understand that this is an impossibility.

    Apache on "Win32" is not exploitable due to any "64-bit" addressing issues.
    It is easily exploitable due to the nature of structured exception handling
    on Windows and the fact that exception handler pointers are stored on the
    stack.

    If the DoS vulnerability is related to the overflow then the ISS patch will
    work to prevent it. The unsigned comparison prevents any stack overflow and
    as a result any related DoS issue is prevented. If the DoS issue is
    unrelated, then of course the ISS patch will not be of any help.

    ISS X-Force
    ----

  • What happened wrt the discovery and reporting (Score:1)

    by lwillett (143842) on Monday June 17 2002, @05:52PM (#3718697)
    I found this message [securityfocus.com] and this message [securityfocus.com] (from bugtraq) to be informative regarding the interesting issues here.

  • Official Apache Project Security Advisory (Score:3, Informative)

    by dananderson (1880) on Monday June 17 2002, @06:17PM (#3718829) Homepage
    The official Apache Project security advisory is at http://httpd.apache.org/ [apache.org]

    Versions of the Apache web server up to and including 1.3.24 and 2.0 up to and including 2.0.36 contain a bug in the routines which deal with invalid requests which are encoded using chunked encoding. This bug can be triggered remotely by sending a carefully crafted invalid request. This functionality is enabled by default.

    In most cases the outcome of the invalid request is that the child process dealing with the request will terminate. At the least, this could help a remote attacker launch a denial of service attack as the parent process will eventually have to replace the terminated child process and starting new children uses non-trivial amounts of resources.

    We were also notified today by ISS that they had published the same issue which has forced the early release of this advisory. Please note that the patch provided by ISS does not correct this vulnerability.

    The Apache Software Foundation are currently working on new releases that fix this issue; please stay tuned here at http://httpd.apache.org/ for updated versions as they become available.

    [Link to full advisory follows at http://httpd.apache.org/info/security_bulletin_200 20617.txt [apache.org] ]

  • Open vs. Closed source (Score:2)

    by SamMichaels (213605) on Monday June 17 2002, @06:47PM (#3718968)
    I think everyone needs to think about this before spouting more nonsense.

    Putting aside the issue of ISS releasing it too early or the amount of bugs MS products have...

    Since Apache is open source, ANYONE can look at the code and do some debugging. We don't have to wait for a coding team to code it, a debugging team to debug it, a compiling team to compile it, a testing team to test it....

    Doesn't open source speed up the entire process since any amount of coders can do the patching? I would assume that the Apache team already has a boatload of patch candidates sitting in their inbox right now.

    The true nature of open source is the fact that MANY coders can review the source. I'm sure a million bugs were PREVENTED already because some guy out in Kansas said "hey dude...you don't want to do it like this. try this..."

  • impartiality (Score:1)

    by v8interceptor (586130) on Monday June 17 2002, @07:34PM (#3719218)
    Take the following situation:
    A certain web server product has a security hole.

    Is it open source?
    "Believe it or not, reports that XXX has a certain vulnerability. Amazing, we could hardly believe it. We had tested the vulnerability TEN TIMES before running this story...".

    Is it NOT open source, and perhaps even made by a certain larger corporation?
    "HAH! More reports that XXX is an absolute joke, about as secure as a plastic bag. The l4m3rs at XXX corp took three YEARS to produce a patch, which is now available. The vulnerability this time allows you to take over the sysadmin's computer if he/she is playing mine sweeper..."

    That said of course I would use Apache over IIS anyday :)

  • would be if Slashdot was hacked and this is the story that the hackers came up with :)

  • Heh. (Score:2)

    by autopr0n (534291) on Monday June 17 2002, @11:59PM (#3720266) Homepage Journal
    IIS remote code exploits every day, and in all this time all we ever see for apache is a potential Deinal of Service.

    Nice :)

  • No problem (Score:2)

    by mnordstr (472213) on Tuesday June 18 2002, @06:00AM (#3720977) Homepage Journal
    I'll just wait for RedHat to create a patched version of Apache and let my up2date patch my server. It's almost too easy...

  • Question for ISS? (Score:1)

    by kireK (254264) on Tuesday June 18 2002, @04:06PM (#3724598)
    Why does ISS think Apache is a not corproation?

    According to the FAQ [apache.org] from the Apache Software Foundation is a non-profit 501(c)(3) corporation, incorporated in Delaware, USA, in June of 1999. I'm surprised that the all knowing X-Force was nto able to find this information.

  • Fix available: 1.3.26 (Score:3, Informative)

    by dananderson (1880) on Tuesday June 18 2002, @05:26PM (#3725211) Homepage
    Apache 1.3.26 is available which is supposed to fix the buffer overflow problem.

    For mirrors: http://www.apache.org/dyn/closer.cgi/httpd/ [apache.org]
    For direct download: http://www.apache.org/dist/httpd/ [apache.org]
    For the announcement: http://httpd.apache.org/ [apache.org]

  • Already fixed (Score:1)

    by geschild (43455) on Wednesday June 19 2002, @10:44AM (#3729488) Homepage
    Due to 'due diligence' this 'hole' has been fixed. Patches are out for both 1.3.x and 2.0.x.

    To all responsible sys-admins out there: go get the patch(ed version)!

    (Another day, another bug squashed in under 2 days).

  • Apache decided the ISS fix does work (Score:1)

    by xijix (143366) on Wednesday June 19 2002, @01:14PM (#3730730)
    Apache has revised there posting to say that the ISS patch acctually does work.

  • Re:Fix for 1.3.x tree? (Score:2, Informative)

    by cliffwoolley (506733) on Monday June 17 2002, @04:10PM (#3718024)
    Updated releases of both 1.3 and 2.0 that fix this problem will be released VERY shortly.
    [ Parent ]

  • Re:Incoming (Score:4, Insightful)

    by iCharles (242580) on Monday June 17 2002, @04:13PM (#3718040) Homepage
    I think there is more than a little merit to the point you are mocking.

    Consider an application has a vulnerability. After an interval elapses, a patch is released, and peace and order is returned to the world.

    If it is an Open Source product, it is lauded as a benefit of the methodology. With "millions of eyes on the code," a problem, once identified, can be resolved. The system works!

    If it is Microsoft, the problem is the closed source. If it was open source, either the problem wouldn't be there in the first place, or the fix would come out faster. It is just another show of how it lacks.

    This artical, IMHO, is proof that just because it is Open Source does not mean it is bug (or vulernability) free.

    As for the time-to-fix, the examples I am used to hearing from the Open Source community is that the patch can be out in a number of hours. I question how much testing went on in the fix in terms of bredth of hardware and software integration, etc. The impression I left with is someone went out and whipped up something that appears to fix the problem. The initial fix plugs the hole, then others come behind them and make it better integrated (i.e. fewer bugs, etc.).

    What is the problem with this? None, I suppose. However, I fail to understand how this is really better, other than the fact that some "beta" code was released "in hours". Certainly not so much better than it merits all the looking-down-the-nose at other platforms.

    I also have a pet theory, which I often state. One of the reasons all crackers et al. go after Microsoft product is that they are widely used, and that showing their failings through breaking them gains them esteme on boards such as this one. Typcially, someone breaking in to an IIS site is condemed, but rather the SysAdmins for using IIS (regardless of application, corporate, or other requirements). This comes accross as condoning this behavior, and causes more people to do more damange.

    No, I don't think that doing otherwise will minimize the number of vulnerabilities or attacks, nor do I feel vulnerabilities shouldn't be fixed.

    [ Parent ]
    • Re:Incoming by gilroy (Score:2) Monday June 17 2002, @04:34PM
    • Re:Incoming by javahacker (Score:1) Monday June 17 2002, @04:39PM
    • Re:Incoming by alfaiomega (Score:1) Monday June 17 2002, @07:56PM
    • Re:Incoming by 0x0d0a (Score:2) Tuesday June 18 2002, @07:14PM
    • 3 replies beneath your current threshold.

  • Re:"uninformed and questionable"? (Score:1)

    by cliffwoolley (506733) on Monday June 17 2002, @04:13PM (#3718042)
    The fact that it doesn't describe the entire scope of the problem. See the official announcement on httpd.apache.org to understand why.
    [ Parent ]

  • Re:Fix for 1.3.x tree? (Score:3, Informative)

    by jukal (523582) on Monday June 17 2002, @04:14PM (#3718050) Journal
    > PHP doesn't work on 2.0 yet, so upgrading to 2.0 is not an option for us. Now what?

    Meanwhile, if you HAVE to use Apache 2.0, run PHP as CGI and you will avoid the version hassle (ofcourse loosing on performance etc). Anyway, it won't take long now to have PHP4 working good as module with 2.x, as the big guys are saying that the Apache API is now kind of stabile for 2.x series.
    [ Parent ]

  • Re:Fix for 1.3.x tree? (Score:2, Informative)

    by caluml (551744) <slashdotNO@SPAMspamgoeshere.calum.org> on Monday June 17 2002, @04:19PM (#3718092) Homepage
    I am running Apache 2.0.36 and PHP 4.1.2 at the moment. It's stable enough, and quite easy to install.
    Install Apache from source, then configure PHP with --with-apxs2=/path/to/apache2/bin/apxs and install.
    Do the x-httpd-application .php thing in the conf file too. Search on Google if I'm none too specific ;)
    [ Parent ]

  • Re:This is Good News for Linux (Score:1)

    by nickgrieve (87668) on Monday June 17 2002, @04:25PM (#3718118) Journal
    What about Apache on the Windows platform, best of both worlds. leading industry technology in your Operating system and a open source http server.
    [ Parent ]

  • Re:Let the spinning begin! (Score:2)

    by jonabbey (2498) <jonabbey@ganymeta.org> on Monday June 17 2002, @04:29PM (#3718148) Homepage

    There's no point in spinning this, nor any real need. It's a bug, it has specific consequences cited in the story, it should be fixed.

    Spinning would be to point out how few remote exploits have been discovered in Apache over the last 4 years compared to IIS, and the fact that Apache's exploit count (if this is exploitable) is not zero doesn't mean that it's not still a whole lot less so far than IIS.

    [ Parent ]

  • Re:don't believe the FUD (Score:1)

    by Builder (103701) on Monday June 17 2002, @04:47PM (#3718252)
    It hasn't been corrected yet. Many sysadmins in Europe will be sitting up tonight waiting for a patch.
    [ Parent ]

  • Re:don't believe the FUD (Score:2, Interesting)

    by Verizon Guy (585358) on Monday June 17 2002, @07:14PM (#3719122) Homepage
    You're a fucking idiot. It's not fixed yet.

    If anything, this hole just serves (ha!) as a reminder of how superior Apache and open source are in general. Only a fool would use anything else.

    I guess that fool is me. Been an IIS user for years. Never r00ted. Not once.

    It's called "good system administration."
    [ Parent ]

  • Re:Hah, the hypocrisy... (Score:1)

    by getter_85 (464748) on Wednesday June 19 2002, @11:36AM (#3729839) Homepage Journal
    heh, you ARE a good troll *nods*

    seriously, if you want people to not make fun of your name, then don't claim that you wrote the linux kernel then, or else people will just think you're a bad parody trying to piss every linux user off
    [ Parent ]

  • Re:I just love it ;) (Score:1)

    by jasonn (562215) <jason@jasonn.com> on Thursday June 27 2002, @07:50PM (#3783632) Homepage
    Amen! It's nice to finally have control. When I was a Microsoft ISP, I had to rely on Microsoft to 'feel' like revealing their hole then release the updated file. It was wonderful to finally actually have some level of control over my servers. I will NEVER rely on IIS for production servers again.
    [ Parent ]
  • 36 replies beneath your current threshold.

  • All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2010 Geeknet, Inc.