lev@suned1.Nswses.Navy.Mil (Lloyd E Vancil) (05/26/91)
I have a question.
In the form of a senario;
Given: A BBS service distributes a program that you must run in your
machine to use the service. ( ;-) guess who! ) This service becomes
very popular with computer users who are less technically inclined.
It is very flashy and popular with children. As part of the program a
very large file is installed in the PC's disk that is used to "stage"
graphics "primitives" screens.
Investigation reveals whole blocks of ram have been dumped to the
file. Typical finds include, dos environment information, disk
directories, pieces of files that were deleted by dos (but not removed
from the disk surface).
I'm just enough of a skeptic to ask why "Whole chunks of ram" are
dumped, but that's a question for comp.programmer
Here's the virus question.
Question:
Would it be possible;
1. for a memory resident virus to be scooped up by this service..
and return to reinfect the machine at a later date? Presumably
by the service's reusing of the file fragment that contains the
"screen primitive" and the "scooped" virus code.
2. for a virus to be written to take advantage of this transmission
method?
(I'm not sure that the "service" retains a complete copy of it's
users "staging file"; after all they claim nearly 1 million
users and at ~1meg per user that's 10^12 bytes? (wow) And I'm
not sure the data from one user is seen by another's machine.)
- --
| suned1!lev@elroy.JPL.Nasa.Gov | * S.T.A.R.S.! . + o |
| lev@suned1.nswses.navy.mil | The Revolution has begun! . + |
| sun!suntzu!suned1!lev | My Opinions are Mine mine mine hahahah!|VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) (05/29/91)
>From: lev@suned1.Nswses.Navy.Mil (Lloyd E Vancil) > ... >(I'm not sure that the "service" retains a complete copy of it's > users "staging file"; after all they claim nearly 1 million > users and at ~1meg per user that's 10^12 bytes? (wow) And I'm > not sure the data from one user is seen by another's machine.) (wow)? Not really *that* awesome... This is only 1 terabyte (1000 gigabytes). Something the PC world has to remember is that the mainframe world is *designed* to deal with *very* large databases. For instance, we run a medium-large IBM mainframe shop (1 3090 and 1 3084, maybe 90MIPS between them), and we have 300 gigabytes of disk here - that's already 30% of that terabyte. And we're NOWHERE near capacity - rough back-of-envelope calculations show that a 3090 with 128 I/O channels (say 96 of them for disk, the rest for TP and tapes and the like) and 256 mod 3390 disks per channel (at 1.5 gigabytes a disk) can address 36 terabytes of disk storage. Unless I dropped a decimal point someplace, you'd only need a room about 250 by 200 feet to store this. (Yes, I know I'm over-simplifying channel loading and similar constraints - most *real* shops with this much disk run multiple CPU's, etc etc) Bottom line - out in the commercial world of major banks, stock brokerages, insurance houses, airline reservation systems, and other large corporations, a mere terabyte of disk isn't considered all that much. Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute
msb-ce@cup.portal.com (05/29/91)
In a recent VIRUS-L posting, lev@suned1.Nswses.Navy.Mil (Lloyd E
Vancil) refers to a recent tempest in a teapot about the cache file
used by Prodigy and asks:
Would it be possible;
1. for a memory resident virus to be scooped up by this service..
and return to reinfect the machine at a later date? Presumably
by the service's reusing of the file fragment that contains the
"screen primitive" and the "scooped" virus code.
2. for a virus to be written to take advantage of this transmission
method?
My understanding of this situation is that in order to cache TeleTex
screens, the Prodigy service allocates about a meg of disk space and
writes screens to it for later recall. Since the space is never erased
(for performance reasons), it still contains remnants of old files
that previously occupied the space. As far as I know, these remnants
are never read from disk, much less transmitted back to the host.
Somebody with a file viewer peered into this cache area one day and
imagined that the software had gone to other files and "scooped up"
their contents for some nefarious purpose.
It is possible that the area allocated to STAGE.DAT might have
previously contained an infected file, but since it should never be
read before it has been written over there can be no question of it
providing any sort of reservoir of infection.
The answer, then, must be NO to both questions.p1@arkham.wimsey.bc.ca (Rob Slade) (06/01/91)
lev@suned1.Nswses.Navy.Mil (Lloyd E Vancil) writes: > Given: A BBS service distributes a program that you must run in your > machine to use the service. ( ;-) guess who! ) This service becomes > > Investigation reveals whole blocks of ram have been dumped to the > file. Typical finds include, dos environment information, disk > directories, pieces of files that were deleted by dos (but not removed > from the disk surface). > > Would it be possible; > 1. for a memory resident virus to be scooped up by this service.. > and return to reinfect the machine at a later date? Presumably > by the service's reusing of the file fragment that contains the > "screen primitive" and the "scooped" virus code. > > 2. for a virus to be written to take advantage of this transmission > method? > > (I'm not sure that the "service" retains a complete copy of it's > users "staging file"; after all they claim nearly 1 million Given a virus infected file which had been deleted "normally" (i.e. in MS-DOS the file is still there but the directory listing is removed) it is possible for the infective/viral code to appear in this purported file. (Shall we call it, say, STAGE.DAT?) My understanding is that the information contained in our theoretical file is data, and that it is "viewed" rather than being "run". If, however, the system used a "resource" type system (such as the Mac does), it may be possible for portions of the file to be "run", and then the danger of reinfection is possible. Given the very large size of our theoretical file, one can note that very little, if any, of it could be transmitted during the time the "send data" LED is on. The risk of the information being transmitted to the central service and redistributed is therefore extremely remote. It would take a prodigious effort to infect users this way, but it is not outside the bounds of possibility. ============= Vancouver p1@arkham.wimsey.bc.ca | "If you do buy a Institute for Robert_Slade@mtsg.sfu.ca | computer, don't Research into (SUZY) INtegrity | turn it on." User Canada V7K 2G6 | Richards' 2nd Law Security | of Data Security