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

 


Forgot your password?
Close
typodupeerror
×
Security Software Apache

Apache Vulnerability Announced 307

Posted by krow from the lame-DOS-attacks dept.
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 More

Apache Vulnerability Announced

Comments Filter:

  • Switch to IIS (Score:4, Funny)

    by l33t j03 ( 222209 ) <l33tj03@hotmail.com> on Monday June 17, 2002 @04: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.

    • Re:Switch to IIS (Score:4, Funny)

      by krogoth ( 134320 ) <slashdot.garandnet@net> on Monday June 17, 2002 @05:54PM (#3718318) Homepage
      "You don't see IIS vulnerabilites spouted all over the internet every day."

      Yes, they tried but it's hard to get people to work on weekends.
    • Actually, this isn't funny - it's sad. Because those small glitches in open-source software that are hyped up to mega-bugs like this one are not even newsworthy when happening in IIS. I have yet to see a news article about a IIS-bug that did not allow to take over the whole machine, but I see trivial ("if you run that platform and if that may happen and if that is enabled than it might lead to a DOS attack") about OSS all the time.

      I still remember the so-called ssh vulnerability about keystroke-intervals, which allowed an attacker to reduce the brute-force attack - time from 10 gazillion years to 2 gazillion years. (This so-called vulnerability was so irrelevant it's no longer funny. Why such crap gets accepted on slashdot - I don't understand that.)

      Even slashdot has this tendency as it reports every tiny OSS-bug, but only reports the really huge-MS holes where you could drive a truck through.

      Microsoft enjoys a great PR-advantage, even on slashdot.

  • Enough Already (Score:5, Insightful)

    by zpengo ( 99887 ) on Monday June 17, 2002 @04: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".

    • Re:Enough Already (Score:1)

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

      There's also a difference between "Linux" and "something that works".

    • Re:Enough Already (Score:2, Informative)

      by Fantanicity ( 583135 )
      I don't intend this to be an "I told you so!"

      Good ... because IIS had a more serious problem with chunking [cert.org]
    • Actually it's not even an MS vs *nix debate, as Apache runs perfectly well on Win32 thank you. And there's also a big difference between a vulnerability which causes "non-trivial resource usage" and a vulnerability which owns your box. Not to mention that given the nature of the bug, the effects are likely much worse on apache running on win32 than on *nix.
      • You are possibly correct - on 64-bit Unix and Windows platforms it can give remote access. Note that you need a 64-bit platform to go beyond a DoS on Unix.

    • Re:Enough Already (Score:3, Insightful)

      by tshak ( 173364 )
      Now for the "But Apache will be patched in 1/5th the time it takes MS to patch IIS" replies.

      Most IIS patches (read: not IE, a completely different product) are out whithin days or a week at the most as well. They're just limited to a very small group of people outside MS that actually have access to it. Many people with certain support agreements can install these "hotfixes" that have not gone through regression testing. The resut of us have to way the 4-8 weeks once MS determines the quality is acceptable for the masses.

      Those who run mission critcal web servers generally don't apply the latest patch because it's generally more risky to install a "hot off the compiler" security patch then the security risk itself.

      • Re:Enough Already (Score:5, Insightful)

        by homer_ca ( 144738 ) on Monday June 17, 2002 @05:28PM (#3718139)
        "Most IIS patches (read: not IE, a completely different product) are out whithin days or a week at the most as well."

        The reason Microsoft patches are released close to when bugs are announced is because most security researchers withhold their reports until the vendor has a patch ready. Responsible disclosure and all. Eeye discovered the latest .htr bug in IIS and they waited until the hotfix was ready.

      • Re:Enough Already (Score:3, Insightful)

        by gilroy ( 155262 )
        Blockquoth the poster:

        Most IIS patches (read: not IE, a completely different product) are out whithin days or a week at the most as well. They're just limited to a very small group of people outside MS that actually have access to it.

        Release to a controlled, small subset is essentially the same as not released at all, at least for those unlucky types not in the small, controlled subset.
        • You glossed over the entire point. Most serious IT departments don't care about the "hot off the compiler" patches because of the lack of testing involved in said patches. So, MS releases stuff just as quickly, but they don't release to the public until the quality has been assured. With OSS, sure, you have the option of installing a pre-Alpha patch, but I wouldn't say that makes OSS inherintly more responsive or secure.
          • Blockquoth the poster:

            Most serious IT departments don't care about the "hot off the compiler" patches because of the lack of testing involved in said patches

            I'm not in IT, but I'd have to see this backed up with solid numbers before I'd believe it. Most of the IT people I know want the holes plugged quickly, and are willing to use early software to do it.


      • Those who run mission critcal web servers generally don't apply the latest patch because it's generally more risky to install a "hot off the compiler" security patch then the security risk itself.

        Its a tough choice when one has to decide which is the bigger threat: the vulnerability or the patch. This is one of the issues with Microsoft infrastructure. There is a history of hotfixes and servicepacks being detrimental to the systems they're supposed to be improving.


        It does little good if a hotfix is released quickly to fix a vulnerability when that hotfix itself could be more damaging than the vulnerability.

    • 1. What about this story has anything to do with *nix admins forgetting to install patches, and/or assuming their software is bugproof?

      2. This bug affects Windows too (exploitably, apparently, while the bug is only DoS under 32 bit unix systems)

      3. Who ever said *nix software never had problems/bugs? Maybe, arguably, less, but nobody contends that anything is perfect or ever will be, unless we can include marketing departments.

      4. We know there is a difference between "admin" and "someone who installed some software". Everybody knows that.
    • All software is likely to have bugs, but some are more serious than others. Look at the Apache advisories so far this year - I think attackers can read directories in the web root when auto-indexing is off (another reason not to rely on security through obscurity)! Now compare this to the average IIS vulnerability (which are also more frequent).
      • Back when attrition.org used to map defacements, the curves looked almost like the netcraft curves for installed based. A closer look revealed that the big curve on the attrition graph had "IIS" on the legend, whereas the big curve on the netcraft graph had "apache". IMO, that's the real reason to avoid IIS - accounts for 2x the defacements on 1/2 the installed base. Yes, my information is a bit old...my call is it has not changed significantly. BTW if anyone can help clue me in on whom has taken to archving/logging website defacements after attrition gave up, I'll appreciate it very much.
    • It's pretty funny that you say that. From the email


      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.

      and

      From Apache.org:
      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.

      Now, what were you saying about Windows vs. *nix?

      SealBeater


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


      Enough already, indeed. One of the very basics to system administration is system maintenance. The uninformed my think IT infrastructures work as "fire and forget" systems. But I have yet to see any such claim stated in this forum or included on any story submission. Yet it has become a popular point for any pro-Microsoft security argument.


      You're stating the obvious. And missing the point.


      If one wanted to view security vulnerabilities / announcements as more than good information to know, one has to look deeper at the issue. What is the vulnerability? What level of compromise can be achieved by exploiting it? How does the vulnerable product's developers react? How long does the vulnerability remain unaddressed? What is required to mitigate or eliminate that particular vulnerability? How does this affect the overall availability and management of the system(s) involved?


      These issues go beyond a single vulnerability or a smug "I told you so." And they go well beyond the scope of this topic.

    • Don't get me wrong

      Well you ARE WRONG.

      I won't upgrade my server, because I don't give a rat's ass about a "maybe if you do this and that and if 10 things coincides somebody might start a DOS attack" - bug like this.

      But I would care about the numerous IIS-bugs that LET YOU TAKE OVER THE MACHINE - oh wait, I do care, that's why I don't run IIS in the first place.

    • Fortunately though, patching *nix systems is *NOT* a full time job.
  • "Useless bug announcements" are a special topic. May be, some bugs appear intentionally to make a lot of noise of it?
  • 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
    That's unpossible!

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

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

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

    by Anonymous Coward
    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 @05: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....

    • Re:Apache team not trusted (Score:4, Informative)

      by fatphil ( 181876 ) on Monday June 17, 2002 @05:09PM (#3718008) Homepage
      From

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

      to

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

      is _not_ a fix. It's a total kludge. If a variable can contain a value that exceeds the range of its type, such that it has a different value when cast to unsigned type, the _the variable is of the wrong type_, and _that's_ the problem that needs to be fixed.

      This is nothing but lousy Elastoplast.

      FP.
    • ISS X-force regards themselves as Big. Really Big. They are as prickly and egotistical as a U.N. Commissioner, or a British aristocrat. And, like any elites, ISS is in such a position of power as to require toadiness from those who want to traffic with the X-force. Those who don't dance to ISS' tune can expect a frosty reception and official snubs.

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

    by ajrez ( 99515 ) on Monday June 17, 2002 @05: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 @05: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.

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

    by jukal ( 523582 ) on Monday June 17, 2002 @05: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.
    • From the part you quoted, it looks like 32-bit *nix doesn't do anything much here but have a child (started for the request anyway) die - so the DOS potential is all that's there, and it's not there any more than from any other bogus request, right? Intel(AMD)/Linux folk just don't have a worry here?
    • This could allow arbitrary code to be run on the server as the user the Apache children are set to run as.

      Oh no! User nobody is wreaking havoc!

      Considering that nobody doesn't even have a login on my box, I don't see how this compares with the root-o'-the-week for IIS.
      • > Oh no! User nobody is wreaking havoc!

        Wake up. Ever seen what happens when you break the ice, with tiny little hole? User nobody will just fall in the bottom and come back as root (berserk mode) - when you get local, root exploits are easy to find.

      • You shouldn't run Apache as Nobody (Score:2, Informative)

        by Anonymous Coward
        Oh no! User nobody is wreaking havoc!

        nobody doesn't even have a login on my box

        Too bad.. on most systems, the 'nobody' account has WAY too much power to run daemons. Running daemon processes as 'nobody' is a security faux-pas. The 'nobody' account should only be used by NFS (NFS maps 'squashed' userIDs to nobody.)

        For every daemon running with 'nobody' permissions (or any shared 'daemon' UID), the security risk increases exponentially, as a flaw in one daemon means access to the process data of all of the others.

        Each daemon should have it's own UID, with file permissions set accordingly, ie. write access to the pid and log files, and usually nothing else, not even /tmp (if it needs a temp folder, it gets it's own.)
        • > For every daemon running with 'nobody' permissions (or any shared 'daemon' UID), the
          > security risk increases exponentially, as a flaw in one daemon means access to the process
          > data of all of the others.

          That's not exponential, that's quadratic.

        • Each daemon should have it's own UID, with file permissions set accordingly, ie. write access to the pid and log files, and usually nothing else, not even /tmp (if it needs a temp folder, it gets it's own.)

          That's why you set the sticky bit on /tmp. Temporary files that should not be read by other users are created without world read permissions. The sticky bit prevents other users from modifying files that they do not own.
    • This could allow arbitrary code to be run on the server as the user the Apache children are set to run as

      Of course, thanks to suid and chroot, this doensn't give an attacker much.

      The secret is Apache+UNIX, not just Apache.

      Now, as for IIS...

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

    by btellier ( 126120 ) <btellier@gm[ ].com ['ail' in gap]> on Monday June 17, 2002 @05: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.

    -----
    • You correctly identify that the ISS patch can leave the problem there down the track ... but then your solution does too !

      The problem you have identified is that there could be code further on that references bufsiz (which I presume is a signed int). Therefore the solution is to either make bufsiz an unsigned int, or (if this is not possible), create another variable which is an unsigned int. This would require an analysis of all code that uses bufsiz, to discover the implications of changing it from signed to unsigned.

      Without looking at the full source, I don't know whether "len_to_read" is signed or unsigned, but in either case your suggestion does not help, as your cast will get overridden by the type of len_to_read (eg: after int x; x = (uint)(-2); x is still a signed int and eg. (x 0) will be TRUE.

      The cast on the comparison does affect the comparison because it changes the range of the quantity involved.
      • I haven't looked at the code, but it seems to me that the patcher thought that bufsize is of type int i.e. 32 bit signed value and that for large values of bufsize the comparison would break. The questions that form in my mind are:

        Is bufsiz an int? If I had been writing the code I would have used size_t. If that is the case, the patch has no effect on any platform with a reasonable definition of size_t which is usually defined as unsigned something.

        Is r->remaining an int? If so, the patch should cast r->remaining too (or instead). If the signedness of the two quantities conflicted, it should have been obvious because the compiler would have generated a warning.

        On a 32 bit machine, for the patch to change the behaviour of the comparison, bufsiz has to be in the range 80000000 to FFFFFFFF (in hex). I ask myself if it is reasonable to have a buffer whose size is apparently somewhere between 2 and 4 gigabytes.

  • Double standard (Score:2, Insightful)

    by bluegreenone ( 526698 )
    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.

    • Re:Double standard (Score:3, Insightful)

      by Builder ( 103701 )
      In this case, HELL YES!

      The patch they provide doesn't solve the problem, they failed to give the vendor any notice and they didn't even work out exactly what is affected. That sounds a lot like uninformed and questionable to me.
    • So your company publicizes a bug for IIS, you're a hero. Publicize one for Apache, you're now "uninformed and questionable"? Geez.

      I assume you're new to /.? You're in for a long ride my friend...

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

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

    by Builder ( 103701 ) on Monday June 17, 2002 @05: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!
    • you're a bunch of immature mornons
      the middle 'n' should be an 'm'. No harm done, however, ;)
    • Your post makes me wonder: would you still be so worried if you didn't know about the vulnerability? I mean, if ISS had waited, the vulnerability would still be there, and all your servers would still be hackable, but you would be sleeping like a baby. And perhaps there is an ever bigger, more dangerous vulnerability in Apache or in some other program that you use, but you don't even know about it yet. If you suddenly become so paranoid when you hear about a vulnerability, how can you not be just as paranoid when you don't know specifically about a bug, but can be reasonably sure that it's there? I'm just wondering.
      • The problem is that when the vulnerabilities are announced, every script kiddie in town gets on the wagon and starts trying to pull servers down. If ISS hadn't announced the vulnerability, yes it would still have existed, and yes, I would still be sleeping at night.

        Every time a new vulnerability is announced I start seeing the scans at our firewalls. FTP vuln -> shedloads of attempts at port 21 of every IP we answer for, even though we don't run any public facing FTP servers. Same for the SNMP vuln and every time a new IIS malformed string attack happens, we start to see it in our logs.

        At least let us patch before telling the kiddies that we're possibly open to bad things :(
  • 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.

  • Too good (Score:3, Funny)

    by selectspec ( 74651 ) on Monday June 17, 2002 @05: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?

  • 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 (Score:2)

      by shogun ( 657 )
      Well about the only way you could realisticly disabled chunked encoding off the top of my head is force the server to only support HTTP 1.0 rather than HTTP 1.1 with a directive such as:

      BrowserMatch "*" downgrade-1.0 force-response-1.0

      Chunked encoding is generally used by HTTP 1.1 when the server does not know the total size of the data to be sent, ie dynamic cgi's and the like and will just keep sending it in chunks until it is all sent.

      • Well about the only way you could realisticly disabled chunked encoding off the top of my head is force the server to only support HTTP 1.0 rather than HTTP 1.1 with a directive such as:

        That's wrong. The bug involves chunked encoding on requests, not responses.

        • Re:IIUC (Score:2)

          by shogun ( 657 )
          Really? Maybe I should take a closer look at the advisory, I didn't know that chunked requests were even possible. Everyone else disregard my above suggestion. (Unless you really want to turn off chunked responses for some other reason) ;-)

  • Some more data (Score:3, Interesting)

    by Florian Weimer ( 88405 ) <fw@deneb.enyo.de> on Monday June 17, 2002 @06: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 .)

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

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

    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 @06: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
    ----

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

    by dananderson ( 1880 ) on Monday June 17, 2002 @07: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] ]

  • 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..."
  • would be if Slashdot was hacked and this is the story that the hackers came up with :)
  • IIS remote code exploits every day, and in all this time all we ever see for apache is a potential Deinal of Service.

    Nice :)
  • 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...

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

    by dananderson ( 1880 ) on Tuesday June 18, 2002 @06: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]

    • Try ./configure --force --with-apache=/your/path/to/apache/src

      Rolf is pretty good with quick patches. I would just wait a day or two. The bug is only a DOS, for most platforms it seems.

Slashdot Top Deals

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Close