Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Apache: Docs

[PATCH] mod_log_forensic security considerations

 

 

Apache docs RSS feed   Index | Next | Previous | View Threaded


d.s at daniel

May 29, 2012, 10:36 AM

Post #1 of 6 (267 views)
Permalink
[PATCH] mod_log_forensic security considerations

https://blogs.apache.org/infra/entry/apache_org_incident_report_for

Infra got bit by mod_log_forensic logs including Authorization headers
and being world-readable, so in an effort to save someone else from
repeating this mistake how about adding it to the "Security
considerations" section of the documentation:

[[[
Index: docs/manual/mod/mod_log_forensic.xml
===================================================================
--- docs/manual/mod/mod_log_forensic.xml (revision 1342688)
+++ docs/manual/mod/mod_log_forensic.xml (working copy)
@@ -93,6 +93,10 @@
document for details on why your security could be compromised
if the directory where logfiles are stored is writable by
anyone other than the user that starts the server.</p>
+ <p>The logfiles may contain sensitive data such as the contents of
+ <code>Authorization:</code> headers (which can contain passwords), so
+ they should not be readable by anyone except the user that starts the
+ server.</p>
</section>

<directivesynopsis>
]]]

Perhaps it would be a useful feature to allow excluding those headers
from being logged, too.

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe [at] httpd
For additional commands, e-mail: docs-help [at] httpd


trawick at gmail

Jun 6, 2012, 12:46 PM

Post #2 of 6 (251 views)
Permalink
Re: [PATCH] mod_log_forensic security considerations [In reply to]

On Tue, May 29, 2012 at 1:36 PM, Daniel Shahaf <d.s [at] daniel> wrote:
> https://blogs.apache.org/infra/entry/apache_org_incident_report_for
>
> Infra got bit by mod_log_forensic logs including Authorization headers
> and being world-readable, so in an effort to save someone else from
> repeating this mistake how about adding it to the "Security
> considerations" section of the documentation:
>
> [[[
> Index: docs/manual/mod/mod_log_forensic.xml
> ===================================================================
> --- docs/manual/mod/mod_log_forensic.xml        (revision 1342688)
> +++ docs/manual/mod/mod_log_forensic.xml        (working copy)
> @@ -93,6 +93,10 @@
>     document for details on why your security could be compromised
>     if the directory where logfiles are stored is writable by
>     anyone other than the user that starts the server.</p>
> +    <p>The logfiles may contain sensitive data such as the contents of
> +    <code>Authorization:</code> headers (which can contain passwords), so
> +    they should not be readable by anyone except the user that starts the
> +    server.</p>
>  </section>
>
>  <directivesynopsis>
> ]]]
>
> Perhaps it would be a useful feature to allow excluding those headers
> from being logged, too.

IMO they shouldn't be logged by default (if at all).
Proxy-Authorization also needs to be handled. (Anything else? My
search query foo is particularly bad today.)

Attached is a potential code fix... I guess a directive could be
added to allow them to be logged, but when would that be needed? (A.
When the request crashes due to the exact value of one of these
headers and the module author needs it for debugging.)

--
Born in Roswell... married an alien...
http://emptyhammock.com/
Attachments: mod_log_forensic_authorization.txt (0.87 KB)


joe_schaefer at yahoo

Jun 6, 2012, 12:49 PM

Post #3 of 6 (245 views)
Permalink
Re: [PATCH] mod_log_forensic security considerations [In reply to]

Session cookies sometimes pose a security risk as well.



----- Original Message -----
> From: Jeff Trawick <trawick [at] gmail>
> To: docs [at] httpd; dev [at] httpd
> Cc:
> Sent: Wednesday, June 6, 2012 3:46 PM
> Subject: Re: [PATCH] mod_log_forensic security considerations
>
> On Tue, May 29, 2012 at 1:36 PM, Daniel Shahaf <d.s [at] daniel>
> wrote:
>> https://blogs.apache.org/infra/entry/apache_org_incident_report_for
>>
>> Infra got bit by mod_log_forensic logs including Authorization headers
>> and being world-readable, so in an effort to save someone else from
>> repeating this mistake how about adding it to the "Security
>> considerations" section of the documentation:
>>
>> [[[
>> Index: docs/manual/mod/mod_log_forensic.xml
>> ===================================================================
>> --- docs/manual/mod/mod_log_forensic.xml        (revision 1342688)
>> +++ docs/manual/mod/mod_log_forensic.xml        (working copy)
>> @@ -93,6 +93,10 @@
>>     document for details on why your security could be compromised
>>     if the directory where logfiles are stored is writable by
>>     anyone other than the user that starts the server.</p>
>> +    <p>The logfiles may contain sensitive data such as the contents
> of
>> +    <code>Authorization:</code> headers (which can contain
> passwords), so
>> +    they should not be readable by anyone except the user that starts the
>> +    server.</p>
>>  </section>
>>
>>  <directivesynopsis>
>> ]]]
>>
>> Perhaps it would be a useful feature to allow excluding those headers
>> from being logged, too.
>
> IMO they shouldn't be logged by default (if at all).
> Proxy-Authorization also needs to be handled.  (Anything else?  My
> search query foo is particularly bad today.)
>
> Attached is a potential code fix...  I guess a directive could be
> added to allow them to be logged, but when would that be needed?  (A.
> When the request crashes due to the exact value of one of these
> headers and the module author needs it for debugging.)
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscribe [at] httpd
> For additional commands, e-mail: docs-help [at] httpd
>

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe [at] httpd
For additional commands, e-mail: docs-help [at] httpd


trawick at gmail

Jun 6, 2012, 6:15 PM

Post #4 of 6 (246 views)
Permalink
Re: [PATCH] mod_log_forensic security considerations [In reply to]

On Wed, Jun 6, 2012 at 3:49 PM, Joe Schaefer <joe_schaefer [at] yahoo> wrote:
> Session cookies sometimes pose a security risk as well.

Yeah. That could be any cookie though although there are a few very
common defaults :( My guess is that cookie values are more useful for
debugging crashes than Authorization headers, but that it should still
be opt-in.

Thoughts, anyone?

>
>
>
> ----- Original Message -----
>> From: Jeff Trawick <trawick [at] gmail>
>> To: docs [at] httpd; dev [at] httpd
>> Cc:
>> Sent: Wednesday, June 6, 2012 3:46 PM
>> Subject: Re: [PATCH] mod_log_forensic security considerations
>>
>> On Tue, May 29, 2012 at 1:36 PM, Daniel Shahaf <d.s [at] daniel>
>> wrote:
>>>  https://blogs.apache.org/infra/entry/apache_org_incident_report_for
>>>
>>>  Infra got bit by mod_log_forensic logs including Authorization headers
>>>  and being world-readable, so in an effort to save someone else from
>>>  repeating this mistake how about adding it to the "Security
>>>  considerations" section of the documentation:
>>>
>>>  [.[.[.
>>>  Index: docs/manual/mod/mod_log_forensic.xml
>>>  ===================================================================
>>>  --- docs/manual/mod/mod_log_forensic.xml        (revision 1342688)
>>>  +++ docs/manual/mod/mod_log_forensic.xml        (working copy)
>>>  @@ -93,6 +93,10 @@
>>>      document for details on why your security could be compromised
>>>      if the directory where logfiles are stored is writable by
>>>      anyone other than the user that starts the server.</p>
>>>  +    <p>The logfiles may contain sensitive data such as the contents
>> of
>>>  +    <code>Authorization:</code> headers (which can contain
>> passwords), so
>>>  +    they should not be readable by anyone except the user that starts the
>>>  +    server.</p>
>>>   </section>
>>>
>>>   <directivesynopsis>
>>>  ]]]
>>>
>>>  Perhaps it would be a useful feature to allow excluding those headers
>>>  from being logged, too.
>>
>> IMO they shouldn't be logged by default (if at all).
>> Proxy-Authorization also needs to be handled.  (Anything else?  My
>> search query foo is particularly bad today.)
>>
>> Attached is a potential code fix...  I guess a directive could be
>> added to allow them to be logged, but when would that be needed?  (A.
>> When the request crashes due to the exact value of one of these
>> headers and the module author needs it for debugging.)
>>
>> --
>> Born in Roswell... married an alien...
>> http://emptyhammock.com/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: docs-unsubscribe [at] httpd
>> For additional commands, e-mail: docs-help [at] httpd
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscribe [at] httpd
> For additional commands, e-mail: docs-help [at] httpd
>



--
Born in Roswell... married an alien...
http://emptyhammock.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe [at] httpd
For additional commands, e-mail: docs-help [at] httpd


wrowe at rowe-clan

Jun 7, 2012, 11:18 AM

Post #5 of 6 (244 views)
Permalink
Re: [PATCH] mod_log_forensic security considerations [In reply to]

On 6/6/2012 2:46 PM, Jeff Trawick wrote:
> On Tue, May 29, 2012 at 1:36 PM, Daniel Shahaf <d.s [at] daniel> wrote:
>>
>> Perhaps it would be a useful feature to allow excluding those headers
>> from being logged, too.
>
> IMO they shouldn't be logged by default (if at all).
> Proxy-Authorization also needs to be handled. (Anything else? My
> search query foo is particularly bad today.)

ANY parsing which occurs within mod_log_forensic is going to open that module
itself to suspicion and potential un-captured exploitative header values.

My own theory; provide pipe log redirection and write a filter to do whatever
you like to corrupt the pure data received from the client.

Otherwise, you have other issues like proxy connect scheme://user:pass [at] backen/
or session tokens in URL's or cookies to contend with.

There is no way to make forensic logging 'safe for general consumption' and that
is the message we have to broadcast loudly.

A forensic logging pipe could easily kill off all matched requests before they
were ever logged to disk, resulting in only unmatched pairs. The parent process
which spawned the logger shouldn't be crashing, so the logging should 'just work'.


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe [at] httpd
For additional commands, e-mail: docs-help [at] httpd


trawick at gmail

Jun 7, 2012, 11:56 AM

Post #6 of 6 (249 views)
Permalink
Re: [PATCH] mod_log_forensic security considerations [In reply to]

On Thu, Jun 7, 2012 at 2:18 PM, William A. Rowe Jr. <wrowe [at] rowe-clan> wrote:
> On 6/6/2012 2:46 PM, Jeff Trawick wrote:
>> On Tue, May 29, 2012 at 1:36 PM, Daniel Shahaf <d.s [at] daniel> wrote:
>>>
>>> Perhaps it would be a useful feature to allow excluding those headers
>>> from being logged, too.
>>
>> IMO they shouldn't be logged by default (if at all).
>> Proxy-Authorization also needs to be handled.  (Anything else?  My
>> search query foo is particularly bad today.)
>
> ANY parsing which occurs within mod_log_forensic is going to open that module
> itself to suspicion and potential un-captured exploitative header values.
>
> My own theory; provide pipe log redirection and write a filter to do whatever
> you like to corrupt the pure data received from the client.
>
> Otherwise, you have other issues like proxy connect scheme://user:pass [at] backen/
> or session tokens in URL's or cookies to contend with.
>
> There is no way to make forensic logging 'safe for general consumption' and that
> is the message we have to broadcast loudly.

The list of concerns can't be fixed with with code and we need to put
more hints in the documentation.

Logging obvious passwords by default is just plain stupid though.

> A forensic logging pipe could easily kill off all matched requests before they
> were ever logged to disk, resulting in only unmatched pairs.  The parent process
> which spawned the logger shouldn't be crashing, so the logging should 'just work'.

Writing only the unmatched requests is equivalent to what you get with
mod_whatkilledus, though using a much different implementation.

--
Born in Roswell... married an alien...
http://emptyhammock.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe [at] httpd
For additional commands, e-mail: docs-help [at] httpd

Apache docs RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.