[16819] in bugtraq
Re: Double clicking on MS Office documents from Windows Explorer
daemon@ATHENA.MIT.EDU (Timothy J. Miller)
Tue Sep 19 14:17:04 2000
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <87bsxlbesc.fsf@zoot.kelly.aftd.af.mil>
Date: Mon, 18 Sep 2000 15:56:03 -0500
Reply-To: "Timothy J. Miller" <cerebus@SACKHEADS.ORG>
From: "Timothy J. Miller" <cerebus@SACKHEADS.ORG>
X-To: Microsoft Security Response Center <secure@MICROSOFT.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Microsoft Security Response Center's message of "Mon, 18 Sep 2000
11:58:41 -0700"
Microsoft Security Response Center <secure@MICROSOFT.COM> writes:
> We considered two cases. In the first one, a malicious user would
> seek to persuade a user to download a malicious version of
> riched20.dll or msi.dll onto the user's machine, in the same
> directory as an Office document. The malicious user would then
> persuade the user to open the Office document. In the end, this case
> turns out to be simply a case of persuading the user to download and
> run untrusted code -- and if the malicious user can do this, there
> are far easier ways to accomplish the same goal.
It strikes me that the subverted DLL need only be present in a
directory containing openable objects. At that point, *any* object
opened via the shell (rather than loaded into a running program) that
utilizes the "overloaded" DLL will execute the malicious code
contained therein.
While the problem of delivering the subverted DLL is still open, this
is not the same as delivering and persuading the user to open a
trojaned document. The user is opening *his* documents, known to be
clean. It is the system that has been subverted-- without violating
any access privileges, I might add.
The trojan DLL can, of course, be delivered in multiple ways-- adding
it to a ZIP file, for instance, or placing in a public share where
openable objects reside. The mind boggles.
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.
-- Cerebus
