Re: log_error_core escaping change broke things

[Stas Bekman]

Aryeh Katz wrote:
Stas Bekman wrote:

Actually it's not only about \n and \t, it's about other chars as 
well. Now I get error messages like this:

This is just my opinion, but isn't this much to place in your error log? 
 Is this something you want your random sys admin to parse?
Why don't you have a separate mod_perl defect log, and the error log can 
say something like "Failure: see filename for error info". This way the 
error goes back to the app developer, instead of the web admin.
error_log *is* a log file to log errors. errors may come in different formats 
and different lengths.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: log_error_core escaping change broke things

[Aryeh Katz]

Stas Bekman wrote:

Actually it's not only about \n and \t, it's about other chars as well. 
Now I get error messages like this:

This is just my opinion, but isn't this much to place in your error log? 
 Is this something you want your random sys admin to parse?
Why don't you have a separate mod_perl defect log, and the error log can 
say something like "Failure: see filename for error info". This way the 
error goes back to the app developer, instead of the web admin.

Aryeh
[Thu Dec 18 23:33:58 2003] [error] [client 127.0.0.1] Fh::new: Variable 
"@SAVED_SYMBOLS" is not available\teval 'package Fh; sub new {\n 
my($pack,$name,$file,$delete) = @_;\n_setup_symbols(@SAVED_SYMBOLS) 
if @SAVED_SYMBOLS;\nrequire Fcntl unless defined 
&Fcntl::O_RDWR;\n(my $safename = $name) =~ s/([\\':%])/ sprintf 
\\'%%%02X\\', ord $1 /eg;\nmy $fv = ++$FH . $safename;\nmy $ref 
= *{"Fh::$fv"};\n$file =~ m!^([a-zA-Z0-9_ 
\\'":/.$-]+)$! || return;\nmy $safe = $1;\n 
sysopen($ref,$safe,Fcntl::O_RDWR()|Fcntl::O_CREAT()|Fcntl::O_EXCL(),0600) 
|| return;\nunlink($safe) if $delete;\nCORE::delete 
$Fh::{$fv};\n return bless $ref,$pack;\n}\n\n;' called at 
/home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 776\n\tCGI::_compile 
called at /home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 
740\n\tCGI::AUTOLOAD('Fh','b','/home/stas/apache.org/mp2-cvs2/t/logs/CGItemp3961',0) 
called at (eval 80) line 
59\n\tCGI::read_multipart('CGI=HASH(0x8d42248)',74261727,130) called 
at /home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 
489\n\tCGI::init('CGI=HASH(0x8d42248)') called at 
/home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 
325\n\tCGI::new('CGI') called at 
/home/stas/apache.org/mp2-cvs2/t/response/TestModules/cgi.pm line 
31\n\tTestModules::cgi::handler('Apache::RequestRec=SCALAR(0x8d421a0)') 
called at (eval 95) line 3\n\teval {...} called at (eval 95) line 3\n at 
/home/stas/apache.org/mp2-cvs2/t/response/TestModules/cgi.pm line 
31\n\tCGI::_compile called at 
/home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 
740\n\tCGI::AUTOLOAD('Fh','b','/home/stas/apache.org/mp2-cvs2/t/logs/CGItemp3961',0) 
called at (eval 80) line 
59\n\tCGI::read_multipart('CGI=HASH(0x8d42248)',74261727,130) called 
at /home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 
489\n\tCGI::init('CGI=HASH(0x8d42248)') called at 
/home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 
325\n\tCGI::new('CGI') called at 
/home/stas/apache.org/mp2-cvs2/t/response/TestModules/cgi.pm line 
31\n\tTestModules::cgi::handler('Apache::RequestRec=SCALAR(0x8d421a0)') 
called at -e line 0\n\teval {...} called at -e line 0\n

which is a totally ruined version of:

[Fri Dec 19 00:19:12 2003] [error] [client 127.0.0.1] Fh::new: Variable 
"@SAVED_SYMBOLS" is not available   eval 'package Fh; sub new {
my($pack,$name,$file,$delete) = @_;
_setup_symbols(@SAVED_SYMBOLS) if @SAVED_SYMBOLS;
require Fcntl unless defined &Fcntl::O_RDWR;
(my $safename = $name) =~ s/([\':%])/ sprintf \'%%%02X\', ord $1 /eg;
my $fv = ++$FH . $safename;
my $ref = \\*{"Fh::$fv"};
$file =~ m!^([a-zA-Z0-9_ \\\'\\":/.\\$-]+)$! || return;
my $safe = $1;

sysopen($ref,$safe,Fcntl::O_RDWR()|Fcntl::O_CREAT()|Fcntl::O_EXCL(),0600) 
|| return;
unlink($safe) if $delete;
CORE::delete $Fh::{$fv};
return bless $ref,$pack;
}

;' called at /home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 776
CGI::_compile called at 
/home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 740

CGI::AUTOLOAD('Fh','b','/home/stas/apache.org/mp2-cvs2/t/logs/CGItemp3845',0) 
called at (eval 80) line 59
CGI::read_multipart('CGI=HASH(0x8d42268)',74261727,130) 
called at /home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 489
CGI::init('CGI=HASH(0x8d42268)') called at 
/home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 325
CGI::new('CGI') called at 
/home/stas/apache.org/mp2-cvs2/t/response/TestModules/cgi.pm line 31

TestModules::cgi::handler('Apache::RequestRec=SCALAR(0x8d421c0)') called 
at (eval 95) line 3
eval {...} called at (eval 95) line 3
 at /home/stas/apache.org/mp2-cvs2/t/response/TestModules/cgi.pm line 31
CGI::_compile called at 
/home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 740

CGI::AUTOLOAD('Fh','b','/home/stas/apache.org/mp2-cvs2/t/logs/CGItemp3845',0) 
called at (eval 80) line 59
CGI::read_multipart('CGI=HASH(0x8d42268)',74261727,130) 
called at /home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 489
CGI::init('CGI=HASH(0x8d42268)') called at 
/home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 325
CGI::new('CGI') called at 
/home/stas/apache.org/mp2-cvs2/t/response/TestModules/cgi.pm line 31

TestModules::cgi::handler('Apache::RequestRec=SCALAR(0x8d421c0)') called 
at -e line 0
eval {...} called at -e line 0



__
Stas BekmanJAm_

Re: log_error_core escaping change broke things

[Stas Bekman]

André Malo wrote:
* Stas Bekman <[EMAIL PROTECTED]> wrote:


Yes, but we use it to log error messages which aren't under our control.
e.g. from user's programs, like cgi scripts. what are we supposed to do?
parse and split a multiline message and invoke the logger n times?


post processing, (which was actually hard to do before and safe now).
I lost you here. what post processing?

What security fault in printing a new line and tab characters? Sorry if
I've missed this discussion. Any pointers?


The same as in access log. For example, an attacker can fake a log entry by
injecting a newline into the URL (%0a) and data that looks like a timestamp
+ message. You wouldn't have gotten it.
\ts are actually questionable. I like the escaping at this point to get a
clear distinction between spaces and tabs. I'm not sure, however, if there
are terminals that don't like them.
References can be found in the CVE-Entry:

That makes sense. I'm not talking about access_log, but error_log. I don't 
think that concern applies to error_log which may contain absolutely anything 
and i fail to see how it would be unsafe. Why not differentiate between 
different logs?

I also fail to see server/http_log.h telling anything about this newly 
introduced restriction. It was never documented as line oriented, which
means that you just changed the public API in the middle of the road, no?


It was never said/acked to be not line oriented. Where are we now?
A line in the {access,error}log consists of a timestamp
and a message. That is expected behaviour, which was broken way too long.
Sorry, Andre, but I think this is an invalid statement. Tomorrow someone will 
decide that logs shouldn't longer than 74 characters, and suggest that the API 
never said/acked to be not 74 lines long? May be it's silly example, but I 
hope you get the idea.

We may, however, decide to add an #ifdef SECURITY_HOLE_LOG_INJECTION or the
like to re-add the broken behaviour of not escaping \n.
:(

Actually it's not only about \n and \t, it's about other chars as well. Now I 
get error messages like this:

[Thu Dec 18 23:33:58 2003] [error] [client 127.0.0.1] Fh::new: Variable 
"@SAVED_SYMBOLS" is not available\teval 'package Fh; sub new {\n 
my($pack,$name,$file,$delete) = @_;\n_setup_symbols(@SAVED_SYMBOLS) if 
@SAVED_SYMBOLS;\nrequire Fcntl unless defined &Fcntl::O_RDWR;\n(my 
$safename = $name) =~ s/([\\':%])/ sprintf \\'%%%02X\\', ord $1 /eg;\nmy 
$fv = ++$FH . $safename;\nmy $ref = *{"Fh::$fv"};\n$file =~ 
m!^([a-zA-Z0-9_ \\'":/.$-]+)$! || return;\nmy $safe = 
$1;\n 
sysopen($ref,$safe,Fcntl::O_RDWR()|Fcntl::O_CREAT()|Fcntl::O_EXCL(),0600) || 
return;\nunlink($safe) if $delete;\nCORE::delete $Fh::{$fv};\n 
return bless $ref,$pack;\n}\n\n;' called at 
/home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 776\n\tCGI::_compile 
called at /home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 
740\n\tCGI::AUTOLOAD('Fh','b','/home/stas/apache.org/mp2-cvs2/t/logs/CGItemp3961',0) 
called at (eval 80) line 
59\n\tCGI::read_multipart('CGI=HASH(0x8d42248)',74261727,130) called at 
/home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 
489\n\tCGI::init('CGI=HASH(0x8d42248)') called at 
/home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 325\n\tCGI::new('CGI') 
called at /home/stas/apache.org/mp2-cvs2/t/response/TestModules/cgi.pm line 
31\n\tTestModules::cgi::handler('Apache::RequestRec=SCALAR(0x8d421a0)') called 
at (eval 95) line 3\n\teval {...} called at (eval 95) line 3\n at 
/home/stas/apache.org/mp2-cvs2/t/response/TestModules/cgi.pm line 
31\n\tCGI::_compile called at /home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm 
line 
740\n\tCGI::AUTOLOAD('Fh','b','/home/stas/apache.org/mp2-cvs2/t/logs/CGItemp3961',0) 
called at (eval 80) line 
59\n\tCGI::read_multipart('CGI=HASH(0x8d42248)',74261727,130) called at 
/home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 
489\n\tCGI::init('CGI=HASH(0x8d42248)') called at 
/home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm line 325\n\tCGI::new('CGI') 
called at /home/stas/apache.org/mp2-cvs2/t/response/TestModules/cgi.pm line 
31\n\tTestModules::cgi::handler('Apache::RequestRec=SCALAR(0x8d421a0)') called 
at -e line 0\n\teval {...} called at -e line 0\n

which is a totally ruined version of:

[Fri Dec 19 00:19:12 2003] [error] [client 127.0.0.1] Fh::new: Variable 
"@SAVED_SYMBOLS" is not available   eval 'package Fh; sub new {
my($pack,$name,$file,$delete) = @_;
_setup_symbols(@SAVED_SYMBOLS) if @SAVED_SYMBOLS;
require Fcntl unless defined &Fcntl::O_RDWR;
(my $safename = $name) =~ s/([\':%])/ sprintf \'%%%02X\', ord $1 /eg;
my $fv = ++$FH . $safename;
my $ref = \\*{"Fh::$fv"};
$file =~ m!^([a-zA-Z0-9_ \\\'\\":/.\\$-]+)$! || return;
my $safe = $1;
sysopen($ref,$safe,Fcntl::O_RDWR()|Fcntl::O_CREAT()|Fcntl::O_EXCL(),0600) 
|| return;
unlink($safe) if $delete;
CO

Re: UseCanonicalName Off *surprise*

[Jim Jagielski]

Brian Akins wrote:
> 
> We had something similar.  What we did that works is:
> 
> UseCanonicalName On
> Listen 80
> Listen 8080
> ServerName www.domain.com:80
> 
> 
> So redirects, no matter what port they came in one, get redirected to 
> port 80.  This was our desired effect.
> 

Under 1.3??
-- 
===
   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: UseCanonicalName Off *surprise*

[Jim Jagielski]

On Dec 19, 2003, at 1:35 PM, William A. Rowe, Jr. wrote:
Let me be clear (on the 1.3 side)...

one expects that given;

UseCanonicalName Off
Listen 8080
Port 80
an inbound request with a Host header of foo:80 would respond with
the redirection http://foo:80/
It does not.  The Listen port again applies until you turn 
UseCanonicalName On.

That is not the case with 1.3.29-dev. We now honor the port # as sent
by the client, no matter what Port says. If the client doesn't
send the port # in the Host header, we grab the port number via
the actual socket.

Re: UseCanonicalName Off *surprise*

[Brian Akins]

William A. Rowe, Jr. wrote:

UseCanonicalName Off
Listen 8080
Port 80
an inbound request with a Host header of foo:80 would respond with
the redirection http://foo:80/
It does not.  The Listen port again applies until you turn UseCanonicalName On.
We had something similar.  What we did that works is:

UseCanonicalName On
Listen 80
Listen 8080
ServerName www.domain.com:80
So redirects, no matter what port they came in one, get redirected to 
port 80.  This was our desired effect.

--
Brian Akins
Senior Systems Engineer
CNN Internet Technologies

Re: UseCanonicalName Off *surprise*

[William A. Rowe, Jr.]

At 11:16 AM 12/19/2003, Tony Finch wrote:
>On Fri, Dec 19, 2003 at 10:04:15AM -0600, William A. Rowe, Jr. wrote:
>>
>> UseCanonicalName Off, Host: header provided (HTTP/1.1)
>> 
>>   The host name header *excluding the host header port suffix * of the request 
>>   is concatenated to httpd 1.3's Port directive setting or the real port number
>>   in httpd 2.0.  
>
>The Port directive has some muddled ServerName/UseCanonicalName semantics
>which is what distinguishes it from the Listen directive. I think the
>behaviour you describe is intended.
>
>> Now this might appear to be a moot issue, but if a proxy that doesn't mangling
>> headers bounces requests from port 80 to another server's port 8080 attempting
>> to impersonate the front end proxy, everything should work, in theory, with
>> UseCanonicalName Off.  As it turns out, UseCanonicalName must be turned
>> on to avoid the port :8080 suffix from being appended to the redirects.
>
>In this situation you should be using Listen rather than Port. Is 2.0 different?

Let me be clear (on the 1.3 side)...

one expects that given;

UseCanonicalName Off
Listen 8080
Port 80

an inbound request with a Host header of foo:80 would respond with
the redirection http://foo:80/

It does not.  The Listen port again applies until you turn UseCanonicalName On.

Bill

Re: UseCanonicalName Off *surprise*

[Jim Jagielski]

1.3.29-dev actually changes the determination of the port value
with UCN off in effect.
The big question is if the client does NOT send a Host
header, and UCN is Off, should the port be the port
number used in the connection socket OR should we use
whatever Port is set to... The current implementation,
which I think is correct, is to use the physical port
number... The intent of UCN Off is to say, basically,
"trust whatever the client sends you, as far as
hostname and port number..." and with that in mind,
I think we should trust what port the client is talking
to in absence of Host (since that is closer to the
goal of Apache's concept of host:port not being the
final or high priority authority).
Also note that what 2.0 and what 2.1 does as far as
ap_get_server_port() with a non-existent Host header
are different... 1.3.29-dev follows the 2.1 logic.
On Dec 19, 2003, at 11:04 AM, William A. Rowe, Jr. wrote:
UseCanonicalName On
-or-
UseCanonicalName Off, but the Host: header was missing (e.g. HTTP/1.0)
  In 1.3 - the host's {ServerName}:{Port} is returned.
  In 2.0 - the host {Servername} is returned (must include port 
suffix).

there were no surprises there.

UseCanonicalName Off, Host: header provided (HTTP/1.1)

  The host name header *excluding the host header port suffix * of the 
request
  is concatenated to httpd 1.3's Port directive setting or the real 
port number
  in httpd 2.0.

Now this might appear to be a moot issue, but if a proxy that doesn't 
mangling
headers bounces requests from port 80 to another server's port 8080 
attempting
to impersonate the front end proxy, everything should work, in theory, 
with
UseCanonicalName Off.  As it turns out, UseCanonicalName must be turned
on to avoid the port :8080 suffix from being appended to the redirects.

Host headers (from my usual clients) do appear in the form
Host: localhost:8080
when the request http://localhost:8080/ is sent.  UseCanonicalName Off 
docs
state outright that we use the Host: header provided by the client.  
The example
above shows that we do not.  But if we correct the behavior, instead 
of the docs,
then perhaps users will commonly end up with broken configs.

So I'm wondering what the consensus is - fix the docs, or the behavior?

Bill

Re: UseCanonicalName Off *surprise*

[Tony Finch]

On Fri, Dec 19, 2003 at 10:04:15AM -0600, William A. Rowe, Jr. wrote:
>
> UseCanonicalName Off, Host: header provided (HTTP/1.1)
> 
>   The host name header *excluding the host header port suffix * of the request 
>   is concatenated to httpd 1.3's Port directive setting or the real port number
>   in httpd 2.0.  

The Port directive has some muddled ServerName/UseCanonicalName semantics
which is what distinguishes it from the Listen directive. I think the
behaviour you describe is intended.

> Now this might appear to be a moot issue, but if a proxy that doesn't mangling
> headers bounces requests from port 80 to another server's port 8080 attempting
> to impersonate the front end proxy, everything should work, in theory, with
> UseCanonicalName Off.  As it turns out, UseCanonicalName must be turned
> on to avoid the port :8080 suffix from being appended to the redirects.

In this situation you should be using Listen rather than Port. Is 2.0 different?

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
SHETLAND ISLES: NORTHWEST 4, EASING VARIABLE 2. LATER INCREASING EAST THEN
NORTHEAST 5 OR 6. MAINLY FAIR, ISOLATED SHOWERS. GOOD. MODERATE.

UseCanonicalName Off *surprise*

[William A. Rowe, Jr.]

In both Apache 1.3 and 2.0 the UseCanonicalName doesn't work quite as it's
documented.  The question would be, do we fix it or document it...

When requesting a document that results in a redirection (directory not
decorated by a trailing backslash, etc) the redirected server name doesn't
actually conform to the Host header provided by the client...

UseCanonicalName On
-or-
UseCanonicalName Off, but the Host: header was missing (e.g. HTTP/1.0)

  In 1.3 - the host's {ServerName}:{Port} is returned.
  In 2.0 - the host {Servername} is returned (must include port suffix).

there were no surprises there.

UseCanonicalName Off, Host: header provided (HTTP/1.1)

  The host name header *excluding the host header port suffix * of the request 
  is concatenated to httpd 1.3's Port directive setting or the real port number
  in httpd 2.0.  

Now this might appear to be a moot issue, but if a proxy that doesn't mangling
headers bounces requests from port 80 to another server's port 8080 attempting
to impersonate the front end proxy, everything should work, in theory, with
UseCanonicalName Off.  As it turns out, UseCanonicalName must be turned
on to avoid the port :8080 suffix from being appended to the redirects.

Host headers (from my usual clients) do appear in the form 
Host: localhost:8080 
when the request http://localhost:8080/ is sent.  UseCanonicalName Off docs
state outright that we use the Host: header provided by the client.  The example
above shows that we do not.  But if we correct the behavior, instead of the docs,
then perhaps users will commonly end up with broken configs.

So I'm wondering what the consensus is - fix the docs, or the behavior?

Bill
 

Re: log_error_core escaping change broke things

[André Malo]

* Stas Bekman <[EMAIL PROTECTED]> wrote:

> Yes, but we use it to log error messages which aren't under our control.
> e.g. from user's programs, like cgi scripts. what are we supposed to do?
> parse and split a multiline message and invoke the logger n times?

post processing, (which was actually hard to do before and safe now).

> What security fault in printing a new line and tab characters? Sorry if
> I've missed this discussion. Any pointers?

The same as in access log. For example, an attacker can fake a log entry by
injecting a newline into the URL (%0a) and data that looks like a timestamp
+ message. You wouldn't have gotten it.
\ts are actually questionable. I like the escaping at this point to get a
clear distinction between spaces and tabs. I'm not sure, however, if there
are terminals that don't like them.

References can be found in the CVE-Entry:


> I also fail to see server/http_log.h telling anything about this newly 
> introduced restriction. It was never documented as line oriented, which
> means that you just changed the public API in the middle of the road, no?

It was never said/acked to be not line oriented. Where are we now?
A line in the {access,error}log consists of a timestamp
and a message. That is expected behaviour, which was broken way too long.

We may, however, decide to add an #ifdef SECURITY_HOLE_LOG_INJECTION or the
like to re-add the broken behaviour of not escaping \n.

nd

Re: log_error_core escaping change broke things

[Stas Bekman]

André Malo wrote:
* Stas Bekman <[EMAIL PROTECTED]> wrote:


This change:
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/log.c?r1=1.127.2.4&r2=1.127.2.5&diff_format=h
now escapes \n and \t chars. Why in the world would you do that? How are we 
supposed to work with multilined and formatted with \t data?


We aren't. The errorlog is not supposed to store table data. It's *line*
oriented. I consider this as a long outstanding security fix not a breakage.
Yes, but we use it to log error messages which aren't under our control. e.g. 
from user's programs, like cgi scripts. what are we supposed to do? parse and 
split a multiline message and invoke the logger n times?

What security fault in printing a new line and tab characters? Sorry if I've 
missed this discussion. Any pointers?

I also fail to see server/http_log.h telling anything about this newly 
introduced restriction. It was never documented as line oriented, which means 
that you just changed the public API in the middle of the road, no? May be 
it's OK for 2.1, but definitely not for 2.0, since the moment users upgrade 
their httpd from 2.9.48 to 2.0.49 (when that's released), they won't be very 
happy about this change.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: log_error_core escaping change broke things

[André Malo]

* Stas Bekman <[EMAIL PROTECTED]> wrote:

> This change:
> http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/log.c?r1=1.127.2.4&r2=1.127.2.5&diff_format=h
> now escapes \n and \t chars. Why in the world would you do that? How are we 
> supposed to work with multilined and formatted with \t data?

We aren't. The errorlog is not supposed to store table data. It's *line*
oriented. I consider this as a long outstanding security fix not a breakage.

nd

Re: [patch] - digest nonce including MM bump, doc and changes.

[Mark J Cox]

> +  *) SECURITY - verification as to wether the nonce returned in the
> + client response is one we issued ourselves by means of a
> + AuthNonce secret exposed as an md5(). See mod_digest documentation
> + for more details. The experimental/mod_auth_digest.c does not
> + have this issue.  [Dirk-Willem van Gulik]
> +

Use CAN-2003-0987 for this issue

Mark
--
Mark J Cox ... www.awe.com/mark
Apache Software Foundation . OpenSSL Group . Apache Week editor

Re: [patch] - digest nonce including MM bump, doc and changes.

[Dirk-Willem van Gulik]

On Thu, 18 Dec 2003, Greg Marr wrote:

> Couldn't the new member be placed at the end of the request rec so
> that it's only a minor bump?

Sure - does that work across all compilers ? Or do some still do some
sort of sorting/packing depending on O level ?

Dw

log_error_core escaping change broke things

[Stas Bekman]

This change:
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/log.c?r1=1.127.2.4&r2=1.127.2.5&diff_format=h
now escapes \n and \t chars. Why in the world would you do that? How are we 
supposed to work with multilined and formatted with \t data?

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com