Re: [PATCH] ap_pregsub_ex and somewhat-limited ap_pregsub() to 2.2.x branch
On Sat, 22 Jun 2013 10:09:35 -0400 Jeff Trawick traw...@gmail.com wrote: On Fri, Jun 21, 2013 at 2:43 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On Fri, 21 Jun 2013 13:19:36 -0400 Jeff Trawick traw...@gmail.com wrote: Even with the CVE-2011-3607 it is still possible to DOS the server by consuming huge amounts of memory with mod_setenvif using a specially crafted configuration. Here's a backport of an existing fix in 2.4.x which resolves the issue I reproduced. Note that unlike in 2.4.x we need ap_pregsub to handle somewhat arbitrary string lengths. I picked 64MB, which can be overridden at compile time. http://people.apache.org/~trawick/ap_pregsub_ex_22x.txt This is essentially a grab of ap_pregsub/ap_pregsub_ex from 2.4.x HEAD with the minimal required changes plus http://svn.apache.org/viewvc?view=revisionrevision=1198966 See the XXX notes in the patch for apparent semantic changes which I probably need to back out. (I haven't researched that yet.) Normally we use STATUS to track this but I don't think it is as polished as we normally expect. Still to do (tomorrow?): Investigate the XXX's, run the regression suite. Concerns with the patch? Interested in any of this in the final 2.0.x release? I am happy to hold up a short while to adopt this patch. I'm neutral on adding it to 2.0.x but will certainly pause for it to be committed if others agree and will review the 2.0.x backport. I'm not motivated to put it in 2.0.x either, but if anyone has time to play I will assist if I can. Then is it still appropriate to claim this in 2.0.65 CHANGES without the pcre change? *) SECURITY: CVE-2011-3607 (cve.mitre.org) Fix integer overflow in ap_pregsub() which, when the mod_setenvif module is enabled, could allow local users to gain privileges via a .htaccess file. [Stefan Fritsch, Greg Ames] or have we implied this same fix under that same CVE number? Granted we don't overflow, we simply run OOM now.
Re: [PATCH] ap_pregsub_ex and somewhat-limited ap_pregsub() to 2.2.x branch
On Mon, 24 Jun 2013 10:47:17 -0500 William A. Rowe Jr. wr...@rowe-clan.net wrote: On Sat, 22 Jun 2013 10:09:35 -0400 Jeff Trawick traw...@gmail.com wrote: On Fri, Jun 21, 2013 at 2:43 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On Fri, 21 Jun 2013 13:19:36 -0400 Jeff Trawick traw...@gmail.com wrote: Even with the CVE-2011-3607 it is still possible to DOS the server by consuming huge amounts of memory with mod_setenvif using a specially crafted configuration. Here's a backport of an existing fix in 2.4.x which resolves the issue I reproduced. Note that unlike in 2.4.x we need ap_pregsub to handle somewhat arbitrary string lengths. I picked 64MB, which can be overridden at compile time. http://people.apache.org/~trawick/ap_pregsub_ex_22x.txt This is essentially a grab of ap_pregsub/ap_pregsub_ex from 2.4.x HEAD with the minimal required changes plus http://svn.apache.org/viewvc?view=revisionrevision=1198966 See the XXX notes in the patch for apparent semantic changes which I probably need to back out. (I haven't researched that yet.) Normally we use STATUS to track this but I don't think it is as polished as we normally expect. Still to do (tomorrow?): Investigate the XXX's, run the regression suite. Concerns with the patch? Interested in any of this in the final 2.0.x release? I am happy to hold up a short while to adopt this patch. I'm neutral on adding it to 2.0.x but will certainly pause for it to be committed if others agree and will review the 2.0.x backport. I'm not motivated to put it in 2.0.x either, but if anyone has time to play I will assist if I can. Then is it still appropriate to claim this in 2.0.65 CHANGES without the pcre change? Perhaps we amend the CHANGES entry to indicate; *) SECURITY: CVE-2011-3607 (cve.mitre.org) Fix integer overflow in ap_pregsub() which, when the mod_setenvif module is enabled, could allow local users to gain privileges via a .htaccess file. [Stefan Fritsch, Greg Ames] NOTE: it remains possible to exhaust all memory using a carefully crafted .htaccess rule, which will not be addressed; enabling .htaccess processing for untrusted directories is the root of such security risks. Upgrade to httpd 2.2.25 or later to limit this specific risk. Is this clear enough for 2.0.65 CHANGES?
Re: svn commit: r1496100 - /httpd/httpd/branches/2.0.x/STATUS
+ 2.0.x patch: http://people.apache.org/~wrowe/mod_rewrite-r1482349.patch + +1: wrowe + -1: I think this backport stumbled on some renamed variables between 2.0 and 2.2. text is the format string in 2.0 but it's the result of vfprintf in 2.2. I think str2 needs to be escaped in 2.0 -- see right-hand-side below printf GET /foo HTTP/1.1\r\nHost: loc$(printf \uC3\uA0)lhost\r\n\r\n | nc 0 127.0.0.1 - - [24/Jun/2013:13:45:21 --0400] [loc\xc3\xa0lhost/sid#118cca8][rid#121a360/initial] (2) init rewrite engine with requested uri /foo 127.0.0.1 - - [24/Jun/2013:13:45:21 --0400] [loc\xc3\xa0lhost/sid#118cca8][rid#121a360/initial] (3) applying pattern '/foo' to uri '/foo' 127.0.0.1 - - [24/Jun/2013:13:45:21 --0400] [loc\xc3\xa0lhost/sid#118cca8][rid#121a360/initial] (2) rewrite /foo - /bar 127.0.0.1 - - [24/Jun/2013:13:45:21 --0400] [loc\xc3\xa0lhost/sid#118cca8][rid#121a360/initial] (2) explicitly forcing redirect with http://locàlhost/bar 127.0.0.1 - - [24/Jun/2013:13:45:21 --0400] [loc\xc3\xa0lhost/sid#118cca8][rid#121a360/initial] (1) escaping http://locàlhost/bar for redirect 127.0.0.1 - - [24/Jun/2013:13:45:21 --0400] [loc\xc3\xa0lhost/sid#118cca8][rid#121a360/initial] (1) redirect to http://locàlhost/bar [REDIRECT/302]
Re: svn commit: r1496100 - /httpd/httpd/branches/2.0.x/STATUS
On Mon, 24 Jun 2013 13:56:33 -0400 Eric Covener cove...@gmail.com wrote: I think this backport stumbled on some renamed variables between 2.0 and 2.2. text is the format string in 2.0 but it's the result of vfprintf in 2.2. I think str2 needs to be escaped in 2.0 Agreed, my patch only picked up the first of the text args, yours will catch all of them, so I've switched the proposal to your patch.
Time for 2.4.5
I propose a release somewhere around the 4th of July, to celebrate our independence from proprietary s/w! I'll RM.
Re: Time for 2.4.5
Am 24.06.2013 20:16, schrieb Jim Jagielski: I propose a release somewhere around the 4th of July, to celebrate our independence from proprietary s/w! I'll RM a snapshot for testers at http://httpd.apache.org/dev/dist/ would be fine, it would take me 5 minutes to rebuild our RPM from it and i guess other people too signature.asc Description: OpenPGP digital signature
Re: [PATCH] ap_pregsub_ex and somewhat-limited ap_pregsub() to 2.2.x branch
On Monday, June 24, 2013, William A. Rowe Jr. wrote: On Mon, 24 Jun 2013 10:47:17 -0500 William A. Rowe Jr. wr...@rowe-clan.net javascript:; wrote: On Sat, 22 Jun 2013 10:09:35 -0400 Jeff Trawick traw...@gmail.com javascript:; wrote: On Fri, Jun 21, 2013 at 2:43 PM, William A. Rowe Jr. wr...@rowe-clan.net javascript:;wrote: On Fri, 21 Jun 2013 13:19:36 -0400 Jeff Trawick traw...@gmail.com javascript:; wrote: Even with the CVE-2011-3607 it is still possible to DOS the server by consuming huge amounts of memory with mod_setenvif using a specially crafted configuration. Here's a backport of an existing fix in 2.4.x which resolves the issue I reproduced. Note that unlike in 2.4.x we need ap_pregsub to handle somewhat arbitrary string lengths. I picked 64MB, which can be overridden at compile time. http://people.apache.org/~trawick/ap_pregsub_ex_22x.txt This is essentially a grab of ap_pregsub/ap_pregsub_ex from 2.4.x HEAD with the minimal required changes plus http://svn.apache.org/viewvc?view=revisionrevision=1198966 See the XXX notes in the patch for apparent semantic changes which I probably need to back out. (I haven't researched that yet.) Normally we use STATUS to track this but I don't think it is as polished as we normally expect. Still to do (tomorrow?): Investigate the XXX's, run the regression suite. Concerns with the patch? Interested in any of this in the final 2.0.x release? I am happy to hold up a short while to adopt this patch. I'm neutral on adding it to 2.0.x but will certainly pause for it to be committed if others agree and will review the 2.0.x backport. I'm not motivated to put it in 2.0.x either, but if anyone has time to play I will assist if I can. Then is it still appropriate to claim this in 2.0.65 CHANGES without the pcre change? Perhaps we amend the CHANGES entry to indicate; *) SECURITY: CVE-2011-3607 (cve.mitre.org) Fix integer overflow in ap_pregsub() which, when the mod_setenvif module is enabled, could allow local users to gain privileges via a .htaccess file. [Stefan Fritsch, Greg Ames] NOTE: it remains possible to exhaust all memory using a carefully crafted .htaccess rule, which will not be addressed; enabling .htaccess processing for untrusted directories is the root of such security risks. Upgrade to httpd 2.2.25 or later to limit this specific risk. Is this clear enough for 2.0.65 CHANGES? +1 -- Born in Roswell... married an alien... http://emptyhammock.com/
