[vox-tech] Re: [vox] Linux viruses?

[Ken Bloom]

On 2004.06.15 14:43, Jeff Newmiller wrote:
> On Tue, 15 Jun 2004, Micah J. Cowan wrote:
> 
> > On Tue, Jun 15, 2004 at 09:32:39AM -0700, Jeff Newmiller wrote:
> > > On Mon, 14 Jun 2004, Micah J. Cowan wrote:
> > >
> > > [...]
> > >
> > > > I have also felt that the very low market-share of Mac OS (in
> > > > comparison to Winblows) simply kept the attention of virus- 
> writers
> off
> > > > of it.
> > >
> > > I used to be a Mac-phile back in Mac128 and MacPlus days.
> >
> > So was I.
> >
> > > I used to
> > > collect lots of Mac software off of USENET binary distributions
> > > newsgroups.  Virus problems were much worse in that OS than under
> DOS,
> > > because with code stored in the structured Resource Fork, adding
> > > pre-execution code was relatively easy.
> >
> > I don't see how that made it more easy than to add code to a DOS
> > executable, and remembering from those days, I'm surprised to hear  
> you
> > say it was much worse than for DOS: my recollections are somewhat
> > different.
> 
> I thought the grammatical construction "that OS" followed by "than  
> under
> DOS" would have made my meaning clear.  Anyway, you apparently _did_
> misunderstand me... DOS executables don't have structured resource  
> forks
> with relocatable code all over the place, so infecting DOS executables
> required some tricky code alterations, and there wasn't much memory to
> "hide" in.

Here is an example of such bad code (see also my post on the topic at  
http://apple.slashdot.org/comments.pl?sid=103394&cid=8810110, although  
it's very brief):

The Macintosh system had system calls that allowed one to very easily  
manipulate the resource fork of any file, adding and removing resources.  
Given a resource type (MENU) and a resource number (145), there was a  
system call that would find the resource on disk, load the resource into  
memory, and return a pointer to that chunk of memory. All done in a very  
standardized way. And there was another call which did the reverse. All  
in a very standardized way.

The operating system stored a lot of important things in the resource  
fork of its own files - the System file (which contained most of the OS  
code) was stored entirely in the resource fork, and the System file's  
resource fork was a part of the "resource chain" for every running  
application.

The resources were well formatted. It was well known, for example, how to  
read and edit MENU resources (which defined the items on a menu) or WIND  
resources (which defined the sizes, and titles of windows of resources),  
and where certain pieces of data belonged in these resources.

In MENU and WIND resources (as well as a few others), one of the data  
fields was a resource number for a code resource that could be used to  
customize how the menu or window was drawn. For example, in the MENU  
resource, one could specify that resource 145 was to be used to draw the  
menu. And the system knew that when a MENU asked it to load #145, that it  
needed to load MDEF resource 145. (There was a standard MDEF resource  
that most programs used to draw their menus, so the programmers didn't  
have to relearn from scratch - it resided in the System file.)

All of this was very automatic. When your program specified that MENU  
#243 needs to be on the menu bar, the system would load MENU #243, and  
whatever MDEF it asked for. The next time the user would click the menu,  
forcing it to draw itself, the MDEF would execute.

How would this work for a virus? Supposing this were an MDEF virus (a  
virus that lived in an MDEF resource)

The virus is distributed in some kind infected application (maybe it  
starts off life in a trojan horse). The user clicks the menu, and the  
MDEF virus runs. The MDEF virus says to itself "I'm running. I'm know  
that I always live in MDEF #145", so it uses the generic resource manager  
system calls to load MDEF #145 into memory. It then proceeds to find  
another unsusptecting file (usually an application program) to infect. It  
opens the file, uses the generic resource manager calls to save that  
piece of memory into MDEF #145 in the new file. Then it loads up all of  
the MENU resources in that file and changes them so that they will use  
the infected MDEF #145 to draw themselves. It closes the file because  
it's done infecting that file. Presto: a new program has been infected.

This is easier than DOS, where you'd need to deal with the whole  
executable. The virus would need to find its own code (which would  
probably be living at a relatively random place in the file) - one would  
need to then read the virus, find a file, and write the virus to a  
location in the new executable, without breaking that executable. This  
took a knowledge of assembly language and machine language that Macintosh  
viruses did not need.

Despite all this, the only Macintosh virus I ever saw in the wild was  
MerryXmas, a HyperCard virus which had a completely different attack  
vector. Yes, folks, when the news came out that a Microsoft product was  
the first product that could spread viruses in *documents* rather than  
executables, I already knew that it wasn't unique. HyperCard viruses had  
already been spreading for in HyperCard stacks years.

Despite all this, the viruses that spread today are *much* less crafty  
than anything you needed to do on the Mac or DOS.

-- 
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.
My key was last signed 10/14/2003. If you use GPG *please* see me about
signing the key. ***** My computer can't give you viruses by email. ***
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rod.livepenguin.com/pipermail/vox-tech/attachments/20040615/d2dee538/attachment.bin