[16834] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Double clicking on MS Office documents from Windows

daemon@ATHENA.MIT.EDU (Crist Clark)
Tue Sep 19 20:23:26 2000

MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39C7CA08.6D279614@globalstar.com>
Date:         Tue, 19 Sep 2000 13:18:16 -0700
Reply-To: Crist Clark <crist.clark@GLOBALSTAR.COM>
From: Crist Clark <crist.clark@GLOBALSTAR.COM>
To: BUGTRAQ@SECURITYFOCUS.COM

"Timothy J. Miller" wrote:
[snip]
> The DLL search order logic is functionally equivalent to having a '.'
> in the $PATH of a UNIX user.  This is known to be bad practice, since
> it allows this kind of shennanigans.
>
> I suggest that this problem, and subsequent problems of this nature,
> can be fixed simply by *not* looking in the current directory for
> required DLLs.

To use your $PATH analogy to emphasize what I see as the most dangerous
(and the part showing the most ill conceived design), this is like putting
'.' in your $PATH _before_ /bin, /usr/bin, and the other standard system
paths.

Checking the current directory is somewhat of a security threat. Checking
the current directory _before_ system directories is a severe threat. Like
most security issues, there is a security-convenience trade. Searching
the PWD at all leans towards convenience, but IMHO, is justifiable. However,
going to the PWD before the system directories is just too risky and I see
little added value.

Of course, the most ideal situation is to have the behavior configurable.
For Win*, a registry entry sepcifying where to look and in what order (with
conservative vendor distributed defaults) would seem the best solution,
but is undoubtably costly to implement.
--
Crist J. Clark                                Network Security Engineer
crist.clark@globalstar.com                    Globalstar, L.P.
(408) 933-4387                                FAX: (408) 933-4926

home help back first fref pref prev next nref lref last post