Date: Wed, 28 Mar 2001 12:05:43 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rsidd@physics.iisc.ernet.in (Rahul Siddharthan) Cc: chat@FreeBSD.ORG Subject: Re: Virus targetting both Windows and Linux? Message-ID: <200103281206.FAA03324@usr05.primenet.com> In-Reply-To: <20010328114017.B96090@lpt.ens.fr> from "Rahul Siddharthan" at Mar 28, 2001 11:40:17 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> Is this at all possible? > http://dailynews.yahoo.com/h/nm/20010327/wr/virus_winux_dc_1.html Maybe if you had WABI or WINE installed. It would be hard for a virus to be executable on more than one platform at a time, unless it wasn't really a virus. Interpreted code would be easier. The fact that you have to explicitly click the thing leads me to believe that it's actually a bacterium, and they haven't magically solved the ANDF problem that computer science has been fighting ever since software started being distributed. More than likely, from the user participation requirement, it's something like a "Shockwave Flash" or similar bacterium. I also doubt the 100 bytes claim; it may go looking for it, but it's unlikely that it would be able to do something about it. There's also a very simple protection step that you could use to thwart most virus code, but it would drop much of the floor out from under the antivirus market: installed images, per VMS. In other words, require priviledges to be able to mark files as executable, and don't permit ordinary users the ability to do that. VMS wasn't quite as anal: it permitted images installed with priviledges, which permitted the linker to set the exec bit, when run on behalf of an ordinary user. I rather suspect that there are sufficient priviledge exploits in most (not all) versions of Windows to make this a dubious approach on platforms with known security compromises. Likewise, a CRC or MD5 hash, stored as kernel metadata, would not be capable of being easily compromised, as long as you had a seperate signature store with which to compare it: infected files simply would not run. People have also suggested that locally, you could change your system call entry points, which would render foreign executables nonviable. It's all an arms race, anyway. A bacterium could propagate as source code, where the compiled version exploited attacks against a remote system, and then compiled itself on the new target system, and was still capable of outputting its own source code (there are programs on the net that can take a program, and make it capable of spitting out its own source code). In one experiment I did, my code would propagate to a subset of the total targettable executable files in range, and only attach itself (as a self-decompressor) if the compression achieved plus the code attached was some other threshold smaller than the original file. When a modified file was run, it would decompress the original, and execute it with the same command line arguments and descriptors, while a child was forked and run in the background to go look for more files to treat. It would only run on systems where the actual file size and data segment size were not required to be the same; that change went into the 386BSD code in 1993 or so, since it's required to permit "uncore" to work for perl, emacs, LISP, etc.. Obviously, when I wrote this, I was living under some serious disk space, but not CPU time, restrictions. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103281206.FAA03324>