httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: Improper string concatenation in mod_alias allows code execution out of bounds defined in apache config file.
Date Mon, 08 Feb 2016 17:21:53 GMT
So after a little more digging, Roy's observation (As documented)
was correct... for the case of matching trailing-slashes, both with
or both omitted.

All of this dates to well before 2.0.55... and there is absolutely
no argument that an Alias src with a trailing slash, including "/"
should ALWAYS be specified to an target with a trailing slash.

Looking at a simple example...

mv icons/small icons-small

<Directory "/path/to/apache">
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted

Alias / /path/to/apache/icons

Note that for httpd to interpret the http://example/-small/ path, the
parent directory MUST be accessible.

In the default case, while icons/ directory would normally be accessible
and /path/to/apache is not accessible, icons-small/ pathname cannot
be resolved by mod_alias.

By opening up access to /path/to/apache - now mod_alias can evaluate
"-small" in the parent directory and resolve the pathname to icons-small/.

In the usual cases...
Alias /ico /path/to/apache/icons
Alias /ico/ /path/to/apache/icons/

The url http://examples/-small/ does *NOT* resolve, so those docs
are correct when the user follows the directions.

But this is not unique to "Alias / /target"... tweaking the example;
Alias /ico/ /path/to/apache/icons
also results in http://example/ico/-small/ resolving to icons-small/
path if the server is allowed access to the parent directory.

This all matches between 2.0.55 and 2.4.18 mod_alias, no changes
in behavior.

Is it sensible for us to simply add a configuration warning in the
next 2.2 and 2.4 releases?  As reporter observes, this isn't a unique
mis-configuration.  And not all users read the docs.

I think my text below should have stated;

Note that unexpected expansion occurs when trailing slashes are
not balanced between the source url and target path.  For example,
Alias / /usr/share/htdocs
will resolve as /usr/share/htdocs-private/
Alias /content/ /usr/share/htdocs
will similarly result in the the URL /content/-private/ resolving to the
path /usr/share/htdocs-private/

The statement could use some word-smithing.

On Mon, Feb 8, 2016 at 10:37 AM, William A Rowe Jr <>

> Thanks Eric, now looping back to
> to see if this behavior was changed, by which commit, so that we ensure
> the docs match the behavior and can determine what the "correct" behavior
> was supposed to be in the first place :)
> On Mon, Feb 8, 2016 at 10:26 AM, Eric Covener <> wrote:
>> quite old:
>> On Mon, Feb 8, 2016 at 11:25 AM, William A Rowe Jr <>
>> wrote:
>> > On Mon, Feb 8, 2016 at 10:20 AM, William A Rowe Jr <
>> >
>> > wrote:
>> >>
>> >>
>> >> This is worthy of discussion on docs@httpd, so please allow me to cite
>> >> your example... Your report does suggest that we might illustrate this
>> alias
>> >> effect more clearly in the docs, e.g. an example like this;
>> >>
>> >>   Note that unexpected expansion may occur when trailing slashes
>> >>   are omitted, including the case of "Alias / /foo". Given the example;
>> >>     Alias /icons /usr/share/icons
>> >>   A request for /icons/small.gif is mapped to
>> /usr/share/icons/small.gif
>> >>   A request for /icons-private/small.gif is mapped to
>> >> /usr/share/icons-private/small.gif
>> >>   This behavior is by-design.

View raw message