Re: [PATCH] mod_log_forensic security considerations

2012-06-08 Thread William A. Rowe Jr.
On 6/8/2012 10:55 AM, Daniel Gruno wrote: > On 06/08/2012 05:45 PM, Joe Schaefer wrote: >> Well not quite, we'd still have had a problem with storing and >> archiving those logs even if we hadn't made them available to >> committers, because they violate our password retention policies. > > My poi

Re: [PATCH] mod_log_forensic security considerations

2012-06-08 Thread Graham Leggett
On 08 Jun 2012, at 7:22 PM, Joe Schaefer wrote: > For several years Graham those logs were rather valuable > in tracking down segfaulting svn requests. Security releases > were made as a result of some of those reports to the > > Subversion project. I'm sure they were, that's exactly what the

Re: [PATCH] mod_log_forensic security considerations

2012-06-08 Thread Daniel Ruggeri
On 6/8/2012 12:52 PM, Jim Riggs wrote: > Having the forensic logs available has proven extremely helpful in this > scenario. Might the full, unfiltered forensic data be valuable? Yes, but I > don't believe the security risk is worth it in my situation. The rare case > where an Authorization head

Re: [PATCH] mod_log_forensic security considerations

2012-06-08 Thread Jim Riggs
On Jun 8, 2012, at 11:51 AM, Graham Leggett wrote: > On 08 Jun 2012, at 5:45 PM, Joe Schaefer wrote: > >> Well not quite, we'd still have had a problem with storing and archiving >> those logs even if we hadn't made them available to committers, because >> they violate our password retention poli

Re: [PATCH] mod_log_forensic security considerations

2012-06-08 Thread Joe Schaefer
For several years Graham those logs were rather valuable in tracking down segfaulting svn requests.  Security releases were made as a result of some of those reports to the Subversion project. - Original Message - > From: Graham Leggett > To: dev@httpd.apache.org > Cc: > Sent: Friday

Re: [PATCH] mod_log_forensic security considerations

2012-06-08 Thread Graham Leggett
On 08 Jun 2012, at 5:45 PM, Joe Schaefer wrote: > Well not quite, we'd still have had a problem with storing and archiving > those logs even if we hadn't made them available to committers, because > they violate our password retention policies. Can you clarify if possible what purpose you were tr

Re: [PATCH] mod_log_forensic security considerations

2012-06-08 Thread Daniel Gruno
On 06/08/2012 05:45 PM, Joe Schaefer wrote: > Well not quite, we'd still have had a problem with storing and > archiving those logs even if we hadn't made them available to > committers, because they violate our password retention policies. My point was, that it should fall upon us to add a filter

Re: [PATCH] mod_log_forensic security considerations

2012-06-08 Thread Joe Schaefer
- Original Message - > From: Daniel Gruno > To: dev@httpd.apache.org > Cc: > Sent: Friday, June 8, 2012 6:24 AM > Subject: Re: [PATCH] mod_log_forensic security considerations > > On 06/08/2012 12:13 PM, Graham Leggett wrote: >> On 08 Jun 2012, at 12:16 AM, Daniel Ruggeri wrote: >> >>

Re: post-CVE-2011-4317 (rewrite proxy unintended interpolation) rewrite PR's

2012-06-08 Thread Jeff Trawick
On Fri, Jun 8, 2012 at 4:58 AM, Joe Orton wrote: > On Thu, Jun 07, 2012 at 01:14:37PM -0400, Jeff Trawick wrote: >> On Thu, Jun 7, 2012 at 11:55 AM, Joe Orton wrote: >> > I like Eric's suggestion of an opt-in RewriteOption.  This will avoid >> > having to iterate yet again if the whitelist is eit

Re: post-CVE-2011-4317 (rewrite proxy unintended interpolation) rewrite PR's

2012-06-08 Thread Rainer Jung
On 08.06.2012 10:58, Plüm, Rüdiger, Vodafone Group wrote: -Original Message- From: Joe Orton Sent: Freitag, 8. Juni 2012 10:38 To: dev@httpd.apache.org Subject: Re: post-CVE-2011-4317 (rewrite proxy unintended interpolation) rewrite PR's On Thu, Jun 07, 2012 at 01:23:29PM -0400, Eric

Re: [PATCH] mod_log_forensic security considerations

2012-06-08 Thread Daniel Gruno
On 06/08/2012 12:13 PM, Graham Leggett wrote: > On 08 Jun 2012, at 12:16 AM, Daniel Ruggeri wrote: > >>> I share Williams concern that this makes mod_forensic potentially less >>> useful. >>> >>> Maybe making the forensic log mode 600 by default would be a better >>> idea? >> Agreed as well. This

Re: [PATCH] mod_log_forensic security considerations

2012-06-08 Thread Graham Leggett
On 08 Jun 2012, at 12:16 AM, Daniel Ruggeri wrote: >> I share Williams concern that this makes mod_forensic potentially less >> useful. >> >> Maybe making the forensic log mode 600 by default would be a better >> idea? > > Agreed as well. This module isn't enabled by default and is most likely

RE: post-CVE-2011-4317 (rewrite proxy unintended interpolation) rewrite PR's

2012-06-08 Thread Plüm , Rüdiger , Vodafone Group
> -Original Message- > From: Joe Orton > Sent: Freitag, 8. Juni 2012 10:38 > To: dev@httpd.apache.org > Subject: Re: post-CVE-2011-4317 (rewrite proxy unintended > interpolation) rewrite PR's > > On Thu, Jun 07, 2012 at 01:23:29PM -0400, Eric Covener wrote: > > e.g. RewriteOptions +"I k

Re: post-CVE-2011-4317 (rewrite proxy unintended interpolation) rewrite PR's

2012-06-08 Thread Joe Orton
On Thu, Jun 07, 2012 at 01:14:37PM -0400, Jeff Trawick wrote: > On Thu, Jun 7, 2012 at 11:55 AM, Joe Orton wrote: > > I like Eric's suggestion of an opt-in RewriteOption.  This will avoid > > having to iterate yet again if the whitelist is either too broad or too > > narrow, and can make the secur

Re: post-CVE-2011-4317 (rewrite proxy unintended interpolation) rewrite PR's

2012-06-08 Thread Joe Orton
On Thu, Jun 07, 2012 at 01:23:29PM -0400, Eric Covener wrote: > e.g. RewriteOptions +"I know I'm running this regex against something > that's not guaranteed to look like a URL-path, and I'll write a regex > that carefully matches/captures the input" How about this? I'm not sure how to put the ri