

Apache 1.3.26 and 2.0.39 Released 138
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.
24 is nice... (Score:5, Insightful)
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... (Score:1)
$0.02
Re:24 is nice... (Score:1)
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... (Score:2)
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... (Score:1)
You're also right in other post that Apache flaws are few and far between....
Re:24 is nice... (Score:1)
Re:24 is nice... (Score:2)
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;)
Complaints Timescale (Score:5, Insightful)
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 (Score:1)
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 (Score:5, Funny)
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 (Score:1)
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.com]. Covalent will be providing those patches pretty soon [covalent.net] for their releases, it seems.
Re:Complaints Timescale (Score:1, Informative)
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 (Score:1)
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
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 (Score:4, Insightful)
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 - a thought (Score:2)
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.
Re:24 Hour Response Time - a thought (Score:2)
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.)
Win32 MSI Installer Broken (Score:3, Informative)
Re:Win32 MSI Installer Broken (Score:1)
Re:Win32 MSI Installer Broken (Score:1)
It launches console batch window and then closes rapidly.
My guess is its an incomplete build, thats all.
24 hour response? (Score:2, Informative)
Re:24 hour response? (Score:1)
24 Hours - unreasonable and dangerous (Score:2, Insightful)
Re:24 Hours - unreasonable and dangerous (Score:5, Insightful)
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 (Score:5, Insightful)
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:RPMs? (Score:1)
./configure
make
make install
???
Even if you did
Close your eyes, make the problem go away (Score:2)
New mod_ssl? (Score:1)
Or will this old version patch successfully against the latest Apache release? I haven't tried mixing versions.
Re:New mod_ssl? (Score:2)
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? (Score:3, Interesting)
Re:mod_ssl? (Score:5, Informative)
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? (Score:1)
Re:mod_ssl? (Score:1)
There are actually some valid reasons not to upgrade sometimes.
.haeger
Re:mod_ssl? (Score:1)
Rene
How is that insightful? (Score:3, Insightful)
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? (Score:2)
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:mod_ssl? (Score:1)
Too bad - I was going to update everything tonight, but I cannot without mod_ssl.
Re:mod_ssl? (Score:3, Informative)
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? (Score:2)
Actually Useful and Intelligent +0
2.8.9 (apache 1.3.26) out now (Score:2)
good job, but the work is not done (Score:2)
*NIX is in the clear. (Score:3, Insightful)
Had me worried there for a minute as I admin quite a few of those.
You are correct. (Score:2)
Looks like it's going to be a long night.
Re:*NIX is in the clear. (Score:2)
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. (Score:1)
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. (Score:2)
Took about about 10 seconds to install. SHutdown apache, make install, start apache.
That was easy!
Re:*NIX is in the clear. (Score:2)
Re:*NIX is in the clear. (Score:2)
That and we hack our src/include/httpd.h file to up the HARD_SERVER_LIMIT to 1024.
Re:*NIX is in the clear. (Score:1)
Re:*NIX is in the clear. (Score:1)
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. (Score:2)
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. (Score:2)
apachectl stop; make install; apachectl start;
Re:*NIX is in the clear. (Score:1)
Quoth the advisory:
Debian Woody (Score:2)
Re:Debian Woody (Score:1)
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 (Score:1)
Re:Debian Woody (Score:2)
Re:Debian Woody (Score:1)
"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? (Score:3, Interesting)
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:
I noticed that a 1.3.25 doesn't actually exist anywhere ... was there a failed release?
Re:CERT got it slightly wrong? (Score:1)
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? (Score:1)
.. and they went straight to 1.3.26.
Re:CERT got it slightly wrong? (Score:2)
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? (Score:1)
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]
See, I told you so. (Score:5, Interesting)
Need I point out my earlier comment [slashdot.org]? I'll save you the trouble of looking it up:
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:
is simply going to be better software than something that's developed out of the runaway greed rampant in the inferior competition.
Apt quote (Score:1)
Oh, and in case you're wondering, I have other quotes [hardcorehackers.com].
PHP now broken? (Score:2, Interesting)
API module structure `php4_module' in file
O?
Same experience here, had to regress PHP (Score:2)
Any other
Re:Same experience here, had to regress PHP (Score:1)
Re:PHP now broken? (Score:2)
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? (Score:1)
Re:PHP now broken? (Score:1)
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? (Score:1)
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? (Score:2)
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? (Score:1)
Re:PHP now broken? (Score:1)
Re:PHP now broken? (Score:2)
To turn your html into php, just change the
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.
Re:PHP now broken? (Score:1)
Re:PHP now broken? (Score:1)
It's in the Name (Score:2)
How can you? It's called "A Patchy" [apache.org] server, after all.
FUD (Score:5, Informative)
Um, surely you mean vulnerability ?
Re:FUD (Score:1)
freebsd ports... (Score:1)
installing php 4.2.1 from ports again, it dies with:
Making all in apache2filter
/bin/sh
1/sapi/a
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/xm
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... (Score:1)
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...
Now got a make install error (Score:1)
Re:Now got a make install error (Score:1)
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
Not up to industry standards (Score:2, Funny)
Anyone knows that a real, professional company [microsoft.com] 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 (Score:1)
Makefile is missing (Score:2)
Actually... (Score:3, Insightful)
Re:Actually... (Score:1)
PHP 4.2.1 / Apache 2.0.39 (Score:1)
When did Apache 2.0 support Windows 98? (Score:2)
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... (Score:1)
But thanks for playing! Better luck next time!
Re:Let's not forget... (Score:1)
But yes, sometimes mistakes are made. A fact I'm sure your parents are quite familiar with.
That will teach you... (Score:3, Insightful)
The weekend is for relaxing