Re: cvs commit: httpd-2.0 acinclude.m4
At 08:31 PM 8/9/2002, Roy T. Fielding wrote: >>Cool. I believe something is better than nothing :). >> >>(I'm sure you're already aware of this - but thought it'd be better to let >>you know) >>I believe my patch went into r1.127 - and has been labelled for the 2.0.40 >>release. So, you might want to bump the label before it's released. > >It has already been released. And where did the three +1 come from >anyway? That is still required on the tarball (not the tag) before >the announcement is supposed to go out, even for security releases. You are absolutely correct. Consider this my publicly recorded +1. >2.0.40 will fail to compile for future releases of OpenSSL 0.9.x >except for those that also happen to end in e-z or are specifically >asked for via the --with-ssl=DIR option in configure. >Maybe that could go on the "known bugs" page. Right on the README.html page of /dist/httpd/ would be a good start. >I have no idea why the patch was applied just prior to the tag. Must have been some security conscious over-eager attempt to deliver secure code, in spite of third party libraries. After cutting them [Madhu/Sander] much slack, I'll agree I really like your approach much better. Thanks for the rational compromise patch, Roy. Bill
Re: cvs commit: httpd-2.0 acinclude.m4
> Cool. I believe something is better than nothing :). > > (I'm sure you're already aware of this - but thought it'd be better to let > you know) > I believe my patch went into r1.127 - and has been labelled for the 2.0.40 > release. So, you might want to bump the label before it's released. It has already been released. And where did the three +1 come from anyway? That is still required on the tarball (not the tag) before the announcement is supposed to go out, even for security releases. 2.0.40 will fail to compile for future releases of OpenSSL 0.9.x except for those that also happen to end in e-z or are specifically asked for via the --with-ssl=DIR option in configure. Maybe that could go on the "known bugs" page. I have no idea why the patch was applied just prior to the tag. Roy
Re: [PATCH] Multiple env test for CustomLog directives in 1.3.26(mod_log-config.c)
Alan Skea wrote: > I don't think SetEnvIf quite does it. In one module I extract a session tracking >token from the URI and set it into an env var. If this var is present then I want to >use a particular log format. I also started looking at a module called robotcop the >other day. It monitors accesses to the robots.txt file to determine if a request >comes from a robot. Without getting into the merit or demerits of a stateful module >I was trying out logging the robot requests to a completely different logfile. In >addition there are a number of states that robotcop can be in that might also affect >how (or if) I would want to log the request. > > So the upshot is that I have two modules that set env variables and at least four >different behaviours depending on the values of those variables. Here's what I want >to achieve using the syntax I proposed: > > CustomLog logs/robotlog session_fmt env=SESSION,ROBOTCOP > CustomLog logs/userlog session_fmt env=SESSION,!ROBOTCOP > CustomLog logs/robotlog combined env=!SESSION,ROBOTCOP > CustomLog logs/userlog combined env=!SESSION,!ROBOTCOP SetEnvIf SESSION .+ robot_session SetEnvIf ROBOTCOP "" !robot_session SetEnvIf SESSION .+ user_session SetEnvIf ROBOTCOP .+ !user_session CustomLog logs/robotlog session_fmt env=robot_session CustomLog logs/userlog session_fmt env=user_session etc... That might not be exactly it, but it should be close. Now, the one thing that might cause problems is if the other modules set the variables too late for mod_setenvif to act on. That would be another great use for the LogVariable directive that Ken and I were discussing a week or so ago. Joshua.
Re: [PATCH] Multiple env test for CustomLog directives in 1.3.26 (mod_log-config.c)
At 23:27 09/08/02, Joshua Slive wrote: >Alan Skea wrote: >>I got a bit frustrated by the lack of flexibility in the mod_log_config CustomLog >directive. What I wanted was to make logging conditional on multiple environment >variables that get set by different modules, and also to be able to make logging >behaviour depend on the value of the variables rather than just their presence or >absence. >>I decide that the appropriate way to do this was to extend the syntax of the >CustomLog directive as follows: > >I don't believe this is necessary. You didn't present a specific use case, but let >me try an example: > >Log only if var1 is set to yes and var2 is not set to no: > >SetEnvIf var1 yes logme >SetEnvIf var2 no !logme >CustomLog logs/access_log combined env=logme > >If that doesn't solve your problem, please be more specific about what the problem is. > >Joshua. I don't think SetEnvIf quite does it. In one module I extract a session tracking token from the URI and set it into an env var. If this var is present then I want to use a particular log format. I also started looking at a module called robotcop the other day. It monitors accesses to the robots.txt file to determine if a request comes from a robot. Without getting into the merit or demerits of a stateful module I was trying out logging the robot requests to a completely different logfile. In addition there are a number of states that robotcop can be in that might also affect how (or if) I would want to log the request. So the upshot is that I have two modules that set env variables and at least four different behaviours depending on the values of those variables. Here's what I want to achieve using the syntax I proposed: CustomLog logs/robotlog session_fmt env=SESSION,ROBOTCOP CustomLog logs/userlog session_fmt env=SESSION,!ROBOTCOP CustomLog logs/robotlog combined env=!SESSION,ROBOTCOP CustomLog logs/userlog combined env=!SESSION,!ROBOTCOP There was a moment that I considered further qualifying the robotcop logging based on other internal robotcop state. This would mean setting different env vars for each different logging behaviour, or getting the logging mechanism to do at least allow exact matching on the value of an env var. Anyway that idea went out the window for now - at least till I've decided if robotcop is really something I want to use, however the point is it would have further complicated the logging setup. It seems to me that the right place to conjunct env vars for logging is in the logging directives without some place where different env vars can be tested within the same directive, the above isn't possible. -_-_ Alan.
RE: [ANNOUNCE] Apache 2.0.40 Released
Sander Striker [mailto:[EMAIL PROTECTED]] wrote: > We have also included support for IPv6 on any > platform that supports IPv6. Hmmm Windows NT/2k/XP/.Net/98/95 supports IPv6, now where is the IPv6 capable binary (or source for that matter ;) ? (Btw... Mac OS X sports IPv6 also in beta's and public in the coming september updates) Greets, Jeroen
Re: cvs commit: httpd-2.0 acinclude.m4
+1. This seems too restrictive to me. People *do* patch the source as well :) Roy T. Fielding wrote: > > -1. Please revert the change. The purpose of the check is to identify > incompatible APIs, not security holes. > > Roy > -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: cvs commit: httpd-2.0 acinclude.m4
> -1. Please revert the change. The purpose of the check is to identify > incompatible APIs, not security holes. I have a patch to turn it into a warning -- will commit once tested. Roy
Re: cvs commit: httpd-2.0 acinclude.m4
>> -1. Please revert the change. The purpose of the check is to identify >> incompatible APIs, not security holes. > > should apache be allowed to be built against a version of OpenSSL that > has a > known problem - I don't think so. But if everybody thinks against - then, > so > be it. People need to be able to build against older versions specifically so that they can test those older versions and so that they can introduce our newer versions into an environment that has privately patched the other library. > Also, as per your argument, I'd question the validity of the following > checks in acinclude.m4. Does it make sense to eliminate them ??. > OpenSSL "[[1-9]]* > OpenSSL "0.[[1-9]][[0-9]]* Those are to accept all future versions, not deny them. I would be happier if the entire check was removed, but the reason it exists is to check for multiple installed versions and pick the first one that passes the minimum compilable requirement. Roy
RE: cvs commit: httpd-2.0 acinclude.m4
-Original Message- From: Roy T. Fielding [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 3:03 PM >-1. Please revert the change. The purpose of the check is to identify >incompatible APIs, not security holes. should apache be allowed to be built against a version of OpenSSL that has a known problem - I don't think so. But if everybody thinks against - then, so be it. Also, as per your argument, I'd question the validity of the following checks in acinclude.m4. Does it make sense to eliminate them ??. OpenSSL "[[1-9]]* OpenSSL "0.[[1-9]][[0-9]]* Thanks, -Madhu
Re: [PATCH] Multiple env test for CustomLog directives in 1.3.26 (mod_log-config.c)
Alan Skea wrote: > I got a bit frustrated by the lack of flexibility in the mod_log_config CustomLog >directive. What I wanted was to make logging conditional on multiple environment >variables that get set by different modules, and also to be able to make logging >behaviour depend on the value of the variables rather than just their presence or >absence. > > I decide that the appropriate way to do this was to extend the syntax of the >CustomLog directive as follows: I don't believe this is necessary. You didn't present a specific use case, but let me try an example: Log only if var1 is set to yes and var2 is not set to no: SetEnvIf var1 yes logme SetEnvIf var2 no !logme CustomLog logs/access_log combined env=logme If that doesn't solve your problem, please be more specific about what the problem is. Joshua.
Re: cvs commit: httpd-2.0 acinclude.m4
-1. Please revert the change. The purpose of the check is to identify incompatible APIs, not security holes. Roy
daedalus is running 2.0.40 live
...since Friday, 09-Aug-2002 13:39:01 PDT. The traffic was pretty light then but is likely to get heavy soon, so I went ahead and bounced it. It's got a Redirect for the dyslexic security bulletin. I had a moment of panic: [gregames@daedalus apache2.0.40]$ sudo apbounce apache2.0.40 (48)Address already in use: make_sock: could not bind to address [::]:80 no listening sockets available, shutting down apbounce shuts down the old server via apachectl stop. When that returns, it sleeps for 4 seconds, then tries to start the new server. That sucks because there's no positive feedback mechanism to tell me when the old server is really down. It would be great if we delay exiting from apachectl stop until the server was really down. IIRC the last time the topic came up, nobody had a nice portable way to do this. Maybe I should just hack apbounce to look for a listener on port 80 once a second or something. Greg
Re: [PATCH] Check for OpenSSL 0.9.6e or greater
Em Fri, Aug 09, 2002 at 02:04:36PM -0700, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) escreveu: > move to OpenSSL 0.9.6e, I thought it'd be prudent to check specifically for > version 0.9.6e or greater. A warning would be prudent.
RE: [PATCH] Check for OpenSSL 0.9.6e or greater
I'm not sure how to address this : For ex., do we allow building Apache against OpenSSL 0.9.5x ?.. I don't believe so. If it's regarding OpenSSL 0.9.6x, I'm not sure how much of binary incompability it introduces. Moreover, considering the fact that we have a CERT advisory asking ppl to move to OpenSSL 0.9.6e, I thought it'd be prudent to check specifically for version 0.9.6e or greater. -Madhu -Original Message- From: Andreas Hasenack [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 1:34 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] Check for OpenSSL 0.9.6e or greater Em Fri, Aug 09, 2002 at 09:58:03AM -0700, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) escreveu: > With the recent vulnerabilities found in OpenSSL, I thought it'd make sense > for Apache to check for OpenSSL 0.9.6e or higher. And what about patched openssl versions? Given the notorious binary incompatibility even between minor openssl releases, not everybody is going to update to the latest version, but patch the ones they have.
RE: cvs commit: httpd-2.0 acinclude.m4
Thanks for pointing it out. I'd missed it completely (mainly because I thought 0.9.7 is still in beta) Here's an updated patch which checks specifically for > 0.9.6e or > 0.9.[7-9]* $ cvs diff acinclude.m4 Index: acinclude.m4 === RCS file: /home/cvspublic/httpd-2.0/acinclude.m4,v retrieving revision 1.127 diff -u -r1.127 acinclude.m4 --- acinclude.m49 Aug 2002 17:10:45 - 1.127 +++ acinclude.m49 Aug 2002 20:55:24 - @@ -430,7 +430,8 @@ ap_ssltk_version="`$p/openssl version`" case "$ap_ssltk_version" in "OpenSSL "[[1-9]]* | \ -"OpenSSL "0.9.[[6-9]][[e-z]]* | \ +"OpenSSL "0.9.6[[e-z]]* | \ +"OpenSSL "0.9.[[7-9]]* | \ "OpenSSL "0.[[1-9]][[0-9]]* ) ap_cv_ssltk="`(cd $p/.. && pwd)`" break -Original Message- From: Ian Holsman [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 10:59 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: cvs commit: httpd-2.0 acinclude.m4 does this work ?? what happens if they release a OpenSSL 0.9.8 ??? or 0.9.8a ?? On Fri, 2002-08-09 at 10:10, [EMAIL PROTECTED] wrote: > striker 2002/08/09 10:10:45 > > Modified:.acinclude.m4 > Log: > Check for OpenSSL 0.9.6e or higher > > Submitted by: Mathihalli Madhusudan <[EMAIL PROTECTED]> > > Revision ChangesPath > 1.127 +2 -2 httpd-2.0/acinclude.m4 > > Index: acinclude.m4 > === > RCS file: /home/cvs/httpd-2.0/acinclude.m4,v > retrieving revision 1.126 > retrieving revision 1.127 > diff -u -r1.126 -r1.127 > --- acinclude.m416 Jul 2002 18:33:05 - 1.126 > +++ acinclude.m49 Aug 2002 17:10:45 - 1.127 > @@ -430,7 +430,7 @@ >ap_ssltk_version="`$p/openssl version`" >case "$ap_ssltk_version" in >"OpenSSL "[[1-9]]* | \ > -"OpenSSL "0.9.[[6-9]]* | \ > +"OpenSSL "0.9.[[6-9]][[e-z]]* | \ >"OpenSSL "0.[[1-9]][[0-9]]* ) >ap_cv_ssltk="`(cd $p/.. && pwd)`" >break > @@ -441,7 +441,7 @@ >esac > done > if test "x$ap_cv_ssltk" = "x"; then > -AC_MSG_ERROR([requires OpenSSL 0.9.6 or higher]) > +AC_MSG_ERROR([requires OpenSSL 0.9.6e or higher]) > fi >]) >ap_ssltk_base="$ap_cv_ssltk" > > > -- Ian Holsman Performance Measurement & Analysis CNET Networks PH: 415-344-2608
Re: [PATCH] Check for OpenSSL 0.9.6e or greater
On Fri, 2002-08-09 at 15:33, Andreas Hasenack wrote: > Em Fri, Aug 09, 2002 at 09:58:03AM -0700, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) >escreveu: > > With the recent vulnerabilities found in OpenSSL, I thought it'd make sense > > for Apache to check for OpenSSL 0.9.6e or higher. > > And what about patched openssl versions? Given the notorious > binary incompatibility even between minor openssl releases, not > everybody is going to update to the latest version, but patch > the ones they have. Also, I think that check will fail on 0.9.7 which is coming RSN. > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [PATCH] Check for OpenSSL 0.9.6e or greater
Em Fri, Aug 09, 2002 at 09:58:03AM -0700, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) escreveu: > With the recent vulnerabilities found in OpenSSL, I thought it'd make sense > for Apache to check for OpenSSL 0.9.6e or higher. And what about patched openssl versions? Given the notorious binary incompatibility even between minor openssl releases, not everybody is going to update to the latest version, but patch the ones they have.
Re: cvs commit: httpd-site/xdocs/info security_bulletin_20020809a.txt
On Fri, 9 Aug 2002, Joshua Slive wrote: > [EMAIL PROTECTED] wrote: > > > Revision ChangesPath > > 1.1 httpd-site/docs/info/security_bulletin_20020809a.txt > > > Permanent URL: http://httpd.apache.org/info/security_bulletin_20020908a.txt I put in a symlink for now security_bulletin_20020908a.txt -> security_bulletin_20020809a.txt what is the right fix (redirect?) Mark
[PATCH] Multiple env test for CustomLog directives in 1.3.26 (mod_log-config.c)
I got a bit frustrated by the lack of flexibility in the mod_log_config CustomLog directive. What I wanted was to make logging conditional on multiple environment variables that get set by different modules, and also to be able to make logging behaviour depend on the value of the variables rather than just their presence or absence. I decide that the appropriate way to do this was to extend the syntax of the CustomLog directive as follows: CustomLog [env=] env-tests is a comma-separated set of tests as follows: # true if the variable exists ! # true if the variable doesn't exist = # true if the variable exists and has the given value != # true if the variable doesn't exist or doesn't have the given value Logging occurs only if all the tests are true. If you need a disjunction of more complex expression then this can be achieved by using multiple CustomLog directives. The advantage of this slightly curious systax is that it is fully backward compatible with existing config files. Patch is below. -_-_ Alan Skea. apache_1.3.26_mod_log_config.patch Description: Binary data
Re: Apache 2.0 vulnerability affects non-Unix platforms
> Incidentally, I didn't see this get sent to users@httpd and > announce@httpd (it was sent to [EMAIL PROTECTED]). Did I miss it? Doh. So thats two mistakes, where is the third? Mark
Re: Apache 2.0 vulnerability affects non-Unix platforms
Mark J Cox wrote: > -BEGIN PGP SIGNED MESSAGE- > > For Immediate Disclosure Incidentally, I didn't see this get sent to users@httpd and announce@httpd (it was sent to [EMAIL PROTECTED]). Did I miss it? Joshua.
Re: cvs commit: httpd-site/xdocs/info security_bulletin_20020809a.txt
> > Permanent URL: http://httpd.apache.org/info/security_bulletin_20020908a.txt Hmmm, actually it really ought to be 20020809a.txt like the files I commited, the text that went out was wrong due to too many us-uk conversions ;). A cunning redirect rule in the server config would fix it so 20020908a redirects to 20020809a Cheers, Mark
Re: cvs commit: httpd-site/xdocs/info security_bulletin_20020809a.txt
[EMAIL PROTECTED] wrote: > Revision ChangesPath > 1.1 httpd-site/docs/info/security_bulletin_20020809a.txt > Permanent URL: http://httpd.apache.org/info/security_bulletin_20020908a.txt Problem here. Not the month/day day/month switch. I've done a "mv" on daedalus so that the URL will work temporarily, but I suggest you update it in CVS. Joshua.
[PATCH] Check for OpenSSL 0.9.6e or greater
With the recent vulnerabilities found in OpenSSL, I thought it'd make sense for Apache to check for OpenSSL 0.9.6e or higher. -Madhu $ cvs diff acinclude.m4 Index: acinclude.m4 === RCS file: /home/cvspublic/httpd-2.0/acinclude.m4,v retrieving revision 1.126 diff -u -r1.126 acinclude.m4 --- acinclude.m416 Jul 2002 18:33:05 - 1.126 +++ acinclude.m49 Aug 2002 16:54:30 - @@ -430,7 +430,7 @@ ap_ssltk_version="`$p/openssl version`" case "$ap_ssltk_version" in "OpenSSL "[[1-9]]* | \ -"OpenSSL "0.9.[[6-9]]* | \ +"OpenSSL "0.9.[[6-9]][[e-z]]* | \ "OpenSSL "0.[[1-9]][[0-9]]* ) ap_cv_ssltk="`(cd $p/.. && pwd)`" break @@ -441,7 +441,7 @@ esac done if test "x$ap_cv_ssltk" = "x"; then -AC_MSG_ERROR([requires OpenSSL 0.9.6 or higher]) +AC_MSG_ERROR([requires OpenSSL 0.9.6e or higher]) fi ]) ap_ssltk_base="$ap_cv_ssltk"
Apache 2.0 vulnerability affects non-Unix platforms
-BEGIN PGP SIGNED MESSAGE- For Immediate Disclosure === SUMMARY Title: Apache 2.0 vulnerability affects non-Unix platforms Date: 9th August 2002 Version: 1 Product Name: Apache web server 2.0 OS/Platform: Windows, OS2, Netware Permanent URL: http://httpd.apache.org/info/security_bulletin_20020908a.txt Vendor Name: Apache Software Foundation Vendor URL: http://www.apache.org/ Affects: All Released versions of 2.0 through 2.0.39 Fixed in: 2.0.40 Identifiers: CAN-2002-0661 === BACKGROUND Apache is a powerful, full-featured, efficient, and freely-available Web server. On the 7th August 2002, The Apache Software Foundation was notified of the discovery of a significant vulnerability, identified by Auriemma Luigi <[EMAIL PROTECTED]>. This vulnerability has the potential to allow an attacker to inflict serious damage to a server, and reveal sensitive data. This vulnerability affects default installations of the Apache web server. Unix and other variant platforms appear unaffected. Cygwin users are likely to be affected. A simple one line workaround in the httpd.conf file will close the vulnerability. Prior to the first 'Alias' or 'Redirect' directive, add the following directive to the global server configuration: RedirectMatch 400 "\\\.\." Fixes for this vulnerability are also included in Apache version 2.0.40. Apache 2.0.40 also contains some less serious security fixes. More information will be made available by the Apache Software Foundation and Auriemma Luigi <[EMAIL PROTECTED]> in the coming weeks. === REFERENCES The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0661 to this issue. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0661 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPVQBxu6tTP1JpWPZAQHCwAP9HVzSAMMrXadmRdPfEe9eFUKOxpQA4v8d mKrLciDXnVpPlaKc7/1OHUcCwPu0IucHGUN5sF93Dw3X2BKoAjJFHnmS123r/CP6 WnHAaM+Hl17pPVxI3dXJXbiDvmpBB6b9SNCrsmf0RLykLHVZqoekOh2902Y7+Fts NpKuwE7xzdA= =mEuL -END PGP SIGNATURE-
Move the regex code to apr-utils?
Hi, Are there any particular reasons that regex code shouldn't be moved to the apr-utils like expat is. That way we'll be (the non httpd developers) able to use the same code for the things that need regular expressions, instead of linking the same lib multiple times. MT.
