I could not find any reference to this particular issue on bugtraq, and as it seems rather serious I decided to submit it.
This message concerns what seems to be a security 'feature' in all versions of InterScan SMTP VirusWall for Windows NT at least through version 3.4. The problem is not with the functionality of the product but with the behavior of its installer. This issue probably also affects installations of the FTP and HTTP VirusWall options as well, but our site only uses the SMTP 'module' of this product.
The issue is that the ISVW installer appears to use the 'cacls' command to adjust the permissions of the InterScan program directory after it completes the installation. The alarming thing is that the adjustment which is made is the addition of 'Everyone - Full Control' to the ACL. This action is taken by the installer without any notification or question to the user and regardless of what filesystem permissions were set on the filesystem or parent directory before the install. This action also appears to be taken during the course of an upgrade as well as a clean install.
As if this were not bad enough, the installer also creates a new file share which exports the same InterScan program directory; again with 'Everyone - Full Control' in the ACL and again without any notification to the user during the installation.
The result of these two actions is that immediately after the installation is completed there will be a gaping hole in the machine on which ISVW resides which allows access to the ISVW executables for anyone. This share includes the executables for the ISVW service which normally would be started each time the machine is booted. The possibilities are easily imagined...
In the real world, this feature affected one of our machines when our Exchange administrator performed an install. Because of the 'Everyone - Full Control' share, all of the ISVW executables were infected by a wandering copy of Win32 FunLove within minutes of installation, and the entire server was subsequently infected when the ISVW service was started.
Compounding this problem is the fact that in normal operation a machine running ISVW cannot have any sort of anti-virus 'auto-protect' system turned on since ISVW and the auto-protect would fight over any temporary files used by ISVW to scan infected messages. In this case we only detected the infection while running a manual virus scan a day or so after the installation.
Our exchange administrator has had an ongoing dialogue with the support department at TrendMicro over the last several weeks, but they have yet to produce either a fix or an explanation for this behavior. The last communication we received from them stated that this problem would be fixed in version 3.4, but our testing indicates that this is not the case.
The only workaround we have found so far is:
As long as the share is removed and the filesystem permissions are adjusted manually, there should be no ongoing threat from this issue (at least until the next upgrade or install...).
If any of this appears to be innaccurate based on other experiences with this product, please do not hesitate to let me know.
-- Michael W. Shaffer email: firstname.lastname@example.org Research Computing Services phone: +1 650.485.2955 Agilent Laboratories, Palo Alto fax: +1 650.485.5568