Re: [VOTE] Release 2.2.1 as GA
Done. I build against APR and APR-util 1.3.0 and the Perl scripts working now. Also no build error apu_version anymore. All tests passed here, including mod_perl and other common mods. Steffen http://www.apachelounge.comYeah it builds fine with APR and APR-util trunk, nothing was needed just builds.mod_perl and mod_security are both working. (build a normal binary and an optimized one, both work, optimized binaries gave some problems with 2.2.0)Build speed seem to have improved aswel, i went down to get a coke and was done when i got back! Compiler: Visual Studio .net 2005 Pro (out of box, no aditianal SDK's)-- ~Jorge
Re: svn commit: r392230 - in /httpd/site/trunk: docs/security/vulnerabilities_13.html xdocs/security/vulnerabilities-httpd.xml
WHY? 1.3 was UNAFFECTED by the original report, because chunking is NOT SUPPORTED. The only reason I insisted on fixing it is that there were other similar issues w.r.t. other handlers. I thought you were the one who insisted that my patch didn't address -2088? It' Bill [EMAIL PROTECTED] wrote: Author: mjc Date: Fri Apr 7 02:39:36 2006 New Revision: 392230 URL: http://svn.apache.org/viewcvs?rev=392230view=rev Log: From: Mike O'Connor Subject: Apacheweek security minor addition, I think I think http://httpd.apache.org/security/vulnerabilities_13.html should probably note that CAN-2005-2088 is (at least partially and maybe completely) addressed in 1.3.34. Modified: httpd/site/trunk/docs/security/vulnerabilities_13.html httpd/site/trunk/xdocs/security/vulnerabilities-httpd.xml Modified: httpd/site/trunk/docs/security/vulnerabilities_13.html URL: http://svn.apache.org/viewcvs/httpd/site/trunk/docs/security/vulnerabilities_13.html?rev=392230r1=392229r2=392230view=diff == --- httpd/site/trunk/docs/security/vulnerabilities_13.html (original) +++ httpd/site/trunk/docs/security/vulnerabilities_13.html Fri Apr 7 02:39:36 2006 @@ -112,6 +112,42 @@ table border=0 cellspacing=0 cellpadding=2 width=100% trtd bgcolor=#525D76 font color=#ff face=arial,helvetica,sanserif + a name=1.3.34strongFixed in Apache httpd 1.3.34/strong/a + /font + /td/tr + trtd + blockquote +dl +dd +bmoderate: /b +b +name name=CVE-2005-2088HTTP Request Spoofing/name +/b +a href=http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2088;CVE-2005-2088/a +p +A flaw occured when using the Apache server as a HTTP proxy. A remote +attacker could send a HTTP request with both a Transfer-Encoding: +chunked header and a Content-Length header, causing Apache to +incorrectly handle and forward the body of the request in a way that +causes the receiving server to process it as a separate HTTP request. +This could allow the bypass of web application firewall protection or +lead to cross-site scripting (XSS) attacks. +/p +/dd +dd + Update Released: 18th October 2005br / +/dd +dd + Affects: +1.3.33, 1.3.32, 1.3.31, 1.3.29, 1.3.28, 1.3.27, 1.3.26, 1.3.24, 1.3.22, 1.3.20, 1.3.19, 1.3.17, 1.3.14, 1.3.12, 1.3.11, 1.3.9, 1.3.6, 1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0p / +/dd +/dl + /blockquote + /td/tr +/table + table border=0 cellspacing=0 cellpadding=2 width=100% + trtd bgcolor=#525D76 + font color=#ff face=arial,helvetica,sanserif a name=1.3.33strongFixed in Apache httpd 1.3.33/strong/a /font /td/tr Modified: httpd/site/trunk/xdocs/security/vulnerabilities-httpd.xml URL: http://svn.apache.org/viewcvs/httpd/site/trunk/xdocs/security/vulnerabilities-httpd.xml?rev=392230r1=392229r2=392230view=diff == --- httpd/site/trunk/xdocs/security/vulnerabilities-httpd.xml (original) +++ httpd/site/trunk/xdocs/security/vulnerabilities-httpd.xml Fri Apr 7 02:39:36 2006 @@ -253,6 +253,45 @@ affects prod=httpd version=2.0.35/ /issue +issue fixed=1.3.34 public=20050611 released=20051018 +cve name=CVE-2005-2088/ +severity level=3moderate/severity +titleHTTP Request Spoofing/title +description +p +A flaw occured when using the Apache server as a HTTP proxy. A remote +attacker could send a HTTP request with both a Transfer-Encoding: +chunked header and a Content-Length header, causing Apache to +incorrectly handle and forward the body of the request in a way that +causes the receiving server to process it as a separate HTTP request. +This could allow the bypass of web application firewall protection or +lead to cross-site scripting (XSS) attacks. +/p +/description + affects prod=httpd version=1.3.33/ + affects prod=httpd version=1.3.32/ + affects prod=httpd version=1.3.31/ + affects prod=httpd version=1.3.29/ + affects prod=httpd version=1.3.28/ + affects prod=httpd version=1.3.27/ + affects prod=httpd version=1.3.26/ + affects prod=httpd version=1.3.24/ + affects prod=httpd version=1.3.22/ + affects prod=httpd version=1.3.20/ + affects prod=httpd version=1.3.19/ + affects prod=httpd version=1.3.17/ + affects prod=httpd version=1.3.14/ + affects prod=httpd version=1.3.12/ + affects prod=httpd version=1.3.11/ + affects prod=httpd version=1.3.9/ + affects prod=httpd version=1.3.6/ + affects prod=httpd version=1.3.4/ + affects prod=httpd version=1.3.3/ + affects prod=httpd version=1.3.2/ + affects prod=httpd version=1.3.1/ + affects prod=httpd version=1.3.0/ +/issue + issue fixed=2.0.55 public=20050611 released=20051014 cve name=CVE-2005-2088/ severity level=3moderate/severity
Re: svn commit: r392230 - in /httpd/site/trunk: docs/security/vulnerabilities_13.html xdocs/security/vulnerabilities-httpd.xml
1.3 was UNAFFECTED Yes, indeed it was me that insisted that this didn't affect 1.3, I'll revert it :) Cheers, Mark
Re: [VOTE] Release 2.2.1 as GA
Jorge Schrauwen wrote: Compiler: Visual Studio .net 2005 Pro (out of box, no aditianal SDK's) FWIW, I'm focused on the Win64 fixes on trunk, backporting compatible changes to 2.2, and ignoring 2.0 for Win64. Of course you don't need any SDK's - they are included. For VS 6.0 users their headers are too far out of date. Studio .Net 2003/2005 users should certainly not need any updates. Actually someone just complained about not building correctly the apu ldap headers. That's not a surprise if using an old VC6 and stale headers.
Re: svn commit: r392234 - in /httpd/site/trunk: docs/security/vulnerabilities_13.html xdocs/security/vulnerabilities-httpd.xml
[EMAIL PROTECTED] wrote: Author: mjc Date: Fri Apr 7 02:58:47 2006 New Revision: 392234 URL: http://svn.apache.org/viewcvs?rev=392234view=rev Log: Revert revision 392230. wrowe correctly points out that cve-2005-2088 didn't affect apache 1.3, and indeed I've mailed people that thought it did to correct them. My completely incomplete It' was ment to say It's unfair to lead people to believe their 1.3.33 and prior is vulnerable to this. That said, maybe it bears pointing out this general fix, and pointing out that 1.3 was never vulnerable, to avoid having to keep emailing that same answer? Bill
Re: [VOTE] Release 2.2.1 as GA
So far I have two reports that mod_ssl is given issues. Strange, I tried it on three XP boxes and all is fine. The report is: error c005 at 6FD0F220 (mod_ssl). c005 is 'access violation'. Using FileMon, this appears to get triggered when trying to read in a server certificate. I removed the SSL portion of one virtual host and it then errored in trying to read the certificate for the first virtual host. Removing both SSL virtualhost portions allows the server to run fine. The configuration was copied in whole from a working 2.2.0 install Steffen - Original Message - From: William A. Rowe, Jr. [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Friday, April 07, 2006 11:55 Subject: Re: [VOTE] Release 2.2.1 as GA Jorge Schrauwen wrote: Compiler: Visual Studio .net 2005 Pro (out of box, no aditianal SDK's) FWIW, I'm focused on the Win64 fixes on trunk, backporting compatible changes to 2.2, and ignoring 2.0 for Win64. Of course you don't need any SDK's - they are included. For VS 6.0 users their headers are too far out of date. Studio .Net 2003/2005 users should certainly not need any updates. Actually someone just complained about not building correctly the apu ldap headers. That's not a surprise if using an old VC6 and stale headers.
Re: [VOTE] Release 2.2.1 as GA
Interesting, i'll give it another shot later today, 2.2.0 was comply totaled if trying as Win64.Making 2.0 Win64 compatible is to mutch work IMHO.Focusing on 2.2 is a great idea...I noted that i didn't have any SDK's installed because if you use the free edition of VC.net 2005 you need Platform SDK and some other tools to be able to compile (IIRC)On 4/7/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:Jorge Schrauwen wrote: Compiler: Visual Studio .net 2005 Pro (out of box, no aditianal SDK's) FWIW, I'm focused on the Win64 fixes on trunk, backporting compatiblechanges to 2.2, and ignoring 2.0 for Win64.Of course you don't need any SDK's - they are included.For VS 6.0 userstheir headers are too far out of date.Studio .Net 2003/2005 users should certainly not need any updates.Actually someone just complained about not building correctly the apu ldapheaders.That's not a surprise if using an old VC6 and stale headers. -- ~Jorge
Re: [VOTE] Release 2.2.1 as GA
Strange my SSL vhosts works fine.Don't get any errors.On 4/7/06, Steffen [EMAIL PROTECTED] wrote: So far I have two reports that mod_ssl is given issues.Strange, I tried it on three XP boxes and all is fine. The report is:error c005 at 6FD0F220 (mod_ssl).c005 is 'access violation'.Using FileMon, this appears to get triggered when trying to read in a servercertificate. I removed the SSL portion of one virtual host and it then errored in trying to read the certificate for the first virtual host.Removing both SSL virtualhost portions allows the server to run fine. Theconfiguration was copied in whole from a working 2.2.0 install Steffen- Original Message -From: William A. Rowe, Jr. [EMAIL PROTECTED]To: dev@httpd.apache.org Sent: Friday, April 07, 2006 11:55Subject: Re: [VOTE] Release 2.2.1 as GA Jorge Schrauwen wrote: Compiler: Visual Studio .net 2005 Pro (out of box, no aditianal SDK's) FWIW, I'm focused on the Win64 fixes on trunk, backporting compatible changes to 2.2, and ignoring 2.0 for Win64. Of course you don't need any SDK's - they are included.For VS 6.0 users their headers are too far out of date.Studio .Net 2003/2005 users should certainly not need any updates. Actually someone just complained about not building correctly the apu ldap headers.That's not a surprise if using an old VC6 and stale headers.-- ~Jorge
Re: [VOTE] Release 2.2.1 as GA
Steffen wrote: So far I have two reports that mod_ssl is given issues. Strange, I tried it on three XP boxes and all is fine. The report is: error c005 at 6FD0F220 (mod_ssl). c005 is 'access violation'. Using FileMon, this appears to get triggered when trying to read in a server certificate. I removed the SSL portion of one virtual host and it then errored in trying to read the certificate for the first virtual host. You have odd NTFS rights on the certificate files? Joost
Re: [VOTE] Release 2.2.1 as GA
Joost de Heer wrote: Steffen wrote: So far I have two reports that mod_ssl is given issues. Strange, I tried it on three XP boxes and all is fine. The report is: error c005 at 6FD0F220 (mod_ssl). c005 is 'access violation'. Using FileMon, this appears to get triggered when trying to read in a server certificate. I removed the SSL portion of one virtual host and it then errored in trying to read the certificate for the first virtual host. You have odd NTFS rights on the certificate files? That shouldn't cause a GPF. You said this was a working conf under 2.2.0? What OpenSSL flavor before / after? Hopefully you pass on .pdb files from the exact build you distribute, and the user can provide a meaningful Dr. Watson log. Unfortuantely there aren't any by default for OpenSSL, unless you hack in /debug /opt:ref into the release ldflags in place of /release, and /oy- /Zi into the release cflags of the openssl build. Bill
Re: [VOTE] Release 2.2.1 as GA
Jorge Schrauwen wrote: Interesting, i'll give it another shot later today, 2.2.0 was comply totaled if trying as Win64. Yup, mostly hopeless back then. Making 2.0 Win64 compatible is to mutch work IMHO. Focusing on 2.2 is a great idea... Couple observations; pcre is quite LP64 dirty; this is observed under darwin x686 and win64. so don't necessarily expect 2.2.1 to build win64 clean yet out of the zip, and it may be a few more cycles before every issuees is resolved. It brings up a good question, which contributors are monitoring our flavor of pcre for updates from the pcre community, and liasoning back our changes to pcre to it's project?
RE: Mod_proxy_http ProxyErrorOverride eating cookies
Bart, How about we tag-team on this one :-) I may not be able to create a patch to fix it, but I can certainly fill out a web form. I submitted this as bug ID #39245 along with the copying the email exchanges we've had on the list. You might want to add yourself to the cc for this. Folks, I'm happy to contribute with configuration examples and HTTP request logs to show where this issue is happening, if needed. Also time permitting, I can probably offer my services in testing any proposed patches with the applications where we've seen this issue. Jeff Tharp System Administrator ESRI - Redlands, CA http://www.esri.com -Original Message- From: Bart van der Schans [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 05, 2006 12:40 AM To: dev@httpd.apache.org Subject: Re: Mod_proxy_http ProxyErrorOverride eating cookies Jeff Tharp wrote: Folks, I just wanted to add my voice to this issue. We've ran into this bug when trying to reverse proxy a number of applications, including IBM WebSphere Proxy Server, SAP E-Recruiting, and Roller. In each case, we had ProxyErrorOverride set to On so we could intercept any errors from the back-end servers. But turning this on caused us to loose cookies set during authentication, breaking the login process. I think the trick of setting a cookie as part of an HTTP redirect during login is common among Java apps such as these. This has been a hurdle that has slowed the implementation of Apache 2.2 as a reverse proxy in front of our external-facing sites. Has a formal bug been opened on this? It would be great to see this fixed before the next release of Apache. I didn't open a formal bug for this issue, but maybe somebody else has already done it. If not, should I create one? Bart Thanks, Jeff Tharp System Administrator ESRI - Redlands, CA http://www.esri.com From Bart van der Schans: Hi, The ProxyErrorOverride On setting is correctly catching the errors from the (reverse) proxied server. Only, it overrides too much IMHO. Right now it overrides anything that's not in the 2xx range, but I think it should allow also the 3xx range for redirects etc. A commonly used trick is to set a cookie with a 302 header so the browser gets redirected to the page which needs the cookie. When using ProxyErrorOverride, mod_proxy_http sets its own headers and the cookie is lost. The attached patch check not only for ap_is_HTTP_SUCCESS but also for ap_is_HTTP_REDIRECT which should solve the problem. Thanks, Bart van der Schans -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl -- -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl --
Re: [VOTE] Release 2.2.1 as GA
I do not have the issue (now 3 reports at the Apachelounge), so I cannot give more info, here it was working fine. I build now with openssl 0.9.8b instead of 0.9.8a. And suprise, it is working now at that guys. I come back here when there are still issues. Steffen - Original Message - From: William A. Rowe, Jr. [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Friday, April 07, 2006 21:44 Subject: Re: [VOTE] Release 2.2.1 as GA Joost de Heer wrote: Steffen wrote: So far I have two reports that mod_ssl is given issues. Strange, I tried it on three XP boxes and all is fine. The report is: error c005 at 6FD0F220 (mod_ssl). c005 is 'access violation'. Using FileMon, this appears to get triggered when trying to read in a server certificate. I removed the SSL portion of one virtual host and it then errored in trying to read the certificate for the first virtual host. You have odd NTFS rights on the certificate files? That shouldn't cause a GPF. You said this was a working conf under 2.2.0? What OpenSSL flavor before / after? Hopefully you pass on .pdb files from the exact build you distribute, and the user can provide a meaningful Dr. Watson log. Unfortuantely there aren't any by default for OpenSSL, unless you hack in /debug /opt:ref into the release ldflags in place of /release, and /oy- /Zi into the release cflags of the openssl build. Bill
Re: [VOTE] Release 2.2.1 as GA
On 4/7/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Making 2.0 Win64 compatible is to mutch work IMHO. Focusing on 2.2 is a great idea...Couple observations; pcre is quite LP64 dirty; this is observed underdarwin x686 and win64.so don't necessarily expect 2.2.1 to build win64clean yet out of the zip, and it may be a few more cycles before everyissuees is resolved.It doesn't hurt to try :) maybe some usefull info comes out of it. It brings up a good question, which contributors are monitoring ourflavor of pcre for updates from the pcre community, and liasoning back our changes to pcre to it's project?pcre... i know its in the srclib folder but what exactly does it do?-- ~Jorge
Re: [VOTE] Release 2.2.1 as GA
On 4/7/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jorge Schrauwen wrote: Interesting, i'll give it another shot later today, 2.2.0 was comply totaled if trying as Win64.Yup, mostly hopeless back then. Making 2.0 Win64 compatible is to mutch work IMHO. Focusing on 2.2 is a great idea...Couple observations; pcre is quite LP64 dirty; this is observed underdarwin x686 and win64.so don't necessarily expect 2.2.1 to build win64clean yet out of the zip, and it may be a few more cycles before every issuees is resolved.It brings up a good question, which contributors are monitoring ourflavor of pcre for updates from the pcre community, and liasoning backour changes to pcre to it's project? Acutally it builds just fine without mod_ssl and mod_deflate...Ok lots of warnings... so thats not so good but it seems fine.stock config works fine,Dav seems to work aswel no go for 3rd party mods as was to be expected-- ~Jorge
