WHMurray@DOCKMASTER.NCSC.MIL (04/20/91)
Copyright (c) 1991 Part 1 of N. Our gentle moderator notes that: >Also, privileged users can bypass file protections. If a privileged >user executes an infected file, the LAN may become infected - again >without the virus having any knowledge that it is infecting a LAN. This is a good point that deserves elaboration. First, what privileges are we talking about? In order for a user to infect a program on a LAN, he must be privileged to write to the program and the program must be writeable. That is, he must have WRITE "rights" ("rights" are the privileges in the language used with many LAN servers) to the program or he can not infect it. He need not be a "privileged" user in the sense of having SUPERVISOR privileges, though that will clearly work. If he has WRITE privileges to the program, he still may not be able to WRITE to the program if it has an "attribute" of READ ONLY or EXECUTE ONLY set on. Thus two conditions must be met in order for the user to be able to infect a program. The manager of the LAN server can make it resistant to infection by granting WRITE privileges sparingly and using READ ONLY and EXECUTE ONLY generously. One other privilege is relevant, i.e., MODIFY rights. Some viruses simply set all attributes on a target off before trying to write to it. In DOS, attributes can be reset by any user. However, in order to set an attribute on an object stored on a LAN server, the user program must have MODIFY rights to the object. Thus, the manager of the LAN server may defeat his broad use of READ ONLY or EXECUTE ONLY by granting MODIFY. So, no action of a workstation user can result in the infection of a program stored on the LAN server as long as that program is READ ONLY or EXECUTE ONLY and he does not have the right to MODIFY those attributes. No action of his can result in the infection of a program stored on the LAN server if he does not have WRITE privileges (rights) to that program. If the workstation user has no WRITE access to any program objects stored on the LAN server, then no action of his can cause the infection of anything on the LAN server and it cannot serve as a vector to move the virus to any other workstation on the LAN. The ability of a user to infect a program stored on the server is necessary but not sufficient for the server to act as a vector. In addition to the program being infected by one user, it must be executed by another. Thus, if a workstation user cannot write to an object stored on the LAN server that can be read by any other user, then he cannot spread the virus to another user. Thus, if the manager of the LAN server does not grant one user READ access to any object to which he grants another user WRITE access, he will make his server resistant to spreading viruses. Thus, it is possible to configure and manage a LAN server so as to make it very resistant to spreading viruses. However, I am sure that most of you understand the limitations inherent in these statements. Many users will have some WRITE access to programs which can be read by others. Any such can be a vector. One obvious vector is the \SHARE directory with which many LAN servers are configured. N.B., a virus need not know anything about the LAN in order for the LAN to serve as a vector. It need only treat all targets the same, wtihout regard to where they are stored. None of the common viruses do know anything about LANs. Note also, the virus need not defeat or bypass any of the security features of the LAN in order for the server to act as a vector. It need only exploit the privileges of the user. Neither does it have to execute on the server or infect any program that will execute on the server. Finally, notice that if a user signs on to a workstation that is already infected by a virus, then the virus will act with his server privileges. If the SUPERVISOR signs on from an infected user workstation, then his privileges will be used by the virus to infect programs stored on the LAN server. Since the boot sector or partition table of the workstation may be infected, a privileged user should never sign on to the server except when he has initialized the workstation from a (personal) trusted copy of DOS. William Hugh Murray, Executive Consultant, Information System Security 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL