www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Tronche <ch.tron...@computer.org>
Subject mod_access/1328: Bytes are checked in wrong order for T_IP allowdeny_type, resulting in <Location> not working for IP mask
Date Tue, 28 Oct 1997 17:20:06 GMT

>Number:         1328
>Category:       mod_access
>Synopsis:       Bytes are checked in wrong order for T_IP allowdeny_type, resulting in
<Location> not working for IP mask
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Tue Oct 28 09:30:00 PST 1997
>Last-Modified:
>Originator:     ch.tronche@computer.org
>Organization:
apache
>Release:        1.3b2
>Environment:
SunOS 5.5 Generic_103093-06 sun4u sparc SUNW,Ultra-1
gcc version 2.7.2
>Description:
Suppose you have in access.conf:

<Location /private/>
allow from 1.2.3
</Location>

and try to access from 1.2.3.4,

in function find_allowdeny (in mod_access.c), the ap[i].x.ip.mask is set to
0xffffff and the ap[i].x.ip.net is set to 0x00010203, while the
r->connection->remote_addr.sin_addr.s_addr is 0x01020304. Thus, the check
wrongly fails. I don't think it's related to nhtol(), because it does
basically nothing on my Sparc. The bug doesn't appear with Apache 1.2.4, and
the configuration works as I expect.
>How-To-Repeat:
See description.
>Fix:
A dirty hack is to reverse the r->connection->remote_addr.sin_addr.s_addr in
find_allowdeny in the T_IP switch branch. The dirtyness comes from the value
being recomputed on every access.

A better way would be to reverse the ap[i].x.ip.net and ap[i].x.ip.mask
when parsing the configuration files, but I don't know if they're used
elsewhere, so I'm not sure. The allowdeny structure is local to the file,
anyway.
%0
>Audit-Trail:
>Unformatted:


Mime
View raw message