Dave Wolfe <dwolfe@risc.sps.mot.com> wrote:
> [ Walt Haas writes: ]
> >
> > The problem was that any address beginning with a "/" was treated as HOSTIL
> E,
> > so an address like "/G=Lena/S=Paulsen@mhs-opic.attmail.com" could never
> > subscribe. The reason turned out to be the line that said
> >
> > local(@components) = split( /\//, $_);
> >
> > The split function caused $components[0] to always be the null string if
> > the first character of the address was "/". Thus when the string
> > /$components[0] was tested, it evaluated to "/", the filesystem root, and
> > I guess writing to that would be pretty hostile :-)
> >
> > The fix was to break up $addr properly. Here's the patch:
> >
> > 511c511
> > < local(@components) = split( /\//, $_);
> > ---
> > > local(@components) = ($_ =~ /([\/\@]?[^\/\@]+)/g);
>
> Will an X.400 address ever *not* start with a '/'? If so, then this
> wouldn't work right. Looking at 1.93, a line was dropped in 1.94 between
> the split and the test:
>
> # strip null element for / at beginning of address
> # since the "/" directory always exists.
> shift(@components) if ( $components[0] eq "" );
>
> Does anyone know why? I think the fix is to restore these lost lines,
> perhaps with some better comments.
Actually, I didn't know that was in 1.93 (didn't look, duh) but that was
in fact the first thing I tried.
Here's the logic, as far as I can parse it:
Any address with a forward slash in it is considered hostile, I guess
on the assumption that somebody might be trying to subscribe a Unix
pathname to the list [I question whether this makes sense; doesn't
sendmail defend against that? What about MTAs running on systems
which delimit files with something besides "/"?]
X.400 addresses are real addresses, and therefore should be accepted for
subscription to the list.
So if a command to subscribe contains an address with a "/", it should
be treated with skepticism, but accepted if it looks like an X.400 address.
So the logic is to compare the username portion of the remote address
against the *local* filesystem [why? aren't we trying to protect the remote
filesystem?] and, if the username looks like a path in the local filesystem,
then we consider it hostile.
The 1.94 code split the address "/G=Lena/S=Paulsen@mhs-opic.attmail.com"
as follows:
$components[0] = "";
$components[1] = "G=Lena";
$components[2] = "S=Paulsen@mhs-opic.attmail.com";
then tested the local filesystem against both
"$components[0]" and "/$components[0]".
"/$components[0]" was always found for any address starting with a "/".
The 1.93 code throws away $components[0] if it is "".
Now consider the following form of address, from one of my lists:
khiggins/STLIB_SALSA@stlib.state.nm.us
ljensen/STLIB_SALSA@stlib.state.nm.us
I don't know what kind of email system they have, but those addresses
are legal per the RFCs so we need to support them.
They contain a "/" so they are checked against the local filesystem.
My logic breaks the first address up as follows:
$components[0]="khiggins";
$components[1]="/STLIB_SALSA";
$components[2]="@stlib.state.nm.us";
A stat() for both "khiggins" and "/khiggins" fails, so the address is
not hostile.
If the address were:
usr/STLIB_SALSA@stlib.state.nm.us
then it would be treated as hostile.
Note that my regexp starts "[\/\@]?", so the initial / is optional.
I still don't know why we should care. I'd vote for taking out the
entire hostile address test - in fact, that was the first thing that
I did when I started having these addresses rejected as hostile. Then
I decided it might be better to actually try to figure out what's
going on.
-- Walt
-------
"Change is necessary. Change is good." - Lonnie Burton
"If you don't like those ideas, I got others." - Marshall McLuhan
Follow-Ups:
References:
|
|
