Re: lynx-dev Re: who owns what

[Bela Lubkin]

Philip Webb wrote:

> suppose i have a file  /homes/purslow/vital
> & Enemy creates a symlink to it called  /tmp/dagger :
> on CHASS the latter will have the permission  lrwx------ ,
> ie only Enemy can (over)write  /tmp/dagger -> /homes/purslow/vital ,
> but no-one else, incl me running Lynx.
> further, Enemy's write permission for  /tmp/dagger  can't allow him
> to overwrite just ANY file out there he chooses to link it to:
> it's a danger ONLY if he can delude ME into doing it for him,
> eg by running a suitable version of Lynx (or some other program),

The enemy doesn't create /tmp/dagger, he creates /tmp/L1234-1TMP.html,
which is a name that Lynx will use when you run it.  (The numbers will
vary, but he can calculate what they're likely to be.)  When Lynx writes
to that file on your behalf, it will overwrite your
/homes/purslow/vital.

Tom has put in code to avoid this, and superficially it does so.  I am
not convinced that it is air-tight.  The problem is that it does various
checks before actually writing to the file.  There's a small but real
amount of time between the checks and the writing.  The enemy can write
a program that waits for you to get to that point, and creates the
dangerous symlink during the window between check and write.  This is
called a race condition.  There have been many real-world examples of
programs which *do* breach security via exactly this kind of race
condition.  (The most famous ones have been exploits of sendmail.)

> but here on CHASS, that's impossible, since the system will choke
> when Lynx asks it to allow me to write Enemy's  /tmp/dagger :
> "You don't got permission, see:  lrwx------ ".

Symlinks would be worthless if one user could not follow another user's
symlink.  On most Unix systems, the permissions show for the link are
completely irrelevant -- `ls` shows them because it always shows
something in those fields, but the kernel ignores them.  Symlinks do not
have permissions of their own.  Your permissions towards a symlink are
based on your permissions towards the pointed-to file.

However, let us suppose that your system is different and permissions on
the symlink *do* matter.  Then there *must* be a way for the person who
creates a symlink to change its permissions (as otherwise they would be
worthless).  Therefore, the attacker must be able to grant you
permission to follow his link.  The only thing that would be different
is that he has to figure this out and add code to his attack program to
do it.

Tom's code checks not only the actual file being written, but also the
directory path it lives in.  That's because even if you own it, it can't
be trusted if it lives in an untrustable directory -- or if any of its
parents, up to the root directory, can't be trusted.  Now, aside from
the problem it caused you, this is also problematic because it adds many
more opportunities for race conditions.  So I think a different solution
is needed.  But that will be addressed later.

Meanwhile, I do agree with the notion that if a file is in (or below)
your home directory, Lynx should trust it.  I say that because, if your
home directory is untrustworthy (e.g. if it has permissions that allow
anyone to write files into it), there are endless ways to attack you.
Lynx can't help you.  It's like locking the door of a car when the
window is rolled down.

>Bela<