COMMAND
MS Office
SYSTEMS AFFECTED
MS Office 2000, Win98/Win2000
PROBLEM
Georgi Guninski found following. If certain DLLs are present in
the current direcotory and the user double clicks on a MS Office
Document or launch the document from "Start | Run" then the DLLs
are executed. This allows executing native code and may lead to
taking full control over user's computer. It also works on remote
UNC shares.
If either of the following files: riched20.dll or msi.dll (other
DLLs also may do, don't know) are present in the current directory
double clicking on an Office document in the current directory
executes the code in DllMain() of the above DLLs. (Excel seems
not to work with riched20.dll but works with msi.dll). Georgi
could not make this work from HTML and IE.
Demonstration:
1) Download dll1.cpp from http://www.guninski.com/dll1.cpp and
build it. We discourage downloading native code from
unknown site, but you may try at your own risk the compiled
version: http://www.guninski.com/dll1.dll
2) Rename dll1.dll to riched20.dll
3) Place riched20.dll in a directory of your choice
4) Close all Office applications
5) From Windows Explorer double click on an Office document
(preferably MS Word document) in the directory containg
riched20.dll
Now, imagine an intruder that has penetrated a company. He has
obtained access to the companies file server which is used only
to share data files, but he has not obtained access to the CEO's
computer in which the data he wishes to obtain is stored. By
looking at the file share traffic he knows the CEO opens Office
documents on the file server, but he is a security conscious guy
and has disabled all macros and other dangerous functionality.
The intruder is out of luck...
...Until now. Now the attacker only needs to drop a malicious DLL
into the same folder as a file he knows the CEO opens on a regular
basis on the file server and wait until he opens it and the DLL
has not already been loaded. This is not an uncommon state. For
example, this is the case when opening a for the first time
document after the machine has rebooted. Once the malicious DLL
loads the intruder has full access to the CEO's system.
Also, consider the case of an e-mail program which, like many on
the market, places all attached files in a particular directory,
and offers a way to open these documents from within the
message-viewing screen. These programs often invoke the same or
similar code paths as double-clicking the document itself. In
this case, the user will see two files -- the document and the
dll. They may believe that they are safe if they simply do not
execute the dll. However, by launching the document they will
invoke the code in the dll. They could even have installed
protection against "macro virii" and believe they are safe from
malicious documents.
When the system starts a program that uses load-time dynamic
linking, it uses the information in the file to locate the names
of the required DLL(s). The system then searches for the DLLs in
the following locations, in sequence:
1. The directory that contains the module for the current
process.
2. The current directory.
3. The Windows system directory. The GetSystemDirectory
function retrieves the path of this directory.
4. The Windows directory. The GetWindowsDirectory function
retrieves the path of this directory.
5. The directories listed in the PATH environment variable.
In addition, if you use LoadLibaryEx you can specify a path for
the module you want to load.
Assuming this, the following conditions must be met to reproduce
the problem discovered by Georgi Guninski:
1. The DLL you want to fake must not have been loaded into
memory by any program yet. Windows will use the copy
already in memory in that case.
2. The targeted program (e.g. MS Word) must not have the DLL
in the same directory as it's executable.
If the program is executed under this conditions, by clicking on a
associated file, the DLL in the current directory (which is the
one the the file you click on is in) is used. There seems to be
an added complication. Sometimes, NT/2000 always loads the torjan
DLL (95/98 not tested). Fernando Trias has been playing with
wordpad by executing wri files. Even if wordpad is loaded, it
will always execute the trojan DLL if it is riched32.dll,
imm32.dll or gapi32.dll. Other DLLs seem to behave as you
indicated.
Below illustrates that this exploit works in internet explorer 5.5
in ftp mode. Clicking on an ftp link in internet explorer (or
redirecting via scripting or even meta tag refresh) converts IE5
into ftp mode, which if the *.dll is in the same directory as a
word document on the ftp server, the *.dll executes. You don't
have to download the *.dll and you don't have to use Windows
Explorer. IE5.5 and probabaly all IE5's in ftp mode do this just
fine. Also probably the majority of people have disengaged the
'confirm after download' for word documents, which means there is
no warning to this at all.
There is good success executing this with Internet Explorer 5.5 in
ftp mode:
ftp://123@abcedf.com/public/test/ohmy.doc
(obviously not a working example), but linking that either to
href or script takes you to the directory with both the *.dll and
*.doc -- the *.doc opens up and this is what we find:
1. The "hello world" message is executed
2. The "starting or trying test.exe" message is executed
3. DOS box comes up
4. THEN the *.doc is downloaded and opened in Word
5. THEN there are a series of memory errors and other errors
related to windows (?)
A whole series of events and errors after the *.dll is executed.
IE5.5 patched to date. Win95 system. It can be negated by
'confirm open after download' for *.doc under view|file
types|word|-- this will bring up a download warning. Of course if
you want to attack your friend, send him a link to that plagerised
essay he's been nagging for, and install back orfice in his
machine at the same time. He'll be expecting the *.doc to
download...
Another thing mentioned by Todd Ransom. Most mid to large
companies have workgroup, departmental, or public file shares for
sharing documents. By definition these file shares have to be
writable by the department or workgroup who uses them. You decide
to write a trojan riched20.dll that adds an admin account to the
domain and put it in \\server\public <file://\\server\public>.
Then You put a word doc out there, remove your own permissions
from it to ensure they will have to open it as an admin account,
and call support. presto. Most of the financial institutions get
pretty uptight about this type of scenario.
SOLUTION
Do not double click on Office documents or use "Start | Run...
office.doc". Instead start the Office application from "Start
Menu" and then use "File | Open".
Both the Office and IE Security Teams checked into the report,
and our overall conclusion is that, although there are
circumstances under which a trojaned .dll could be launched as
discussed in the report, there isn't a compelling exploit
scenario. Well, that's MS.
True, but you can protect the user from himself by setting
appropriate permissions on all corporate shares. First rule: data
shares are for data only, not executables. Second rule: users
may write to data shares, but not other shares. Then the admin
must do two things:
1) Set the NTFS permissions so that users may not Execute any
files on the data share.
2) Set the Share permissions to Everyone:Change instead of the
default Everyone:Full.
This latter protection prevents users from changing the NTFS
permissions on files/directories, *even if they are the owner*.
An admin can also set up a separate Programs share for
executables, but no users should be able to write to this share
at all. Of course the above does not protect against a user
being tricked into opening a document from a share under the
attacker's control somewhere out on the Internet. "Standard
firewall practices" blocking incoming and outgoing NBT/CIFS/SMB
should take care of that.
Note however that you cannot protect the user from files on
*local* drives in quite the same iron-clad way. You can set NTFS
permissions to disallow Execute on files, but the Owner of the
file can override this by changing the ACL on the file.
More resources for a possible solution for the MS Office document
issue.... From MSDN:
"Activating DLL/COM Redirection
DLL/COM redirection is activated on an application-by-application
basis by the presence of a ".local" file. The ".local" file is
an empty file in the same directory as the application's .exe
file, with the same name as the application's .exe file with
".local" appended to the end of the name.
For example, to activate DLL/COM redirection for an application
called "myapp.exe," create an empty file called "myapp.exe.local"
in the same directory where myapp.exe is installed.
Once DLL/COM redirection is activated, whenever the application
loads a DLL or an OCX, Windows looks first for the DLL or OCX in
the directory where the application's .exe file is installed. If
a version of the DLL or OCX is found in the directory where the
application's .exe file is installed, the application uses it
regardless of any directory path specified in the application or
the registry. If a version of the DLL or OCX is not found in the
directory where the application's .exe file is installed, the
normal search path or server path is used."