Apache 1.3.26 and 2.0.39 Released

cliffwoolley writes "The Apache Software Foundation has released new versions of both Apache 1.3 and 2.0. These versions are both security and bug-fix releases. They address and fix the issues noted in CAN-2002-0392 [CERT VU#944335] regarding a vulnerability in the handling of chunked transfer encoding. You can download the new releases here." This of course is for the exploit that we reported yesterday. It is hard to complain about a 24-hour response time for a bug.

Comments

24 is nice...

[jeffy124]

... but it certainly would've been better if ISS had allowed it, or even writeup a proper patch or give the right info on who's vulnerable.

Personally, their argument about not contacting the Apache Foundation because some of them work for Red Hat is complete bullshit, plus the fact that they could've contacted CERT about it instead. CERT would've made sure RH didnt take credit, since that's among ISS's fears, and also would've told them that the issue was known and being worked on.

Re:24 is nice...

[Verizon Guy]

Sure, we could say that, but if they exploit never went public, would the Apache group have sat around with their thumbs up their asses doing nothing? IOW, I think that if it never went public, we certainly wouldn't have seen a patch today. I mean, Apache has known about this for months --- another developer secretly exploited it for the Apache folks. I think sometimes you need the extra kick in the behind to get those patches out. I'm 100% convinced that if that exploit didn't go public yesterday, we wouldn't have a patch today. Yet in all that time, hackers could have been exploiting all those Apache servers on the net... which according to Netcraft is the most popular Internet web server.

Strangely enough, I think we can all safely tell the zealots now to go fuck themselves when they cite "security by obscurity" against Microsoft, as it seems like it's an epidemic in the Open Source community as well. Only reason Microsoft patches take a lot longer to go public is that since they're not a loose band of hackers like most open source projects, they can't just go out and release a patch---it has to be subject to all sorts of corporate hoopla, like quality testing and that sort. They need to be absolutely sure it doesn't do something like turn your box into liquid shit... they could get SUED big time. If an open source project released a bum patch, who/what is there to go after if something messes up? Nobody. That's where the fundamental difference lies... with open source, there is no organization to go after.

Re:24 is nice...

[Jobe_br]

What makes you think that MS could be sued? They've caused over 8.75 billion dollars of damages to companies and have yet to be sued ... you've read the EULA, right?

$0.02

Re:24 is nice...

[jeffy124]

well, there's something called providing ample time. We dont know how long Apache/CERT knew about the flaw. Apache probably already had the patch ready to go, just wanted to make sure vendors that redistribute Apache (ie, Red Hat, Suse, etc) were aware of the flaw and a copy of the update before going public with it.

But the point of the matter here was that ISS gave Apache virtually no time whatsoever before going public (something like less than two hours), on top of that, going public with a bad patch and incomplete (or incorrect) information.

You are correct however, that turnaround time is much faster in open source systems than closed source because of all the extra CYA stuff that has to take place. It always amazes me that someone would embarass themselves by giving a company less than a day before going public with a flaw, or makes no contact at all. Microsoft asks for 14 days, but I personally feel that 7 is sufficient, even for MS.

Re:24 is nice...

[Tony-A]

Apache exploits are pretty hard to come by these days. Miss this one and it will be a long dry spell until anybody finds another one. Like a media feeding frenzy, rationality seems to vanish. Two hour notice and a broken patch, judging from other posts. ISS comes off looking pretty juvenile. There seems to be some indications that Apache was aware of this from another source, so there is some possibility that ISS jumped the gun to avoid being shunted out of the limelight.

Overall Apache comes out smelling like a rose.

"On the Windows and Netware platforms, Apache runs one multithreaded child
process to service requests. The teardown and subsequent setup time to
replace the lost child process presents a significant interruption of
service. As the Windows and Netware ports create a new process and reread
the configuration, rather than fork a child process, this delay is much
more pronounced than on other platforms."
"... Using any multithreaded model, all concurrent requests currently served by the affected child process will be lost."

Sounds like a good reason to run Apache on Linux/BSD/UNIX.
(Well they did claim that Apache 1.3 wasn't really stable on Microsoft Windows;)

Re:24 is nice...

[Tony-A]

We dont know how long Apache/CERT knew about the flaw. Apache probably already had the patch ready to go, just wanted to make sure vendors that redistribute Apache (ie, Red Hat, Suse, etc) were aware of the flaw
The irony is that it is the vendors of Apache for Microsoft Windows who are most in need of the patch. On 32-bit Linux or BSD seems like it's just a pretty lame DoS attempt. I would expect more trouble from Code Red and friends filling up error logs.

Re:24 is nice...

[jeffy124]

you're darn right about that. Apache users with Windows seem to require direct access to a binary as opposed to the source, meaning that "patch" published by ISS, regardless of correctness, was useless to majority of Windows users. This was among the reasons Apache went to CERT with their info before going public.

You're also right in other post that Apache flaws are few and far between....

Re:24 is nice...

[Anonymous Coward]

well, there are still some people around who are running Apache/Linux on Digital Alpha, which is 64 bits and is vulnerable (anyway, I upgraded to 1.3.26)

Re:24 is nice...

[alan_d_post]

GOBBLES has produced a remote code execution exploit for OpenBSD (published on bugtraq on Thursday). This is serious stuff!

Complaints Timescale

[4of12]

It is hard to complain about a 24-hour response time for a bug.

No, it's not:)

Seriously, though, it's a pretty impressive turn around time and should give some credence to those of us making arguments that the support is really there for open source projects like Apache, even though there's no "1-800-HELPME" number nor an expensive maintenance and support agreement.

Re:Complaints Timescale

[BenTheDewpendent]

so what are you complainging about?

24hours granted there isnt a help line but you just type it in a search engin and you get help for nearly anything oss related.

ms you get tiny bits of obscure help and months for a patch and help costs.

Re:Complaints Timescale

[4of12]

just type it in a search engine...

What are you asking, man! I'd have to learn how to read, write and think to do that.

Can't I just get a warm fuzzy feeling by buying a large support agreement from Microsoft?

Besides, I'll be among a large herd of IIS users - who could possibly know and want to `sploit me with Code Red?

Most buyers at my site are using fradulent credit card numbers anyway, so if the database gets owned it's not all that big a deal.

Re:Complaints Timescale

[JordanH]

• Seriously, though, it's a pretty impressive turn around time and should give some credence to those of us making arguments that the support is really there for open source projects like Apache, even though there's no "1-800-HELPME" number nor an expensive maintenance and support agreement.

You can have your maintenance and support agreement, complete with 24x7 support line, if that's what you need, by contracting with someone like Covalent. Covalent will be providing those patches pretty soon for their releases, it seems.

Re:Complaints Timescale

[Anonymous Coward]

Is this the same Covalent who had the gall to tell me today when I telephoned (before that notice was up) for support on one of their SSL products that they had assessed the vulnerability and it wasn't all that big a problem, as Apache handled it pretty well and the child processes would die off?

When I pointed out that this was exactly WHY I needed the patch, as our webservers are actually important to us and we'd rather not have them DoS'd, she mumbled something about adding us to a alert list for when the patches were ready.

Re:Complaints Timescale

[Anonymous Coward]

When it comes down to it, if someone wants to DoS you, they will. It doesn't matter if this bug is fixed, a determined attacker can still DDoS you.

It does mean that someone at random might have chosen you to DoS because "it was easy" due to the bug. But being a DoS only bug there is no threat of a worm based on it hitting you. The chance of someone DoSing you using this bug are almost nil.

Re:Complaints Timescale

[sidster]

Please note that the apache_1.3.26.tar.gz file was on their server (according to their server) at 11:24 am PDT time!

I had it downloaded and installed on my box at work at about 6pm PDT.

Output from HEAD on apache_1.3.26.tar.gz:

Connected to www.apache.org.
Escape character is '^]'.
HEAD /dist/httpd/apache_1.3.26.tar.gz HTTP/1.1
Host: www.apache.org

HTTP/1.1 200 OK
Date: Wed, 19 Jun 2002 04:00:49 GMT
Server: Apache/2.0.39 (Unix)
Cache-Control: max-age=86400
Expires: Thu, 20 Jun 2002 04:00:49 GMT
Last-Modified: Tue, 18 Jun 2002 18:24:15 GMT
ETag: "cbbee-2324ab-73a911c0"
Accept-Ranges: bytes
Content-Length: 2303147
Content-Type: application/x-tar
Content-Encoding: x-gzip

Connection closed by foreign host.

24 Hour Response Time

[PeekabooCaribou]

It is hard to complain about a 24-hour response time for a bug.

I think this is the real advantage of OSS. It's people that make Apache, not some group of nameless programmers in a high-rise somewhere. The Apache programmers use Apache on a daily basis, so they stand to gain just as much as the rest of us do by releasing a quick fix. I honestly think they care about making it a good, bug-free product. I put much more trust into the open-source projects than I do for any closed source commercial package.

Re:24 Hour Response Time

[Anonymous Coward]

24 hours plus whatever time it takes the distros to vet it, package it and make it available to their users...

Re:24 Hour Response Time

[Anonymous Coward]

Actually, when I worked at Microsoft several years ago, upper management sent out an email requesting everyone use IIS and other MS products as opposed to Linux, Apache and other OSS.

The letter claimed it looked bad to MS customers and partners when MS was internally using non-MS products.

There are a lot of people at MS that would rather use Apache, Linux, etc., but they aren't allowed to anymore.

As for MS employees being human - I knew a couple that were. Most were arrogant bastard robots.

Win32 MSI Installer Broken

[tyrione]

Downloaded a moment ago and the package is broken so I reverted to downloading the bloated non-msi executable and it works just fine.

Re:Win32 MSI Installer Broken

[cliffwoolley]

Can you be more specific? Which installer (2.0.39 or 1.3.26)? What exactly happens?

Re:Win32 MSI Installer Broken

[tyrione]

2.0.39 Installer fails.

It launches console batch window and then closes rapidly.

My guess is its an incomplete build, thats all.

Re:Let's not forget...

[jimjag]

Your statement would be right on the mark, if it had the advantage of being based on fact. The "fix" you refer to is not, and was not, the actual correction, since the bug itself was more involved than that.

But thanks for playing! Better luck next time!

24 hour response?

[xswl0931]

Doesn't anyone actually read the articles anymore? Apache was aware of the issue before ISS posted their advisory.

Re:24 hour response?

[Coyote67]

I'm glad someone finally said it. And people say windows users are mindless sheep. Insert flamebait msg here.

24 Hours - unreasonable and dangerous

[Anonymous Coward]

Givng Apache 24 hours to make a bug fix imposed an unreasonable deadline, and also encouraged the fix to be quick and dirty. Any time code is patched, it could cause other bugs to show, or introduce new ones. Developers need a certain amount of time to do testing once changes are made to make sure they didn't break anything! Kudos to the apache developers for meeting the deadline, but anti-kudos to (i'm not sure who) those imposed it.

Re:24 Hours - unreasonable and dangerous

[buffy]

Givng Apache 24 hours to make a bug fix imposed an unreasonable deadline, and also encouraged the fix to be quick and dirty. Any time code is patched, it could cause other bugs to show, or introduce new ones. Developers need a certain amount of time to do testing once changes are made to make sure they didn't break anything! Kudos to the apache developers for meeting the deadline, but anti-kudos to (i'm not sure who) those imposed it.

You kind-of missed how this went down. Nobody "imposed" a 24-hour window for the bug to be fixed. Had IIS not been a bunch of boneheads and prematurely (as in ejaculation) released information regarding the vulnerability, the programmers involved could've taken a little bit more time to develop the fix, ensuring better quality.

The commendations re: the 24-hour turn around is simply referencing the ability of a lose-knit group of open source programmers to rapidly respond to a bad situation. Had Microsoft been in the same spot (they have been before--people have screwed them, too--and they most certainly will be again) it still would've taken them a lot longer to kick out the fix, and even longer to get it into their distribution channels.

Folks at ISS

[Anonymous Coward]

ISS is full of shit. They have no respect for the way things work. Due to being connected with the security team of my company, I knew about the bug for a few days. And also that the Apache group was working to correct it. But not, the pricks at ISS had to release it with a whopping two hour notice, not only that but they released a broken patch.

And on top of all of that their stock goes up. What a crock of shit.
</rant>

Re:Folks at ISS

[Anonymous Coward]

What you forget is that last week Apache was still vulnerable. And what many also forget is that this vulnerability was still out in the open. ISS just changed the source code into English, so many other people could understand it.

"But.." I hear you cry, "It doesn't work like THAT!" Yes it does. It's called "OPEN source" for a reason, now. Sheesh, we can't go along secretly wanting security through obscurity when we have a campaign for openness. What sheer hypocrisy.

Re:Folks at ISS

[Anonymous Coward]

Bullshit. Security through obscurity is never acknoledging a problem. Security through proper means includes working with vendors so that the "black hat" community doesn't have a 24 hour window to exploit a vulnerability before you can fix it.

The apache group was within days of releasing the advisory and fix when ISS decided they were all high and mighty.

The way it "works" is, you alert the vendor (in this case apache) and ask how much time it will take to fix. The vendor responds with a valid estimate. If this estimate is out of line (say 3 months) then you don't have a choice but to release. If the estimate is reasonable, a couple of days to a couple of weeks (depending on the flaw), you hold off on the announcement and work with the vendor. 2 hours is NOT appropriate. Saying "Red Hat" can't be trusted is NOT appropriate. Saying "Mark Cox" can't be trusted is NOT appropraite. etc.

The folks at ISS were trying to prove they were better then everyone else, and be damned everyone who has a copy of apache.

Re:Folks at ISS

[Anonymous Coward]

Bullshit. Security through obscurity is never acknoledging a problem.

Bullshit indeed. Like Microsoft not announcing Code Red way before it was a problem. I think ISS simply exposed the hypocrisy of the community and hurt their poor little egos. Kudos to them. They have the balls to stand up and say certain factions are full of shit.

The way it "works" is, you alert the vendor (in this case apache) and ask how much time it will take to fix. The vendor responds with a valid estimate.

ha! You're a funny one. There are no "vendors" in open-source land. Apache might be the development team, but their development is still OUT IN THE OPEN! Anyone can gain access to their mailing lists. If ISS didn't report it, Slashdot _would_ have (if they knew about it, of course). Infact, Slashdot _contributed_ to the "problem" you and everyone else was bitching about. They passed on the information that a very small and unheard of organization announced. Most people would never have heard of ISS if Slashdot didn't post about it.

There is a very hard fact that no one wants to admit: APACHE WAS VULNERABLE LAST FUCKING MONTH. And THE MONTH BEFORE AND THE MONTH BEFORE AND THE MONTH BEFORE AND THE MONTH BEFORE AND THE MONTH BEFORE! Who CARES if ISS announces something when a patch is about to come out. EVERYONE WAS VULNERABLE ALREADY! The Bad Guys already knew about it and were on their merry-exploiting-way.

Go back to your hypocrisy.. I know you will.

Re:Folks at ISS

[Anonymous Coward]

This isn't exactly the first time some of the boneheads at ISS did something blatantly dumb. I remember a story a little while back about them nearly getting kicked out of a trade show for hacking into competator's machines. One of their other competators picked it up on a network intrusion machine they were demoing!

RPMs?

[Anonymous Coward]

Okay, I'm a lamer, I'd rather do a "rpm --rebuild" than whip it up from scratch.

Does anybody know where a 2.0.39 RPM is available?

Re:RPMs?

[CyberPhunk]

I'll probably be moded down for saying this, but is it THAT hard to type:
./configure
make
make install
???

Even if you did ./configure --prefix=/usr/local/apache-1.3.26 you could still easily copy over the confs from your last installation! I just updated 8 servers within an hour, and it wasn't hard at all.

Close your eyes, make the problem go away

[Fastball]

Props to the Apache team for a quick and thorough fix. Now this, THIS is what I call quality control and customer service. This outruns and outguns Microsoft's see no evil, speak no evil policy on security hotfixes. Hands down.

Re:Close your eyes, make the problem go away

[Anonymous Coward]

what are you talking about? microsoft issues security hotfixes all the time, and theyre tested better than this "24-hour" turnaround too.

Re:Close your eyes, make the problem go away

[Anonymous Coward]

You're missing the point, MicroDroid. They issue a security hotfix months after people have found ways to exploit it. It's like plugging the dam after the river bursts through. I will say that *lately* they've been issuing a few more patches here and there, but then again they've got XP in the wild now so it's fitting.

New mod_ssl?

[doughmein_dot_net]

Anybody know when an updated version of mod_ssl will be released for this latest release of Apache? I know it's probably too soon to ask, but the mod_ssl homepage (http://www.modssl.org) still shows version 2.8.8 for Apache 1.3.24.

Or will this old version patch successfully against the latest Apache release? I haven't tried mixing versions.

Re:New mod_ssl?

[JediTrainer]

It's there now. Make sure you reload the page.

I'm already running it in our staging environment, to test it before loading the whole kit-and-caboodle to our production servers.

mod_ssl?

[Phroggy]

Anyone know the status of mod_ssl for 1.3.26?

Re:mod_ssl?

[jonabbey]

mod_ssl is baked into the Apache releases 2.0.35 and later, and is _far_ easier to compile and install than the old Apache 1.3 + external mod_ssl was.

Get to Apache 2.0.x when you can.

Re:mod_ssl?

[Jobe_br]

I tried checking their site, but it appears down - a few mirrors I found online didn't show any sign of a 1.3.26 release and the ftp.modssl.org site didn't show any 1.3.26 tarball under 'source' ... so, in short, not yet, I guess.

Too bad - I was going to update everything tonight, but I cannot without mod_ssl.

Re:mod_ssl?

[accessdeniednsp]

Argh..I posted a comment but it was replied to the wrong thread by accident. Crap.. Anyway, here's what I had to say. Hope it helps. (I hope I'm not going to get flamed for anything on this but I probably will).

Me and woolley chatted on irc tonite and i verified his patch [theaimsgroup.com] does indeed work. You will have to manually adjust apache_1.3.26/src/ap/Makefile.tmpl to add the three object files to line 7:

ap_hook.o ap_ctx.o ap_mm.o

The patch will cause a rejection due to modifications between 1.3.24 and 1.3.26 to the file.

The patch applies to apache-1.3.24, btw. And be sure to use mod_ssl-2.8.8-1.3.24 and add --force on the mod_ssl configure line.

Woolley's patch works great.

Re:mod_ssl?

[MadAhab]

Oh, shit, --force. Thanks for posting something actually useful (and you won't get karma for it so just don't start whining ;-)

Actually Useful and Intelligent +0

Re:mod_ssl?

[Spoke]

Would love to, but support for many modules including PHP is flaky at best at this time.

Re:mod_ssl?

[haeger]

Unfortunatly this isn't an option for all. I'll migrate to 2.X whenever possible, but until all PHP-odditys with the 2.X version is worked out I'll stick with my trusty 1.3.X version.

There are actually some valid reasons not to upgrade sometimes.

.haeger

Re:mod_ssl?

[tuxzone]

No need to go 2.0.x for modssl, go to http://www.delouw.ch/linux/Apache-Compile-HOWTO/ht ml/apache.html for a patch to use the 1.3.24 mod_ssl release.

Rene

Re:mod_ssl?

[mrkitty]

Mod_ssl for 1.3.26 is released http://www.modssl.org/source/mod_ssl-2.8.9-1.3.26. tar.gz In case anyone wanted it.

good job, but the work is not done

[Rubbersoul]

First I must say good work the the apache team, but the must stop and remind everyone the work is not done. Now this patch needs to be applied to all affected systems, now it is time for the SA's and the what not of the world to step up. Lets not forget this fact because even MS releases patchs sooner or later (ok later), but it seems that many boxes stay effected for ever due to bad admining on said MS box(en).

*NIX is in the clear.

[red5]

This advisory is for the multi-threaded version on apache only. So sites running 1.3.x on *nix are unaffected.

Had me worried there for a minute as I admin quite a few of those.

Re:*NIX is in the clear.

[Anonymous Coward]

According to Apache's own advisory, *NIX platforms are vulnerable. They are not remotely exploitable, but child processes can be forced to quit unexpectedly, potentially causing a DoS.

Re:*NIX is in the clear.

[accessdeniednsp]

Me and woolley chatted on irc tonite and i verified his patch does indeed work. You will have to manually adjust apache_1.3.26/src/ap/Makefile.tmpl to add the three object files to line 7:

ap_hook.o ap_ctx.o ap_mm.o

The patch will cause a rejection due to modifications between 1.3.24 and 1.3.26 to the file.

The patch applies to apache-1.3.24, btw. And be sure to use mod_ssl-2.8.8-1.3.24 and add --force on the mod_ssl configure line.

Woolley's patch works great.

Re:*NIX is in the clear.

[xtremex]

Just updated Apache on my Solaris Box from Source.
Took about about 10 seconds to install. SHutdown apache, make install, start apache.
That was easy!

Re:*NIX is in the clear.

[yem]

32 bit unix that is.

Quoth the advisory:

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.

Re:*NIX is in the clear.

[Micah]

well it takes a bit longer when you have mod_perl, php, and mod_gzip to compile into it. Heading off to do that now....

Re:*NIX is in the clear.

[red5]

Multiply that by like 25 and you have my day.
That and we hack our src/include/httpd.h file to up the HARD_SERVER_LIMIT to 1024.

Re:*NIX is in the clear.

[Bio]

What I did was:

Copy the config.status from the old apache install directory.
Copy modules (I have 'fastcgi' and 'php4') in src/modules from the old directory.
Call config.status, type 'make'.
Make a backup copy of the old httpd
Type 'make install'
'apachectl stop' and 'apachectl start'

This worked (for me).

Re:*NIX is in the clear.

[Tony-A]

Just try that in Microsoft Windows.
Webserver downtime what? About 10 or 15 seconds, I'd guess.

Copy the config.status from the old apache install directory.
Copy modules (I have 'fastcgi' and 'php4') in src/modules from the old directory.
Call config.status, type 'make'.
Make a backup copy of the old httpd
Type 'make install'
'apachectl stop' and 'apachectl start'

Ok, ok, I'm a newbie and still not quite used to the idea of replacing a program while it's still running. Kudos on the ordering of the steps. Murphy's Law might get the better of you, but it will have to work pretty hard to do it.

Re:*NIX is in the clear.

[bill_mcgonigle]

potentially causing a DoS

That's almost the same as 'just fine' with Apache.

I came up with a remarkably simple DoS exploit vs. Apache last year, and the Apache guys basically said, 'well, geez, that sucks, but we'd have to rearchitect Apache to prevent it, so...'. And that's for something that could take down any Apache server with a very lightly distributed DoS.

The way to deal with DoS is with active monitoring; we're never going to have all the possible DoS's fixed in any product.

Re:*NIX is in the clear.

[xtremex]

Does Apache Toolkit work on Solaris? I've used it on Linux, but never on Solaris..I don't think it would since it uses RPMS...correct me if I'm wrong

Re:*NIX is in the clear.

[RobNich]

Although you can replace the binary while it is running, it won't save you time. This will:

apachectl stop; make install; apachectl start;

Debian Woody

[pkplex]

Any idea when the fix will be in the woody packages?

Re:Debian Woody

[alfaiomega]

Any idea when the fix will be in the woody packages?

What the hell?! You need this fix in a wooden package?! With cockade and stuff? Would the express FedEx delivery be OK, Your Majesty? Can't you just download it from the 'net like other people?! Geez...

Re:Debian Woody

[pkplex]

Take your pills, man.

Re:Debian Woody

[Afrosheen]

What the hell is Cockade? Is it gatorade for roosters or what? Nuttier than something I flushed yesterday, this one.

Re:Debian Woody

[peterpi]

Quite funny (well, not funny actually) that this reqest is just underneath a post saying:

"Now this patch needs to be applied to all affected systems, now it is time for the SA's and the what not of the world to step up"

An ill administered *nix box is much more useful for a hacker than an ill administered Windows box.

To pkplex; it is your responsibility to the public internet to go fetch a copy and compile it yourself. If you're new to that, then don't worry, it's not too difficult, and there are plenty of HOWTO's etc on the web.

CERT got it slightly wrong?

[Jobe_br]

I'm not sure, since I don't closely follow CERT myself - but an acquaintance e-mailed me the CERT advisory today and I noticed that the 1.3.x version of apache it cites is not 1.3.26 - its 1.3.25:

Upgrade to the latest version

The Apache Software Foundation has released two new versions of Apache that correct this vulnerability. System administrators can prevent the vulnerability from being exploited by upgrading to Apache version 1.3.25 or 2.0.39.

I noticed that a 1.3.25 doesn't actually exist anywhere ... was there a failed release?

Re:CERT got it slightly wrong?

[yem]

I noticed that a 1.3.25 doesn't actually exist anywhere ... was there a failed release?

Yes that was a tad premature. In the end 1.3.25 was abandoned and they went straight to 2.3.26.

Re:CERT got it slightly wrong?

[yem]

gah!@ normally I wouldn't bother, but that should read:

.. and they went straight to 1.3.26.

Re:CERT got it slightly wrong?

[Builder]

CERT didn't get it wrong, things changed.

The Apache team told CERT that the next 1.3 version would be 1.3.25. This was the plan right up until a couple of hours before release. At this point, 1.3.25 was up for testing, and for some reason (I'm sure it was a good one), 1.3.25 was abandoned and they went to 1.3.26. I'm sure that the changelog will reveal all.

Re:CERT got it slightly wrong?

[Jobe_br]

Indeed, apparently one last thing needed to be done to fix the CERT advisory bug:

Changes with Apache 1.3.26

*) Potential NULL referencing fixed in the CGI module. It had
been there for 5 years. [Justin Erenkrantz]

*) Ensure that we set the result value in ap_strtol before
we return it. [The whole gang again]

Changes with Apache 1.3.25

*) Code changes required to address and close the security
issues in CAN-2002-0392 (mitre.org) [CERT VU#944335].
To support this, we utilize the ANSI functionality of
strtol, and provide ap_strtol for completeness.
[The whole gang]

[many other 1.3.25 changes snipped]

Re:Let's not forget...

[Anonymous Coward]

so are you claiming that the bug fix took a full 24 hours to complete? face it, the other poster had a point: turnaround times are limited by other things than coding.

See, I told you so.

[rice_burners_suck]

Need I point out my earlier comment? I'll save you the trouble of looking it up:

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.

I believe it was Dark Helmet who once said, "Evil will always triumph because good is dumb." But in the case of software, it's pretty clear that free will always triumph because commercial is dumb. Honestly, software developed out of a desire to:

• Learn,
• Do good,
• Have fun in the process...

is simply going to be better software than something that's developed out of the runaway greed rampant in the inferior competition.

Re:See, I told you so.

[Anonymous Coward]

How did this karma-whoring hippie get modded up? What anti-capitalist bullshit, I must say. Whenever we hear word of a Microsoft exploit (i.e. a single bug in their ENTIRE SOFTWARE CATALOG) it usually comes from what source? MICROSOFT! Code Red was announced by Microsoft _months_ before Slashdot got word. You can't force users to upgrade. If you want to judge affects of security breaches (such as Code Red's continued influence) then *ix history has a much longer and brutal history of damage done.

*ix is the reason your credit card will be stolen over the internet. *ix is the reason your web site is experiencing a DoS/DDoS. *ix is the reason your passwords are sniffed by a machine very close to yours. You want _true_ security? Avoid *ix. That fuckin' simple.

Re:See, I told you so.

[Anonymous Coward]

> Whenever we hear word of a Microsoft exploit
> (i.e. a single bug in their ENTIRE SOFTWARE
> CATALOG) it usually comes from what source?
> MICROSOFT!

You obviously don't read bugtraq.

> If you want to judge affects of security
> breaches (such as Code Red's continued
> influence) then *ix history has a much longer
> and brutal history of damage done.

Unix has been around a lot longer.

And what the hell does *nix have to do with continued Code Red activity?

Re:See, I told you so.

[Anonymous Coward]

You illiterate moron.

Q: The majority of (OS-centric) bugs on bugtraq are for what OS?
A: A Unix flavor.

Unix has been around a lot longer.

No fuckin' way! Thank you for pointing out the pathetically obvious.

And what the hell does *nix have to do with continued Code Red activity?

If you want to compare Microsoft security issues with *ix, then you better back it up.

Microsoft's worst damage done via security breach: Code Red.

*ix worst damage done via security breach: thousands of credit card numbers stolen, denial-of-service and distributed denial-of-service. *ix security breaches alone account for the majority of all network interruptions (minus legit technical problems).

You obviously haven't done your homework. Bad student, bad!

Re:See, I told you so.

[Anonymous Coward]

Dork. If it weren't for Unix, the internet you're using right now likely wouldn't exist.

Bow down! UN1X 0wnzj00!

You are correct.

[red5]

Well at least it's only a DoS.

Looks like it's going to be a long night. :(

PHP now broken?

[Zeekamotay]

Oh sweat. Is this just me, or does 1.3.26 break PHP? I recompiled PHP 4.2.1 from source, but I still get this message when trying to start Apache:

API module structure `php4_module' in file /usr/local/apache/libexec/libphp4.so is garbled - perhaps this is not an Apache module DS
O?

Re:PHP now broken?

[Anonymous Coward]

Dude, get off the PHP training wheels and into a real language -- perl, python or (gasp) java if you're looking for scripting. For hard-core coding, go with C.

Re:PHP now broken?

[sidster]

Trolls like you obviously don't know the benefits of using the right tool for the particular task at hand.

• Php and html mix exteremely well.
• It is very easy to extend php if you needed to.
• Tons of interfaces are available from Php
  • GD
  • PostgreSQL
  • MySQL
  • PDF
  • ... shall i go on?
• Php is very well documented.
• If you know C and Perl then Php becomes second nature.

You probably use a hammer for all your tasks.

• Hammering a nail into the wall
• screwing in a light-bulb into the socket
• etc ...

Re:PHP now broken?

[Micah]

odd. I just recompiled everything and:

Server: Apache/1.3.26 (Unix) mod_gzip/1.3.19.1a mod_perl/1.27 PHP/4.2.1

Tested most of my sites and everything seems to work just fine, including PHP sites that use PostgreSQL.

Re:PHP now broken?

[Anonymous Coward]

Make sure you delete the config.cache before running make clean and make install.

Re:PHP now broken?

[zadkat]

Word, dude. Delete the config.cache , make clean, make install and life is good. Where I had fun was pulling out the SSL references. Somehow c-client.a in /usr/local/lib/libc-client.a was in the mix and cause I had *that* compiled with SSL support make for Apache was dying, IMHO, that is. Recompiled imap-2001a and php all from source and I'm happy again (er... well.. SSL support will be better, but not in as big a rush)

Re:PHP now broken?

[melloncollienet]

100% correct (although PHP does seem like cheating at times, it seems that PHP was designed for a web-based environment - whereas perl was not).

Re:PHP now broken?

[jmertic]

The php4apache2.dll module with PHP 4.2.1 won't work at all with the 2.0.39 server. Comes up with an error that the module isn't for this version of Apache. Once that LoadModule is commented out, all works fine.

Re:PHP now broken?

[oldave]

I have yet to get php4.2.x to work properly with Apache 1.3.x under Solaris 8 or 9, and last night's release is no exception.

It all compiles fine - but php simply won't pass form variables, even in a $PHP_SELF.

Have had to stay away from 4.2.x until I can get around to going to Apache 2.0.x

Re:PHP now broken?

[Zeekamotay]

PHP now has register_globals turned off by default -- don't you remember those big compile-time warnings that said, "PHP NOW HAS REGISTER_GLOBALS OFF BY DEFAULT!" :)

What you're seeing is correct behavior. You need to either use the $_SERVER, $_GET, and $_POST variables or set register_globals=on in your php.ini file.

Re:PHP now broken?

[Zeekamotay]

Yah, I use "make distclean" before each compile -- that inherently removes the cache file. The same update on three other machines worked just fine though, so there's something funky going on with this particular one. Perhaps it's time for some... as my buddy Tom says... percussive maintenance. :)

Re:PHP now broken?

[Tony-A]

"PHP now has register_globals turned off by default"
This is to prevent malicious browsers from setting what are supposed to be program variables. info.php as <?phpinfo()?%gt is your friend.

Re:PHP now broken?

[Tony-A]

You are right that PHP was designed for a web-based environment. PHP originally stood for Personal Home Page.
To turn your html into php, just change the .html to .php
Embed your programming in <?php and ?> tags.
All variables have a $ prefix.
Somehow they managed to NOT screw up the language design. PHP4 is good!
Access to APIs such as sql servers is through native calls, rather than attempting some kind of worst common denominator.
Arrays are comparable to Perl Arrays and or Hash, simultaneously. Very handy for result sets which are accessed by name and/or column name, simultaneously.

Same experience here, had to regress PHP

[Akardam]

I regressed to PHP 4.1.2 (the last version that I used sucessfully), and as soon as I did that, it worked like a peach. Perhaps it's a PHP problem; I never used PHP 4.2.x with Apache 1.3.24, so I don't know.

Any other /.ers have this experience?

Re:Same experience here, had to regress PHP

[Anonymous Coward]

I had PHP 4.2.1 up fine with 1.3.24. I was just waiting for a newer mod_ssl before I upgraded Apache to 1.3.26. Now I guess I may need to wait for a newer PHP, too.

Re:Same experience here, had to regress PHP

[Anonymous Coward]

I after i installed apache_1.3.26 i was hoping that i would not need to rebuild php.

But doing apachectl configtest i got the warning about apache not liking the libphp4.so (php 4.1.2).

I went ahead and downloaded php4.2.1 and built it from source and everything went smooth from there on.

My sites (.php sources) all run fine now. Though i did notice that with php.ini-recommended there were a ton of E_NOTICE errors being logged in apache's error_log about accessing index in array that doens't exit.

Things like:

$arr = array()
// ...
if ( $today == "monday" ) {
$arr['excuse'] = 'Sick Day';
}

// later in the code if you tried to access
// the above index in $arr and it wasn't monday
// you get the warning!

// This check causes the waring believe it or not :-)
if ( $arr['excuse'] ) {
call_boss( $arr['excuse']);
}
else go_to_work();

I had to modify php.ini to make it quite down.

--sidstah!

Re:Same experience here, had to regress PHP

[Zeekamotay]

Well I added the newly updated mod_ssl, and it worked fine. Don't know if that was the difference, or something else I had been fiddling with. I'm ok now though, so I'm going to poke around anymore.

It's in the Name

[akiy]

It is hard to complain about a 24-hour response time for a bug.

How can you? It's called "A Patchy" server, after all.

Re:24 Hour Response Time - a thought

[q-soe]

Well i think the 24 hour response time is a good thing.. However to play devils advocate for a second - if Microsoft had resolved an issue (i know stop laughing and read on) in 24 hours would it have been posted on here in this manner?? I suspect it would have had a different slant to it...

I only ask this in the light of the fact that ALL software has bugs and issues and exploits but all software eventually gets patched - I find open source more responsive in some cases and worse in others - its not a given that something will get fixed every time faster but on average it is - this is an advantage of open source software for me. The disadvantage of course lies in people who claim open source software never has a bug or exploit at all - all software HAS these things but some softwqare gets fixed faster than others.

Good one to the apache team.

FUD

[Vainglorious Coward]

This of course is for the exploit that we reported yesterday

Um, surely you mean vulnerability ?

Re:FUD

[GrenDel Fuego]

That's not fud, it's stupidity.

24 hours?

[Anonymous Coward]

umm... The bug wasn`t fixed in 24 hours!

The apache coders have known about it for a while now, but it was only ISS going public early that forced the quick release of the patch before full testing!

Still good that we didn`t need to wait a few weeks for the update though! :)

freebsd ports...

[smash]

Semi relevant.... upgrading my freebsd 4.6 box to apache 2.0.39 of course required recompiling php.

installing php 4.2.1 from ports again, it dies with:

Making all in apache2filter
/bin/sh /usr/ports/www/mod_php4/work / hp-4.2.1/libtool --silent --mode=compile cc -I. -I/usr/ports/www/mod_php4/work/php-4.2.
1/sapi/ap ache2filter -I/usr/ports/www/mod_php4/work/php-4.2.1/main -I/usr/ports/www/mod_php4/work/php-4.2.1 -I/usr/local/inclu
de/apache2 -I/usr/ports/www/mod_php4/work/php-4.2.1/Zend -I/usr/local/include -I/usr/local/include/mysql -I/usr/ports/www/mod_
php4/work/php-4.2.1/ext/xml /expat -D_REENTRANT -D_THREAD_SAFE -I/usr/ports/www/mod_php4/work/php-4.2.1/TSRM -I/usr/local/incl
ude/pth -O -pipe -march=pentiumpro -I/usr/local/include -I/usr/local/include/pgsql -pthread -DZTS -prefer-pic -c php_function
s.c
php_functions.c:93: syntax error
*** Error code 1

Anyone else have the problem?

thanks in advance ;)
smash.

Re:freebsd ports...

[Anonymous Coward]

Well, I just used portupgrade to upgrade Apache. So no need to recompile PHP. Everything seems to work ok. I probably will encounter problems with PHP (because something should be wrong if it doesn't compile anymore, isn't it?! :P), but for now it works for me this way. :)

Re:freebsd ports...

[Anonymous Coward]

Never mind. I upgraded Apache 1.3.x nog Apache 2.x, so maybe it doesn't work for 2.x...

Re:freebsd ports...

[Anonymous Coward]

I got the same error compiling PHP 4.2.1 under Linux. That file (php_functions.c) uses the MODULE_MAGIC_AT_LEAST macro to check the Apache module version, and it seems that that macro has been deprecated (actually, killed) in Apache 2.0.39. The gory details are in:

$(APACHE_DIR)/include/ap_mmn.h

It seems like the equivalent macro in 2.0.39 is AP_MODULE_MAGIC_AT_LEAST. I've edited php_functions.c to change it and then it compiled without a problem.

You are using FreeBSD, so I think you have two options:

- cvsup the ports collection. Perhaps the port mantainer has write a patch.
- Compile PHP without using the port mechanism of FreeBSD.
- Wait for PHP to release a fixed version.

Good luck!

Re:freebsd ports...

[smash]

Thanks heaps, I was wanting to confirm - still new to freebsd (used linux heaps) and wanted to make sure its not just my box being broken ;)

This machine hasn't actually been comissioned yet, so I think I'll just cvsup ports again tomorrow and it should most likely be sweet :)

Thanks again...

That will teach you...

[mikolajl]

...to never work during the weekend.

The weekend is for relaxing ;-)

Not up to industry standards

[return 42]

Geez, how unprofessional. They knew about the vuln, they were working on it, then someone stupidly spilled the beans and they had to pull an all-nighter so their users wouldn't be exposed any longer than necessary.

Anyone knows that a real, professional company would sit on the vuln report for a few weeks, until the finder got fed up and went public with it, then they'd complain about irresponsible disclosure and take two weeks to release a fix.

chunked bug

[apach_user]

hmm. the new version of the apache advisory doesn't mention ISS's "faulty" patch. retraction? http://httpd.apache.org/info/security_bulletin_200 20617.txt

Apache design handles bugs better

[Anonymous Coward]

Two ways of thinking:
1. Assume we can make it 100% secure, and then give it system privs.
2. Assume we will make mistakes, and make it run with reduced privs.
It is not a matter of who can make a more secure product. It is nice when something is designed with the assumption that the software, like all software, will have holes.

Security is a process, not a product. I like the direction Open Source is taking. Apache runs as a regular user. Bind runs as regular user. Postfix, Qmail, and the newer SSH from the OpenBSD team are designed with flaws in mind.

When Open Source products get slammed enough times, they change models. Some companies never learn.

2.8.9 (apache 1.3.26) out now

[TomatoMan]

It's at modssl.org. Thanks, Ralph!

Makefile is missing

[macdaddy]

Did anyone else notice that the Makefile is missing from the 1.3.26 release? I can't find it anywhere. I was going to upgrade real quick but this rather important piece of the puzzle is missing.

Actually...

[SuiteSisterMary]

It is hard to complain about a 24-hour response time for a bug.

Actually, it's easy. Watch. Gee, I wonder what sort of regression testing they did. Or anything along the lines of QA, other than 'it compiles with only warnings.'

Re:Actually...

[Anonymous Coward]

Duh.... you think the apache team is a bunch of novice programmers don't you....

I'm sure they have a complete test suite to do just what you wonder.

So how are things in Redmond?

Re:Actually...

[jimjag]

It was actually during the QA testing, using httpd-test, that we discovered the bug in 1.3.25 that resulted in 1.3.26

How is that insightful?

[dave-fu]

They original poster probably has very good reasons for using Apache 1.3.
If I take my car to the mechanic for a tune-up, the answer I'm not looking to hear is "forget about the tune-up. why don't you just buy a BMW M1?". In the meantime, I've got an otherwise perfectly fine car just like the original poster likely has a perfectly fine setup (perhaps with apps built and tested under Apache 1.3) and the latest and greatest isn't the answer for them.

Re:How is that insightful?

[jonabbey]

Sure, of course. I did say 'when you can'. And it is far easier to compile and link with a 2.0.x version than it was with 1.3, being as it does come with mod_ssl, and all of the build scripts are integrated.

There is a lot that doesn't yet go so well on 2.0.x, mostly in the form of third party modules that have not been ported and/or certified for use with 2.0.x.

It'll be a better world when they are, though.

Re:24 Hour Response Time - a thought

[Tony-A]

if Microsoft had resolved an issue (i know stop laughing and read on) in 24 hours would it have been posted on here in this manner?? I suspect it would have had a different slant to it
Considering it took something over three days before a search for Code Red on microsoft.com returned anything when microsoft apparently already had a patch for a couple of weeks, methinks the slant would be incredulity.

ALL software has bugs and issues and exploits
Agreed, with the possible exception of some stuff by Donald Knuth.
but all software eventually gets patched
Nope. dBASE5 for DOS has a serious bug which will never be patched. (Under certain conditions, "reading" a file will cause the initial 6 bytes of several other files to be reqritten with stale cached data. Ugly.)

Apt quote

[npsimons]

"A hacker does for love what others would not do for money."

Oh, and in case you're wondering, I have other quotes.

PHP 4.2.1 / Apache 2.0.39

[jmertic]

PHP 4.2.1 doesn't seem to work with Apache 2.0.39. You need to upgrade to the CVS version of PHP; see the bug report

When did Apache 2.0 support Windows 98?

[gsfprez]

I just followed the links, and, if i'm not crazy, you can now run 2.0.x on Windows 98...

Any verification of this?

(its not for me - its for a guy i support... i'm running off of OpenBSD myself)

Re:Let's not forget...

[jimjag]

Sorry, I had assumed (mistakely I see) that you were actually *interested* in the whole issue.

But yes, sometimes mistakes are made. A fact I'm sure your parents are quite familiar with.

WRONG

[Anonymous Coward]

http://online.securityfocus.com/bid/5033/exploit/

Compile and run, and BAM, you have a uid=nobody shell on an OpenBSD server running vulnerable Apache.
The authors likely have a Linux exploit too, because glibc makes it much easier to exploit heap-corruption bugs.

Re:mod_ssl? for Apache 2.0.39

[Anonymous Coward]

I downloaded and installed the binary for 2.0.39 for RedHat and when I do an ./apachectl startssl all I get is a port 80 listening. When I do a netstat -an I only show 80. Ugh, I'm no Linux genius, I just need to get my MRTG/RRDTOOL https site back up. The FAQ for ModSSl/Apache is a little confusing to me. When I look in the modules directory I don't see a mod_ssl.so but there are 100 other modules. Why wouldnt this be included in the binary? Isn't it more important than all of that other stuff in there?

Now got a make install error

[Jockox3]

Changing the php_functions.c allowed the make to go fine. However I now have several problems cropped up on make install. First it was trying to find a directory '.' listed in the subdirs defiition in the Makefile in the source root. So I removed that and it proceeded a bit better but only until it got to here: Installing program: phpextdist make[2]: Leaving directory `/root/php-4.2.1/pear' make[1]: Leaving directory `/root/php-4.2.1/pear' make[1]: Entering directory `/root/php-4.2.1' make[1]: *** [install-sapi] Error 1 make[1]: Leaving directory `/root/php-4.2.1' make: *** [install-recursive] Error 1 Any ideas? I am using RH 7.1, and trying to build an Apache 2.0.39, PHP 4.2.1 setup. Cheers, Jock

Re:Now got a make install error

[Jockox3]

Sorry - messed that up! Reposting better formatted one for readability.

Changing the php_functions.c allowed the make to go fine.

However I now have several problems cropped up on make install.

First it was trying to find a directory '.' listed in the subdirs defiition in the Makefile in the source root.

So I removed that and it proceeded a bit better but only until it got to here:

Installing program: phpextdist
make[2]: Leaving directory `/root/php-4.2.1/pear'
make[1]: Leaving directory `/root/php-4.2.1/pear'
make[1]: Entering directory `/root/php-4.2.1'
make[1]: *** [install-sapi] Error 1
make[1]: Leaving directory `/root/php-4.2.1'
make: *** [install-recursive] Error 1

Any ideas? I am using RH 7.1, and trying to build an Apache 2.0.39, PHP 4.2.1 setup.

Cheers, Jock

Re:plain truth

[Anonymous Coward]

no, there's an exploit.

http://online.securityfocus.com/news/493

i miss yoiu

[kentyman]

i love you