On Thu, 27 Nov 2008 19:10:34 -0500, David Boyes <[EMAIL PROTECTED]> wrote:
>On 11/26/08 1:47 PM, "Michael Coffin" <[EMAIL PROTECTED]> wrote: > >> Let me play devil's advocate for just a minute. WHAT would actually >> constitute a "virus" in a VM/CMS environment? >> We don't have the "backdoors" and "automatic program execution" stuff >> that comes out of Redmond, so you don't have to worry about, for >> example, XEDITing a file and it launching a program without your >> approval that formats your 191 disk. > >One possible vector would be the CMS installation segment. If a suitably >privileged userid were compromised, an app could be developed that modified >the NSS spool file directly, and you could introduce either a nucleus >extension with a common command name, or a load of another segment that got >you some malicious code. Since the installation segment gets control before >your PROFILE EXEC or most other user-controlled stuff gets control, you' re >hosed before there's much chance to detect it. Maybe it's a matter of symantics, but what you've described is a trojan horse on an already compromised system. A virus is something that replicates automatically from one system to another system. Just because *your* system has been sucessfully co-opted doesn't mean *my* system is a t increased risk of being compromised or infected. If you define "system" as "CMS guest" then you would have a virus, but limited to one z/VM platform. One potential vector for malicious code is through the VM DOWNLOAD PACKAGES. However, this requires willful action by a site to download an d install the package. In this case, you're putting your trust in that the hosting site has not been compromised such that the available packages ca n be modified, and that you trust the contributor of the package. Of course, if you only run such code in virtual machines without special privileges, authorizations, or access to data that could compromise another virtual machine then your risk is pretty small. Brian Nielsen
