donw@zehntel (Don White) (09/13/88)
[simple mind, simple idea. It's not just a good idea. It's the way i am.]
Do you supose it would be difficult for Commodore to put a little CRC
check in their Kickstart and Workbench Boot blocks to INSURE that no
virus had been installed? Any time you do boot, a message could come
up saying "Kickstart HAS BEEN TAMPERED WITH!!!" and/or "Workbench HAS BEEN
TAMPERED WITH!!!" if such is the case.
Is there any reason that this virus baloney has to drag on and on?
Don White
zehntel!donw
{ihnp4 | akgua | seismo | tektronix}!zehntel!donw
Box 271177 Concord, CA. 94527-1177
P.S. Brian Moffet, I am still trying to get through to you with email.
Are you out there?
dzenc@hermes.ai.mit.edu (Daniel Zenchelsky) (09/13/88)
In article <681@zehntel.UUCP> donw@zehntel (Don White) writes: >[simple mind, simple idea. It's not just a good idea. It's the way i am.] > > Do you supose it would be difficult for Commodore to put a little CRC > check in their Kickstart and Workbench Boot blocks to INSURE that no > virus had been installed? Any time you do boot, a message could come > up saying "Kickstart HAS BEEN TAMPERED WITH!!!" and/or "Workbench HAS BEEN > TAMPERED WITH!!!" if such is the case. > > Is there any reason that this virus baloney has to drag on and on? Two reasons why that won't work: 1) Virus code can be made to match the checksum. 2) The checksum can be made to match the virus code Oh well... -Dan +-----------------------------------------------------------+ | ______ | | || |o| Daniel Zenchelsky -- dzenc@hermes.ai.mit.edu | | ||___| | | | | _ | "If it's not in the computer, it doesn't exist" | | \_[]_|_| | | | +-----------------------------------------------------------+
jimm@amiga.UUCP (Jim Mackraz) (09/14/88)
In article <681@zehntel.UUCP> donw@zehntel (Don White) writes:
)[simple mind, simple idea. It's not just a good idea. It's the way i am.]
)
) Do you supose it would be difficult for Commodore to put a little CRC
) check in their Kickstart and Workbench Boot blocks to INSURE that no
) virus had been installed? Any time you do boot, a message could come
) up saying "Kickstart HAS BEEN TAMPERED WITH!!!" and/or "Workbench HAS BEEN
) TAMPERED WITH!!!" if such is the case.
Yes, a damn good reason: there is no way to stop people from writing
viruses, and challenging them to beat the new system is not a wise
move.
) Is there any reason that this virus baloney has to drag on and on?
Yes, because hackers choose to do it. I only see two things that can
improve things:
1) identify that there are better things to do with software talent than
write viruses, both from a notoriety and a cash-money point of view.
I would think that some of these virus writers are getting pretty damn
good at Amiga programming. I'd hope that they realize that making that
a long-term money-making talent is strongly influenced by how they
spend their efforts. A good demo in place of a good virus spreads
almost as fast and does net good for the machine, rather than making
it less acceptable. And of course a good commercial or pd program is even
more important.
2) limit the publicity given the viruses to the absolute minimum
of identifying viruses and the protection programs.
I think that any other discussion of viruses, including asking the net
which BBS has which version of which virus killers (which can be
done via mail, in person, or at user groups), and including postings
like mine and Don's, are counter productive.
Read up on viruses: you can't protect against them using any means
you would like to live with. The best thing to do is to help this
fad pass.
) Don White
jimm
--
Jim Mackraz, I and I Computing
amiga!jimm BIX:jmackraz
Opinions are my own. Comments regarding the Amiga operating system, and
all others, are not to be taken as Commodore official policy.Dan-Hankins@cup.portal.com (09/14/88)
1. CRCs can be spoofed fairly easily by anyone who knows the math. A disassembly of the boot block will reveal the algorithm to the virus writer rather quickly. 2. If I were a virus writer, I wouldn't even bother to spoof the CRC. I'd just write my virus to patch out the CRC checking code so that it never raises an alarm. 3. Self-validating programs are in general not a promising approach to stopping viruses. The virus just alters the checking code so that it fails to notice the virus. Remember: Once a self-protecting program is released, the virus writer can easily study it and defeat it. Dan Hankins "These opinions are mine and mine alone. They are not for sale. They may, however, be rented or leased at reasonable rates."
tope@enea.se (Tommy Petersson) (09/14/88)
In article <681@zehntel.UUCP> donw@zehntel (Don White) writes:
-[simple mind, simple idea. It's not just a good idea. It's the way i am.]
-
- Do you supose it would be difficult for Commodore to put a little CRC
- check in their Kickstart and Workbench Boot blocks to INSURE that no
- virus had been installed? Any time you do boot, a message could come
- up saying "Kickstart HAS BEEN TAMPERED WITH!!!" and/or "Workbench HAS BEEN
- TAMPERED WITH!!!" if such is the case.
-
- Is there any reason that this virus baloney has to drag on and on?
-
- Don White
- zehntel!donw
- {ihnp4 | akgua | seismo | tektronix}!zehntel!donw
- Box 271177 Concord, CA. 94527-1177
-
I saw a magazine ad in a german 'zine, maybe Kickstart, where they
sold a custom kickstart rom with some virus checking added. I don't
know if it is any good, or legal, but it seems to be possible to
do something anyway...bell@unc.cs.unc.edu (Andrew Bell) (09/15/88)
In response to idea of checksummed boot block idea you saw a few messages
ago...
The "checksum" could be made a rather intricate calculation, and thus hard to
match. However, since Commodore may want to change the boot block, and there
are various custom boot blocks, this really isn't such a great idea.
However, an idea that might at least make virus writing more difficult would
be creating custom boot blocks that do interesting things. Perhaps a bunch of
Robotron robots performing anti-marketroid maneuvers...
Just think: disciple-to-be:"Hey what are those robots doing?"
You:"Why, they're ensuring my system is virus-free."
DTB:"Wow, I didn't know Amigas could do that..."
That way, when you boot up and you see that display, you're more sure of
being virus-free. If there were a number of these around, with hooks to ensure
their code is on the boot block, it might be impossible to write a small
enough virus to move and change every publicly available boot block.
Comments, anyone?
Ideas, Leo? :-)
Copyright 1988 by Andrew Bell
The Schizophrenic Grad Student (and Amiga developer)
bell@cs.unc.edu
acb@cs.duke.edurokicki@polya.Stanford.EDU (Tomas G. Rokicki) (09/15/88)
In article <4197@thorin.cs.unc.edu>, bell@unc.cs.unc.edu (Andrew Bell) writes: > The "checksum" could be made a rather intricate calculation, Most `more complicated' boot block checksums could easily be reverse-engineered. No, you'd want to allocate 128 bits to the `check' field, at least, and use RSA public-key magic to make it impossible for anyone but Commodore to make a boot block. (Commodore would supply check fields for commercial boot blocks via the commercial developers program.) Even this wouldn't be sufficient, though, because a virus could hitch a ride off someone's boot block that read and executed code directly off the disk, or some such. Folks, there is no point to challenging the virus writers, as Jimm says. Best to ignore the problem. But the RSA idea would be kind of neat. -tom
mills@phao.eng.ohio-state.edu (Christopher Mills) (09/15/88)
In article <4197@thorin.cs.unc.edu> bell@unc.UUCP (Andrew Bell) writes: > >However, an idea that might at least make virus writing more difficult would >be creating custom boot blocks that do interesting things. Perhaps a bunch of >Robotron robots performing anti-marketroid maneuvers... > Arrgh! No! Not a robotroff virus! No! Please! No! It's a neat hack, but I hate to have the little buggers running around on my screen when I don't want them there... Eek! I'd rather have a virus (almost)... -=- _________________________________________________________________________ | Christopher Mills | "If you see someone without a smile, | | mills@baloo.eng.ohio-state.edu | give them mine - I'm not using it." | ====== My thoughts are not my own--I'm posessed by mailer daemons. ======
bell@unc.cs.unc.edu (Andrew Bell) (09/15/88)
In article <599@accelerator.eng.ohio-state.edu> mills@phao.eng.ohio-state.edu (Christopher Mills) writes: >In article <4197@thorin.cs.unc.edu> bell@unc.UUCP (Andrew Bell) writes: >> >>However, an idea that might at least make virus writing more difficult would >>be creating custom boot blocks that do interesting things. Perhaps a bunch of >>Robotron robots performing anti-marketroid maneuvers... >> > > Arrgh! No! Not a robotroff virus! No! Please! No! >| Christopher Mills | "If you see someone without a smile, | Aw, "Smile, darn ya, smile..." -_Who Framed Roger Rabbit_? Just to make sure my point got across: no, the robots program should NOT be a virus. It should be incapable of replicating itself (instead, some variant of the install program should exist.) Then, if you start up your amiga and the screen hack fails to appear, something has changed the boot block. It might be possible for a virus to move the screen hack out of the boot block and run it after it has completed its dirty work, but hooks that make the screen hack check if a copy of it is still in the boot block should make virii too small to do all the necessary work. A trojan horse might be capable of such damage, but it too would have to be sizeable and complex. Can anybody think why this wouldn't work? The only possibility I can think of being a problem is people distibuting virii while claiming they're boot block protectors, or distributing boot block hack installers that are Trojan Horses... -Andrew Bell The Schizophrenic Grad Student bell@cs.unc.edu acb@cs.duke.edu
lishka@uwslh.UUCP (Fish-Guts) (09/15/88)
In article <599@accelerator.eng.ohio-state.edu> mills@phao.eng.ohio-state.edu (Christopher Mills) writes: >In article <4197@thorin.cs.unc.edu> bell@unc.UUCP (Andrew Bell) writes: >> >>However, an idea that might at least make virus writing more difficult would >>be creating custom boot blocks that do interesting things. Perhaps a bunch of >>Robotron robots performing anti-marketroid maneuvers... >> > > Arrgh! No! Not a robotroff virus! No! Please! No! No no no no no.... You missed his point, which I thought went something like "stick some hard to reproduce animation code, encoded in some fashion, in the boot block. When the machine starts up, the cute animation code would run to tell you everything was fine." At least that is how I interpreted it. The problem is this cute animation code could be duplicated. Let's face it...viruses will always be around. The only thing to do is ignore the viruses and their creators. There is no miracle cure. >| Christopher Mills | "If you see someone without a smile, | >| mills@baloo.eng.ohio-state.edu | give them mine - I'm not using it." | >====== My thoughts are not my own--I'm posessed by mailer daemons. ====== -- Christopher Lishka ...!{rutgers|ucbvax|...}!uwvax!uwslh!lishka Wisconsin State Lab of Hygiene lishka%uwslh.uucp@cs.wisc.edu Immunology Section (608)262-1617 lishka@uwslh.uucp ---- "...Just because someone is shy and gets straight A's does not mean they won't put wads of gum in your arm pits." - Lynda Barry, "Ernie Pook's Commeek: Gum of Mystery"
dave@onfcanim.UUCP (Dave Martindale) (09/16/88)
In article <2881@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: > >Read up on viruses: you can't protect against them using any means >you would like to live with. The best thing to do is to help this >fad pass. How about hardware memory protection? It actually helps you debug code, and may allow "virtual memory", but as a side effect it can absolutely prevent viruses that install themselves in the operating system somewhere. Or is this still too radical an idea for a "personal computer"?
rminnich@super.ORG (Ronald G Minnich) (09/17/88)
In article <16144@onfcanim.UUCP> dave@onfcanim.UUCP (Dave Martindale) writes: >How about hardware memory protection? It actually helps you debug > >Or is this still too radical an idea for a "personal computer"? Round and round we go. No, you are wrong, it only helps a little, and not that much. We will have to put this in the 'standard usenet posting', i guess, as it comes up about every two weeks. sigh. ron
jimm@amiga.UUCP (Jim Mackraz) (09/17/88)
In article <16144@onfcanim.UUCP> dave@onfcanim.UUCP (Dave Martindale) writes: )In article <2881@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: )> )>Read up on viruses: you can't protect against them using any means )>you would like to live with. The best thing to do is to help this )>fad pass. ) )How about hardware memory protection? It actually helps you debug )code, and may allow "virtual memory", but as a side effect it can )absolutely prevent viruses that install themselves in the operating )system somewhere. Maybe we should add that to V1.4. I'm sure there are no viruses in the history of, say, un*x. People use files for viruses on most systems that I've read about. I think they do that on un*x just fine. )Or is this still too radical an idea for a "personal computer"? A little pricey, to be assumed for the base model of a family. jimm -- Jim Mackraz, I and I Computing amiga!jimm BIX:jmackraz Opinions are my own. Comments regarding the Amiga operating system, and all others, are not to be taken as Commodore official policy.
bell@unc.cs.unc.edu (Andrew Bell) (09/17/88)
In article <378@uwslh.UUCP> lishka@uwslh.UUCP (Fish-Guts) writes: >In article <599@accelerator.eng.ohio-state.edu> mills@phao.eng.ohio-state.edu (Christopher Mills) writes: >>In article <4197@thorin.cs.unc.edu> bell@unc.UUCP (Andrew Bell) writes: >>>[Regarding my idea of creating animated boot block code...] >>[Mr. Mills's comments] > No no no no no.... You missed his point, which I thought went >something like "stick some hard to reproduce animation code, encoded >in some fashion, in the boot block. When the machine starts up, the >cute animation code would run to tell you everything was fine." At >least that is how I interpreted it. > The problem is this cute animation code could be duplicated. >Let's face it...viruses will always be around. The only thing to do >is ignore the viruses and their creators. There is no miracle cure. If the code is large enough, the boot block can be filled, and thus there is no room for a virus as well as the nifty animation/music/whatever. Also, if there are dozens of different boot blocks around, virii could only propogate to disks containing one type of boot block without being spotted. It might be possible for virii to move the nifty code out of the boot block and execute it after it's done its dirty work, but a virus that can do all that's necessary should be hard to fit in 1k, especially if the boot block codes check to see if they are in the boot block. A potential problem would be that virus authors could advertize virii as boot block codes, and infect people by what they thought were vaccines... People could also create non-viruses that make one more susceptible to virii, by being small enough (or rewritable as smaller) so that real viruses can pose as this non-virus and have plenty of room for the rest of their dirty work. Sort of the AIDS of the computer world, making one more susceptible to infection... Another thing you could do with boot block codes is create one that switches booting to your hard disk; put this on every disk and you don't need to take them out to warm reset, and you don't perceptibly use up space on the disk. -Andrew Bell The Schizophrenic Grad Student bell@cs.unc.edu acb@cs.duke.edu
ain@s.cc.purdue.edu (Patrick White) (09/19/88)
In article <4241@thorin.cs.unc.edu> you write: >It might be possible for virii to move the nifty code out of the boot block >and execute it after it's done its dirty work, but a virus that can do all Why bother.. the virus can keep part of iteslf on the disk so it can be larger.. then it has all the room to emulate anything it wants to... But, the best solution (and only real one?) is to hack a version of kickstart so the bootblock never gets executed -- and have a normal one around for use with games and such with custom bootblocks.. presto, no more spreading of infections.. of course all you poor people with 500 and 2000s who traded boot-up time for flexibility loose, but then that was your decision, not mine. Pat White (ain@s.cc.purdue.edu)
limonce@pilot.njin.net (Tom Limoncelli) (09/19/88)
Ummm... with all this talk about protecting the boot-block (which can
be circumvented) doesn't anyone realize that someone could write a
virus that infects DIR or SERIAL.DEVICE or LIST or ASSIGN or ECHO?
Strong CRCs and memory protection can only go so far. I'm surprised
that in "Inside OS/2" (a very good book... but I like any author that
writes like Thomas Paine) the author claims virii will have a very
difficult time gaining access to a way to install themselves. What
about modifying FORMAT, DISKCOPY, or CHKDSK (or the Amiga's
validator)? How many users do you know have the protection bits set
on those programs so that nobody can modify them (or their protection
bits)?
IMHO, the best thing would be education. We have to teach people that
virii writing is not funny.
Tom
--
Tom Limoncelli -- Drew University, Box 1060, Madison, NJ 07940
TLimonce@Drew.Bitnet -- limonce@pilot.njin.net -- VoiceMail (201)408-5389
Drew College of Liberal Arts: male/female ratio: 2:3 student/pc ratio: 1:1
"The opinions expressed are mine... just mine."bell@unc.cs.unc.edu (Andrew Bell) (09/20/88)
In article <3568@s.cc.purdue.edu> ain@s.cc.purdue.edu (Patrick White) writes: >In article <4241@thorin.cs.unc.edu> I wrote: >>It might be possible for virii to move the nifty code out of the boot block >>and execute it after it's done its dirty work, but a virus that can do all > > Why bother.. the virus can keep part of iteslf on the disk so it can be >larger.. then it has all the room to emulate anything it wants to... Have the boot block program check where it's running in memory. On a cold boot it should be in the same location unless you get new hardware or there is a hardware problem. Presumably a virus that copied the boot block code elsewhere would have to do a good bit of work to set things up again so the boot block code ran from the same point in memory. If the boot block code did a complex checksum on all the stuff beneath it, it could be very hard to fool the bbc into thinking it's running on a virus free environment. If there are multiple bbc's out there, it would be hard for a virus to determine which one is on a given disk and modify it so it doesn't check its location. Note that this requires have your boot disk un-write-protected since it must save any changes in start-up point, but only each time something actually changes. These bbc's aren't a change in the operating system; they could be neat little things that are useful regardless of the existence of viruses. >Pat White (ain@s.cc.purdue.edu) -Andrew Bell The Schizophrenic Grad Student bell@cs.unc.edu
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/20/88)
:
:The "checksum" could be made a rather intricate calculation, and thus hard to
:match. However, since Commodore may want to change the boot block, and there
:are various custom boot blocks, this really isn't such a great idea.
(1) It won't work, period. Throughout time industry has
underestimated the 'bad' hacker (distinction: good and bad).
It only takes one, and although such people usually do not
have college degrees and couldn't care less about high level
theory, they *can* trace code and break just about anything
it existance, ESPECIALLY if it is in the OS.
(2) It won't work, hackers are usually smarter than the OS designers
when it comes to code breaking, especially considering the
checksum code is readily disassemblable. In fact, many companies
these days are highering hackers to fight hackers... but it
doesn't help. It's easier to break than build.
(3) Many games use custom boot blocks
(4) Only A1000's have kickstart on disk and that is not likely
to get screwed up (i.e. write protect the disk).
(5) Many handlers exist which are not virus's.. For example, the
new ram disk in 1.3 not only survives reboot, but allows you
to boot out of ram.
The solution is simple. Don't write Virus's. Don't even write anti-virus
virus's. Write Virus detectors. Here on the USENET it isn't as big a problem
than on other nets or BBSs because it is possible to trace the originator.
Even if it comes from a guest account one can simply remove the entire computer
from the graph until their sysop does something about it. This could be made
into an argument in favor of moderators testing code before posting it,
but frankly, if it doubles the turn-around time I will take my chances.
-Mattdan-hankins@cup.portal.com (09/21/88)
In article "Re: The Ultimate fix!!!" of 9/19/88 15:45 bell@unc.cs.unc.edu (Andrew Bell) writes: >Have the boot block program check where it's running in memory. On a cold ... >Presumably a virus that copied the boot block code >elsewhere would have to do a good bit of work to set things up again so the >boot block code ran from the same point in memory. If the boot block code >did a complex checksum on all the stuff beneath it, it could be very hard to >fool the bbc into thinking it's running on a virus free environment. >If there are multiple bbc's out there, it would be hard for a virus to >determine which one is on a given disk and modify it so it doesn't check >its location. So when a new boot block comes out, the virus writer simply writes a new version of his virus that checks for the new code, the same way that Marauder comes out with a new Brain File that checks for more copy protections. The virus program doesn't have to have a copy of a boot block in order to recognize it; a four or eight byte CRC will do the job admirably. Besides, an infection that only hits one out of eight machines is still destructive. It will still spread. Dan Hankins
bell@unc.cs.unc.edu (Andrew Bell) (09/22/88)
In article <9318@cup.portal.com> dan-hankins@cup.portal.com writes: > > In article "Re: The Ultimate fix!!!" of 9/19/88 15:45 bell@unc.cs.unc.edu >(Andrew Bell) writes: >>If there are multiple bbc's out there, it would be hard for a virus to >>determine which one is on a given disk and modify it so it doesn't check >>its location. > So when a new boot block comes out, the virus writer simply writes a new >version of his virus that checks for the new code, the same way that Marauder >comes out with a new Brain File that checks for more copy protections. The >virus program doesn't have to have a copy of a boot block in order to >recognize it; a four or eight byte CRC will do the job admirably. It can recognize it, but how much code will it take to change it? If there are *multiple* bbcs around, the virus will have to account for many of them to spread reliably, and differently ordered (object file) versions of the same boot block code will need to be treated differently. How quickly can that virus author get his "brain files" out there, anyway? People have enough trouble getting upgrades to programs they *want*... [I realise that the virus can link to code outside the boot block, so the 1k limit for the initial virus code isn't that big a limiting factor, it's just more work for the virus author...] And if dozens of boot blocks aren't enough, how about an infinite number? There would have to be some sort of boot block writer program. Allow the user to add his/her own name (or a name for their Amiga) in the code, and perhaps a random seed to move data and code areas around (kinda tricky, I realize). You could then have a little program on your most commonly booted-with (but write-protected) disk that checks each newly inserted disk for the presence of your or your Amiga's name in the boot block, and lets you know if it's not a custom boot block. Then when you forget to wear your write-protect tab, your "partners" are less likely to infect you... What is in the boot block normally, anyway? > Besides, an infection that only hits one out of eight machines is still >destructive. It will still spread. A lot slower, though. It gives the anti-virus writers more of a chance to catch up. With people's conciousness level raised about viruses, it should nip the virus in the bud. And if seven people out of eight a virus author tries to infect can catch him/her in the act, I suspect he'd/she'd be rather reticent about creating one. >Dan Hankins -Andrew Bell The Schizophrenic Grad Student bell@cs.unc.edu acb@cs.duke.edu
bjc@pollux.UUCP (Betty J. Clay) (09/22/88)
In article <Sep.18.18.41.56.1988.24600@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: > >IMHO, the best thing would be education. We have to teach people that >virii writing is not funny. > There was a trial in Fort Worth this week in which a man was accused of There was a trial in Fort Worth this week in which a man was accused of planting a virus in the computer of his employer (just before he was fired). He was found guilty, under a new law passed by the last Texas legislature. Sentencing has been delayed until October, but can include a jail sentence as well as a rather hefty fine. How is THAT for educating people about writing virii? >Tom >-- Betty Clay ..........killer!pollux!bjc
donw@zehntel (Don White) (09/24/88)
[So far... ]
So far, I have gotten about half a dozen replies telling me that my sanity
is questionable for suggesting that the virus problem can be stopped. And yet,
there HAS been some useful dialog.
Here is an updated suggestion which I DARE you to find flawed. 1/2 ;-)
If kickstart (both ROM and Disk) were distributed with a WORKBENCH checker
you would be told automatically when your disk was not standard. If you have
attempted to load a copy-protected program then you will simply accept that
it is non-standard. And documentation should warn you that you are subject to
having other disks harassed. There is NO WAY TO GET PAST THIS WARNING because
it is in ROM or a write-protected kickstart. (System Master disks should be
distributed with NO WRITE PROTECT TABS!!! I.E ALWAYS PROTECTED!!!)
This method would incur some cost. Any time Workbench changed, KickStart
would have to be redistributed. But there would always be dependable warning
when you first stuck a virused disk in your system. It would be READ before
it was RUN. This insures that no bad code is executed!!
Come on now! Wouldn't this work?
Don White
{ihnp4 | akgua | seismo}!zehntel!donw
Box 271177 Concord, CA. 94527-1177
P.S. Brian , I've tried to mail to you four times. No success. (Although,
curiously, you CAN get mail through to me.) I guess I will just have to post
the Lattice-ized Boing! to comp.sources.amiga. Oh well.dan-hankins@cup.portal.com (09/24/88)
In article <4320@thorin.cs.unc.edu> bell@unc.cs.unc.edu (Andrew Bell) writes: >It can recognize it, but how much code will it take to change it? If there >are *multiple* bbcs around, the virus will have to account for many of them ... Okay, let's assume you've made it impractical for a virus writer to put his virus in the boot block. This is no deterrent. Any executable file is a potential virus carrier. One such IBM PC virus, called the Jerusalem Virus or JV after the location of its discovery, did just this. The JV would be tacked onto the beginning of an executable file. Whenever someone would run the file, JV would execute first and install itself in one of the system interrupt vectors. From then on, whenever someone would run a program on the infected machine, JV would get control at the system call to load the program, and would modify that file on disk to contain itself, if it could. On a particular Friday the 13th of this year, it would erase all magnetic media on the machine. On all other Friday the 13ths, it would degrade system performance. It was only caught because (a) it always made the executable 1800 bytes bigger, and (b) it didn't check to see if the file it was infecting was already infected. Therefore a frequently run utility would eventually grow too large to be loaded into memory, or the user would run out of disk space for no apparent reason. There are easy ways to avoid (a) and (b). Even with those giveaways, it managed to trash a lot of systems. And it never touched the boot block. Dan Hankins
jms@antares.UUCP (joe smith) (09/25/88)
One of the assumptions that the original poster of this article is using is the idea that if a given block has the right checksum, then it has not been corrupted. This is not true. If two blocks have different checksums, then they are guarenteed to be different. But two blocks having the same checksum does NOT mean that they are identical. A 512 byte block has 4096 bits; there are 2**4096 different combinations possible. But reducing all that data down to 32 or so bits allows many different blocks to result in the same checksum. For a given checksum, it is possible to create N different blocks with that checksum. For D data bits and C checksum bits, N is on the order of 2**(D-C). (Granted, not bogus blocks result in executable code.) In summary; while checksums are good insurance against random corruption of bits in a block, they are not infallible against deliberate corruption. A mechanism that uses only checksums can be fooled by a determined hacker. This is true regardless of which checkum algorithm is used, as long as the checksum has significantly fewer bits than the block it is protecting. -- +----------------------------------------------------------------------------+ | TYMNET:JMS@F29 CA:"POPJ P," UUCP:{ames|pyramid}oliveb!tymix!antares!jms | | INTERNET:JMS%F29.Tymnet@Office-1.ARPA PHONE:Joe Smith @ (408)922-6220 | +----------------------------------------------------------------------------+
lishka@uwslh.UUCP (Fish-Guts) (09/26/88)
In article <693@zehntel.UUCP> donw@zehntel (Don White) writes: >[So far... ] [ ... ] > Here is an updated suggestion which I DARE you to find flawed. 1/2 ;-) > > If kickstart (both ROM and Disk) were distributed with a WORKBENCH checker > you would be told automatically when your disk was not standard. If you have > attempted to load a copy-protected program then you will simply accept that > it is non-standard. And documentation should warn you that you are subject to > having other disks harassed. There is NO WAY TO GET PAST THIS WARNING because > it is in ROM or a write-protected kickstart. (System Master disks should be > distributed with NO WRITE PROTECT TABS!!! I.E ALWAYS PROTECTED!!!) > > This method would incur some cost. Any time Workbench changed, KickStart > would have to be redistributed. But there would always be dependable warning > when you first stuck a virused disk in your system. It would be READ before > it was RUN. This insures that no bad code is executed!! > > Come on now! Wouldn't this work? Yeah, this sounds like it would work. However, the only way to make *certain* one had the right boot block is to keep an *exact* copy in the ROMs. Any less information is liable to be broken; note that this is the major problem with checksums. One problem is what to do with non-standard (i.e. custom) boot-blocks. Should a requester be posted when one is found? I find that annoying because then I have to hit a mouse button every time I want to boot a commercial game. For that manner, any intrusive warning will be annoying. This probably would not be as effective as you think. My reasoning: the workbench should always check out; however, non-standard boot blocks would not. So when people booted with a disk containing a non-standard boot-block, a message would appear (like "this is a non-standard boot block: use it at your own risk!"). Given that there are a lot of games and other programs with non-standard boot blocks, people would soon ignore the warning for anything but a bootable workbench disk. So what do you have? Some more precious ROM memory used for checking only Workbench disks. This is probably better done with one of the current virus checking programs. For example: write your own program that has an exact copy of the Workbench boot-block embedded in it. Put it first in your startup-sequence. There will be a small bit of overhead for comparing the two, but not too bad. The only time that the program needs to be changed is when another release of the Workbench comes out, which is not all that frequent anyhow (there have only been three or four released to the public so far, in about that many years). The Kickstart check would work, but it consumes precious ROM space and penalizes those who do usually get viruses (I have never had problems with them myself). Furthermore, it would only solve part of the problem of viruses that reside in the boot block. There will probably be other forms of viri (or is it virii, or is it viruses?) in the future that do not use the boot block as their residence. By far the best solution has already been mentioned by a wise net-person: *IGNORE* the virus writers; i.e. do not give them any free publicity (like these messages are), do not keep posing solutions to them over the net, do not flatter them in any way (including calling them names and such). I have a feeling that if these virus-writing dudes do not get any form of acknowledgement, they will begin producing more interesting and visible software, like useful PD programs, because they will be noticed more. The other solution is practice "safe [disk] sex!" Think of those write-protect tabs as disk-condoms, and USE them as protection. Backup your stuff more. Never trust a PD disk until its boot-block has been examined, and be wary of PD programs. > Don White > {ihnp4 | akgua | seismo}!zehntel!donw .oO Chris Oo. -- Christopher Lishka ...!{rutgers|ucbvax|...}!uwvax!uwslh!lishka Wisconsin State Lab of Hygiene lishka%uwslh.uucp@cs.wisc.edu Immunology Section (608)262-1617 lishka@uwslh.uucp ---- "...Just because someone is shy and gets straight A's does not mean they won't put wads of gum in your arm pits." - Lynda Barry, "Ernie Pook's Commeek: Gum of Mystery"
bell@unc.cs.unc.edu (Andrew Bell) (09/26/88)
In article <9381@cup.portal.com> dan-hankins@cup.portal.com writes: >In article <4320@thorin.cs.unc.edu> bell@unc.cs.unc.edu (Andrew Bell) writes: > >>It can recognize it, but how much code will it take to change it? If there >>are *multiple* bbcs around, the virus will have to account for many of them >... > >Okay, let's assume you've made it impractical for a virus writer to put his >virus in the boot block. This is no deterrent. Any executable file is a >potential virus carrier. One such IBM PC virus, called the Jerusalem Virus >or JV after the location of its discovery, did just this. [Then he talks about how this Trojan Horse works] >Dan Hankins 'Taint a virus, that's a Trojan Horse. And VirusX etc. can't do anything about that sort of thing either, unless I'm entirely mistaken. I'd be surprised if anything could; novices tend not to write-protect disks, and more experienced folks can't write-protect their hard disk. Putting the system on the hard disk means that the program can discreetly add its code to programs on the hard disk, without the strange accessing being a giveaway. You really want your system code on a write-protectable medium if you want hardware virus/Trojan Horse protection, and even that only keeps your system uncorrupted. (Actually, you might call such the Jerusalem Virus a virus, as they obviously did, but it is transmitted via Trojan Horse techniques.) The only possible way I can think of to defend against these sorts of malicious software is to monitor the various system pointers, and have it pointed out when a device driver has been modified. If the various anti- virus programs do that then I apologize for my misstatement at the top; if they don't they might consider doing it. -Andrew Bell The Schizophrenic Grad Student bell@cs.unc.edu acb@cs.duke.edu
BEB%UNO.BITNET@cunyvm.cuny.edu (09/27/88)
Don White <donw@zehntel> writes: > If kickstart (both ROM and Disk) were distributed with a WORKBENCH checker > you would be told automatically when your disk was not standard. If you have And how do we do the checking? Checksums? Once known (same day they hit the street if not before) they can be matched by a trojan virus. Comparison with code in ROM? No room in current ROMs, is there? Code not in ROM? Unsecure. > attempted to load a copy-protected program then you will simply accept that > it is non-standard. And documentation should warn you that you are subject to > having other disks harassed. There is NO WAY TO GET PAST THIS WARNING because > it is in ROM or a write-protected kickstart. (System Master disks should be > distributed with NO WRITE PROTECT TABS!!! I.E ALWAYS PROTECTED!!!) Nobody in his right mind ever boots off the original master more than once. (I think I did it twice. :} > This method would incur some cost. Any time Workbench changed, KickStart > would have to be redistributed. So C= would be very unwilling to do it, even if it would help, and I for one would be unwilling to pay extra for such a limited gain in "security". > But there would always be dependable warning > when you first stuck a virused disk in your system. It would be READ before > it was RUN. This insures that no bad code is executed!! Any code not in ROM is fair game for a trojan horse. You can't put it all in ROM without *major* hardware redesign. At most you can get a clean boot, but from the end of the boot on anything is vulnerable. > Come on now! Wouldn't this work? This only addresses the bootblock type of virus. How do you defend against a virus that spreads by attaching itself to random load files (for instance)? Or how about a "dir" that copies itself to a writeable disk that contains a :c/dir. This is the vector. Pick any sort of crazy badness you could imagine for the disease. When you've figured out how to defeat that, I'll suggest another method of mangling your system. See? It's a no-win game. No point in even trying to defend against it. Talking about viruses and trojan horses just encourages the pinheads that write them. The best defense is a suspicious nature. > Don White > {ihnp4 | akgua | seismo}!zehntel!donw > Box 271177 Concord, CA. 94527-1177 Bruce death before disclaimer <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> <>Handle: Bruce Bettis USnail: University of New Orleans <> <>BITnet: <BEB@UNO.BITNET> Computer Research Center <> <>Voices: (504) 286-7067 New Orleans, La. 70148 <> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
dan-hankins@cup.portal.com (09/27/88)
> I dare you to find a flaw
...
If the virus is not in the boot block, a boot block checker won't find
it. Period. End of story.
Dan Hankinsdan-hankins@cup.portal.com (09/27/88)
Don White writes: >Backup your stuff more. Never trust a PD disk until its boot-block >has been examined, and be wary of PD programs. And be wary of commercial programs also. Plastic shrink-wrappers and corporate charters are not magic talismans against viral infection. Dan Hankins
donw@zehntel (Don White) (09/28/88)
[The egg dammit!! The egg came first!!]
I appreciate everybodys input! We have so many sharp people on
the net that I thought we could come up with a solution to virus writers.
I know that most of the inventions that we use today were invented despite
expert testimony which said that such things could not work.
We can't currently guard against every devious scheme, but I am curious
if there is any worth in trying to guard the system from the simpler
viruses. Doctors innoculate us against the basics.
And, I am hoping that if we at least think about the problems we have, we
might someday solve them. I don't know if it will require a self-aware
operating system, or just a new file system format, but I REFUSE to
ASSUME that there is no possible solution. There MAY, in fact, be no
solution. But I think we should keep looking.
I think educating the virus writers is a meaningless phrase. They
are clearly having too much sick fun too stop. So, the only thing we
can really do is try to educate US. (Meaning all users).
Nuff said. Thanks for your ideas and criticisms.
PS. Matt Dillon, OK, you got me. I didn't know CRCs were that easy to duplicate.Someone mentioned this since you sent me your last message. Ignore my return
mail. :-)
Don White
zehntel!donw
Box 271177 Concord, CA. 94527-1177
peter@sugar.uu.net (Peter da Silva) (09/28/88)
In article <4374@thorin.cs.unc.edu>, bell@unc.cs.unc.edu (Andrew Bell) writes: > 'Taint a virus, that's a Trojan Horse. Nope, it's a virus. A trojan horse is a technique which you can use to get a virus into another computer, and it's the way most viruses... including the Amiga bootblock viruses... work. A virus is any program that hides in a computer system and replicates itself. > You really want your system code on a write-protectable medium if you want > hardware virus/Trojan Horse protection, and even that only keeps your system > uncorrupted. Or run a protected operating system like UNIX, where a virus has a *much* harder time of it. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
andy@cbmvax.UUCP (Andy Finkel) (09/29/88)
In article <2689@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >In article <4374@thorin.cs.unc.edu>, bell@unc.cs.unc.edu (Andrew Bell) writes: >> 'Taint a virus, that's a Trojan Horse. > >Nope, it's a virus. A trojan horse is a technique which you can use to Actually, its more like a time bomb, or a worm. It wasn't a replicating program from the reports I got; just a program that needed to be reset every once in awhile or else it started up, and did bad things to the file system. >Or run a protected operating system like UNIX, where a virus has a *much* harder >time of it. Since the bug was introduced by one of their programmers, being protected wouldn't have helped much. -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "If we can't fix it, it ain't broke." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
dan-hankins@cup.portal.com (09/29/88)
In article <2689@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >Nope, it's a virus. Yep, it's a virus. >A trojan horse is a technique which you can use to get a virus into another >computer, and it's the way most viruses... including the Amiga bootblock >viruses... work. Sort of. I believe that the classic definition of a Trojan Horse is: A program that appears useful but which has been deliberately and directly modified to contain code unrelated to the program's overt function. This unrelated code may be directly harmful (erase your hard disk), indirectly harmful (release a virus), or innocuous (display a bouncing ball on your screen once per hour). >A virus is any program that hides in a computer system and replicates itself. Close. The first published definition of a computer virus is attributed to Dr. Fred Cohen, who experimented with a non-harmful virus on one of his university's computer systems. Being first, his definition should really be considered the most valid. It certainly holds the closest to the biological analogy: A computer virus is a piece of code that hides by attaching itself to other pieces of code, self-replicates by usurping the function of the host code, and may or may not inflict damage to the host systems. It may or may not have an incubation period, and a specific host trigger. The biological analogy holds up well: 'other pieces of code' are the programs and operating system of the machine, and correspond to cells in a body. Attaching is roughly equivalent to invading a cell. Replication by usurpation (is that a word?) is equivalent to the way a virus replaces the DNA of the target cell with its own. Incubation and triggers have obvious analogies with biological viruses. >Or run a protected operating system like UNIX, where a virus has a *much* harder >time of it. Not really. Fred Cohen's virus experiment was performed on a protected multiuser operating system. The longest it took a virus to attain system priviledges was an half an hour, the shortest five minutes, with an average of about fifteen, *even when the users knew a virus was around*. Dan Hankins
peter@sugar.uu.net (Peter da Silva) (09/29/88)
In article <4861@cbmvax.UUCP>, andy@cbmvax.UUCP (Andy Finkel) writes: > Actually, its more like a time bomb, or a worm. It wasn't a replicating > program from the reports I got; just a program that needed to > be reset every once in awhile or else it started up, and did bad > things to the file system. We must be talking about different programs. I thought we were talking about the one that tagged itself onto the beginning of any executable file in your machine, and was caught when executables started growing. What *were* you talking about? -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
mkr@kestrel.Philips.Com (Michael K. Reed) (09/30/88)
In article <2689@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) dreams: > >Or run a protected operating system like UNIX, where a virus has a *much* harder ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >time of it. >-- > Peter da Silva `-_-' peter@sugar.uu.net What is this, some kind of SICK JOKE??? Unix is well known as one of the premier systems to hack, second only to TWENEX (TOPS-20) for the award of "Most Abusable Operating System". (my opinion). There are, of course, special Secure UNIX versions, but straight UNIX is probably "login system of choice" for infiltrators... Michael ________________________________________________________________ | Michael Reed !allegra---- | | mkr@philabs.philips.com \ | | AI Department !steinmetz--->---!philabs!mkr | | Philips Laboratories / | | (914) 945-6069 !rutgers---- | +----------------------------------------------------------------+
andy@cbmvax.UUCP (Andy Finkel) (09/30/88)
In article <2706@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >We must be talking about different programs. I thought we were talking about >the one that tagged itself onto the beginning of any executable file in your >machine, and was caught when executables started growing. > >What *were* you talking about? Maybe I responded to the wrong thread ... I was responding to the comment about the program that Time magazine called a virus last week. -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "People who post news as root probably have other bad habits, too." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
papa@pollux.usc.edu (Marco Papa) (10/01/88)
In article <9548@cup.portal.com| dan-hankins@cup.portal.com writes: |In article <2689@sugar.uu.net| peter@sugar.uu.net (Peter da Silva) writes: |Close. The first published definition of a computer virus is attributed to |Dr. Fred Cohen, who experimented with a non-harmful virus on one of his |university's computer systems. Yep, USC's Computer Science Dept. VAX-780, a.k.a. usc-cse. | Being first, his definition should really |be considered the most valid. It certainly holds the closest to the |biological analogy: | | A computer virus is a piece of code that hides by attaching itself to | other pieces of code, self-replicates by usurping the function of the | host code, and may or may not inflict damage to the host systems. It | may or may not have an incubation period, and a specific host trigger. | |The biological analogy holds up well: 'other pieces of code' are the |programs and operating system of the machine, and correspond to cells in a |body. Attaching is roughly equivalent to invading a cell. Replication |by usurpation (is that a word?) is equivalent to the way a virus replaces |the DNA of the target cell with its own. Incubation and triggers have |obvious analogies with biological viruses. | ||Or run a protected operating system like UNIX, where a virus has a *much* harder ^^^^ ||time of it. | |Not really. Fred Cohen's virus experiment was performed on a protected |multiuser operating system. The longest it took a virus to attain system |priviledges was an half an hour, the shortest five minutes, with an average |of about fifteen, *even when the users knew a virus was around*. The VAX-780 that Fred used was running UNIX 4.2bsd. All of Dan's quotes are perfectly accurate. To add some info, after the "controlled ex[periment", Fred tried to obtain permission to try it out on other systems (in the instance, a DEC running TOPS-20). The local university "authorities" refused. -- Marco Papa 'Doc' [willing participant in Fred's controlled experiment] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
peter@sugar.uu.net (Peter da Silva) (10/02/88)
In article <9548@cup.portal.com>, dan-hankins@cup.portal.com writes: > >A virus is any program that hides in a computer system and replicates itself. > A computer virus is a piece of code that hides by attaching itself to > other pieces of code, self-replicates by usurping the function of the > host code, and may or may not inflict damage to the host systems. It > may or may not have an incubation period, and a specific host trigger. I think you need to add "and has the ability to infect other systems it comes in contact with". > >Or run a protected operating system like UNIX, where a virus has a *much* harder > >time of it. > Not really. Fred Cohen's virus experiment was performed on a protected > multiuser operating system. The longest it took a virus to attain system > priviledges was an half an hour, the shortest five minutes, with an average > of about fifteen, *even when the users knew a virus was around*. (1) On a non-protected system it would take *0* time to infect the system. I think the best thing to do would be to have the virus hide itself in a public bin directory with a a name that's a common typo of one of the standard commands. Then it prints the usual error message and starts seeing what new privileges it has. This will go on until root executes it. In a well managed UNIX system, with root privileges only used for root commands, this could take quite a while. (2) It's harder for a virus to infect UNIX, also, because it's unlikely that 68020 code from a sun would do much to a Microvax or even a 68010 machine like a 3b1. A binary standard is a two-edged sword. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
erict@flatline.UUCP (j eric townsend) (10/02/88)
In article <2720@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes: [re: virus propagation] > (2) It's harder for a virus to infect UNIX, also, because it's unlikely that > 68020 code from a sun would do much to a Microvax or even a 68010 machine > like a 3b1. A binary standard is a two-edged sword. An interesting side note: binaries from various Convergent Technologies 'frames are said to run quite well on the Unix-PC aka Convergent Technologies Safari 4. Maybe we should try some uVAX binaries on flatline.... :-) -- Motorola skates on Intel's head... J. Eric Townsend See ya at ArmadilloConX! 511 Parker #2, Houston, Tx, 77007 Inet: COSC3AF@george.uh.edu UUCP: uunet!nuchat!flatline!erict Bitnet: COSC3AF@UHVAX1.BITNET ..!bellcore!tness1!/
peter@sugar.uu.net (Peter da Silva) (10/02/88)
In article <36066@philabs.Philips.Com>, mkr@kestrel.Philips.Com (Michael K. Reed) writes: > What is this, some kind of SICK JOKE??? Unix is well known as one of > the premier systems to hack, second only to TWENEX (TOPS-20) for the > award of "Most Abusable Operating System". This might be true, but for the case of a virus it's the toughest. Unless you've made sort of breakthrough that allows a 68000 program to run on a Vax, 8086-family machine, NS32032-family machine, Pr1me, Perkin-Elmer, Gould, Cray, and so on. Or else figure out a way to get someone to unwittingly customise your makefile and compile the virus. Say, by distributing it to alt.sources? And people wonder why I made alt.sources.amiga moderated... -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
papa@pollux.usc.edu (Marco Papa) (10/02/88)
In article <2725@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >In article <36066@philabs.Philips.Com>, mkr@kestrel.Philips.Com (Michael K. Reed) writes: >> What is this, some kind of SICK JOKE??? Unix is well known as one of >> the premier systems to hack, second only to TWENEX (TOPS-20) for the >> award of "Most Abusable Operating System". > >This might be true, but for the case of a virus it's the toughest. ^^^^^^^^ I guess you haven't read any of Fred Cohen's papers, seen any of his programs, read CACM, know of Bill Landreth's UNIX break-ins, looked into the NFS or UUCP code. UNIX is one of the EASIEST platforms to install a virus on. Period. [this is my last on this one. Let's move on]. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/03/88)
Peter da Silva peter@sugar.uu.net Writes:
:This might be true, but for the case of a virus it's the toughest. Unless
:you've made sort of breakthrough that allows a 68000 program to run on a Vax,
:8086-family machine, NS32032-family machine, Pr1me, Perkin-Elmer, Gould, Cray,
:and so on.
:
:Or else figure out a way to get someone to unwittingly customise your makefile
:and compile the virus. Say, by distributing it to alt.sources?
No need to do that at all... one does not have to write the virus
in C. There are a whole host of interpreted languages from the SH or CSH
to AWK, PEARL, LISP, and others that do not require recompilation.
-Mattdan-hankins@cup.portal.com (10/03/88)
In article <2720@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes: >I think you need to add "and has the ability to infect other systems it >comes in contact with". I thought I had implied that; I didn't specify that the replication was limited to a single system. I said, "replicates by usurping the function of the host's code". I should think this would include inter-system replication. >(1) On a non-protected system it would take *0* time to infect the system. >I think the best thing to do would be to have the virus hide itself in a >public bin directory with a a name that's a common typo of one of the standard >commands. Then it prints the usual error message and starts seeing what new >privileges it has. This will go on until root executes it. In a well managed >UNIX system, with root privileges only used for root commands, this could take >quite a while. What you just described is known in some circles as a bacterium. It has different characteristics from a virus. Like a virus, it draws on the resources of the host system for survival and replication. Unlike a virus, it does not attempt to alter the genetic code of host cells (read: alter the executable code of legitimate programs) for reproduction and camouflage. It is more difficult for a bacterium to reproduce unnoticed, partly because it introduces a file that was not present previously, and partly because it cannot spread to a system with a different cpu. >(2) It's harder for a virus to infect UNIX, also, because it's unlikely that >68020 code from a sun would do much to a Microvax or even a 68010 machine >like a 3b1. A binary standard is a two-edged sword. This provides no impedance whatsoever to a virus. An executable-program virus is one that attaches itself to programs in the user's account. The user then does the virus' work for it whenever he sends an executable program to someone else. Why would the user send a 68020 executable to a person with a 68000 machine? He wouldn't. The virus is assured of being copied to environments where it will execute with no problems. Plus, there are interpreted languages that are at least somewhat system-independent. Shell scripts and Rexx programs are as good if not better vectors for a virus than raw executables. By the way, Fred Cohen's original research was done on a Unix machine, as noted in an earlier posting. Dan Hankins
dan-hankins@cup.portal.com (10/03/88)
In article <2725@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes >In article <36066@philabs.Philips.Com>, mkr@kestrel.Philips.Com (Michael K. Reed) writes: >> What is this, some kind of SICK JOKE??? Unix is well known as one of >> the premier systems to hack, second only to TWENEX (TOPS-20) for the >> award of "Most Abusable Operating System". > >This might be true, but for the case of a virus it's the toughest. Unless >you've made sort of breakthrough that allows a 68000 program to run on a Vax, >8086-family machine, NS32032-family machine, Pr1me, Perkin-Elmer, Gould, Cray, >and so on. There is no need for a 68000 program to run on all those other architectures. The virus attaches itself to an executable on the machine it is running on. The user then spreads the virus by copying or allowing tobe copied an infected program to another machine. The virus is never copied to a Vax, 8086, NS32032, Pr1me, etc. A virus copies itself within a machine. Users copy viruses between machines. Dan Hankins
dan-hankins%cup.portal.com@UDEL.EDU (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 7137; Fri, 30 Sep 88 23:16:16 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Fri, 30 Sep 88 23:16:13 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa16274; 30 Sep 88 19:41 EDT Received: from USENET by Louie.UDEL.EDU id aa16092; 30 Sep 88 19:28 EDT From: dan-hankins@cup.portal.com Subject: Re: The ultimate fix!!! Message-ID: <9548@cup.portal.com> Date: 29 Sep 88 03:20:54 GMT Organization: The Portal System (TM) XPortal-User-Id: 1.1001.5361 To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU In article <2689@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >Nope, it's a virus. Yep, it's a virus. >A trojan horse is a technique which you can use to get a virus into another >computer, and it's the way most viruses... including the Amiga bootblock >viruses... work. Sort of. I believe that the classic definition of a Trojan Horse is: A program that appears useful but which has been deliberately and directly modified to contain code unrelated to the program's overt function. This unrelated code may be directly harmful (erase your hard disk), indirectly harmful (release a virus), or innocuous (display a bouncing ball on your screen once per hour). >A virus is any program that hides in a computer system and replicates itself. Close. The first published definition of a computer virus is attributed to Dr. Fred Cohen, who experimented with a non-harmful virus on one of his university's computer systems. Being first, his definition should really be considered the most valid. It certainly holds the closest to the biological analogy: A computer virus is a piece of code that hides by attaching itself to other pieces of code, self-replicates by usurping the function of the host code, and may or may not inflict damage to the host systems. It may or may not have an incubation period, and a specific host trigger. The biological analogy holds up well: 'other pieces of code' are the programs and operating system of the machine, and correspond to cells in a body. Attaching is roughly equivalent to invading a cell. Replication by usurpation (is that a word?) is equivalent to the way a virus replaces the DNA of the target cell with its own. Incubation and triggers have obvious analogies with biological viruses. >Or run a protected operating system like UNIX, where a virus has a *much* harder >time of it. Not really. Fred Cohen's virus experiment was performed on a protected multiuser operating system. The longest it took a virus to attain system priviledges was an half an hour, the shortest five minutes, with an average of about fifteen, *even when the users knew a virus was around*. Dan Hankins
erict%flatline.uucp@UDEL.EDU (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 4414; Sat, 01 Oct 88 23:54:12 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Sat, 01 Oct 88 23:54:09 EDT Received: by Louie.UDEL.EDU id af02594; 1 Oct 88 21:23 EDT Received: from Louie.UDEL.EDU by Louie.udel.EDU id af02310; 1 Oct 88 21:12 EDT Received: from USENET by Louie.UDEL.EDU id aa02209; 1 Oct 88 21:00 EDT From: j eric townsend <erict@flatline.uucp> Subject: Re: The ultimate fix!!! Message-ID: <368@flatline.UUCP> Date: 1 Oct 88 23:00:04 GMT Organization: one bitchin' 3b1 in Tx.Houston.the-Montrose To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU In article <2720@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes: [re: virus propagation] > (2) It's harder for a virus to infect UNIX, also, because it's unlikely that > 68020 code from a sun would do much to a Microvax or even a 68010 machine > like a 3b1. A binary standard is a two-edged sword. An interesting side note: binaries from various Convergent Technologies 'frames are said to run quite well on the Unix-PC aka Convergent Technologies Safari 4. Maybe we should try some uVAX binaries on flatline.... :-) -- Motorola skates on Intel's head... J. Eric Townsend See ya at ArmadilloConX! 511 Parker #2, Houston, Tx, 77007 Inet: COSC3AF@george.uh.edu UUCP: uunet!nuchat!flatline!erict Bitnet: COSC3AF@UHVAX1.BITNET ..!bellcore!tness1!/
peter%sugar.uu.net@UDEL.EDU (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 4294; Sat, 01 Oct 88 23:49:42 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Sat, 01 Oct 88 23:49:39 EDT Received: by Louie.UDEL.EDU id ac02594; 1 Oct 88 21:22 EDT Received: from Louie.UDEL.EDU by Louie.udel.EDU id ac02310; 1 Oct 88 21:09 EDT Received: from USENET by Louie.UDEL.EDU id aa02156; 1 Oct 88 20:59 EDT From: Peter da Silva <peter@sugar.uu.net> Subject: Re: The ultimate fix!!! Message-ID: <2720@sugar.uu.net> Date: 1 Oct 88 21:32:22 GMT Organization: Sugar Land Unix - Houston, TX To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU In article <9548@cup.portal.com>, dan-hankins@cup.portal.com writes: > >A virus is any program that hides in a computer system and replicates itself. > A computer virus is a piece of code that hides by attaching itself to > other pieces of code, self-replicates by usurping the function of the > host code, and may or may not inflict damage to the host systems. It > may or may not have an incubation period, and a specific host trigger. I think you need to add "and has the ability to infect other systems it comes in contact with". > >Or run a protected operating system like UNIX, where a virus has a *much* harder > >time of it. > Not really. Fred Cohen's virus experiment was performed on a protected > multiuser operating system. The longest it took a virus to attain system > priviledges was an half an hour, the shortest five minutes, with an average > of about fifteen, *even when the users knew a virus was around*. (1) On a non-protected system it would take *0* time to infect the system. I think the best thing to do would be to have the virus hide itself in a public bin directory with a a name that's a common typo of one of the standard commands. Then it prints the usual error message and starts seeing what new privileges it has. This will go on until root executes it. In a well managed UNIX system, with root privileges only used for root commands, this could take quite a while. (2) It's harder for a virus to infect UNIX, also, because it's unlikely that 68020 code from a sun would do much to a Microvax or even a 68010 machine like a 3b1. A binary standard is a two-edged sword. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
papa%pollux.usc.edu@UDEL.EDU (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 4324; Sat, 01 Oct 88 23:51:06 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Sat, 01 Oct 88 23:50:58 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id ae23553; 1 Oct 88 4:04 EDT Received: from USENET by Louie.UDEL.EDU id aa23480; 1 Oct 88 3:56 EDT From: Marco Papa <papa@pollux.usc.edu> Subject: Re: The ultimate fix!!! Message-ID: <12492@oberon.USC.EDU> Date: 1 Oct 88 00:18:08 GMT Organization: Felsina Software, Los Angeles, CA To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU In article <9548@cup.portal.com| dan-hankins@cup.portal.com writes: |In article <2689@sugar.uu.net| peter@sugar.uu.net (Peter da Silva) writes: |Close. The first published definition of a computer virus is attributed to |Dr. Fred Cohen, who experimented with a non-harmful virus on one of his |university's computer systems. Yep, USC's Computer Science Dept. VAX-780, a.k.a. usc-cse. | Being first, his definition should really |be considered the most valid. It certainly holds the closest to the |biological analogy: | | A computer virus is a piece of code that hides by attaching itself to | other pieces of code, self-replicates by usurping the function of the | host code, and may or may not inflict damage to the host systems. It | may or may not have an incubation period, and a specific host trigger. | |The biological analogy holds up well: 'other pieces of code' are the |programs and operating system of the machine, and correspond to cells in a |body. Attaching is roughly equivalent to invading a cell. Replication |by usurpation (is that a word?) is equivalent to the way a virus replaces |the DNA of the target cell with its own. Incubation and triggers have |obvious analogies with biological viruses. | ||Or run a protected operating system like UNIX, where a virus has a *much* harder ^^^^ ||time of it. | |Not really. Fred Cohen's virus experiment was performed on a protected |multiuser operating system. The longest it took a virus to attain system |priviledges was an half an hour, the shortest five minutes, with an average |of about fifteen, *even when the users knew a virus was around*. The VAX-780 that Fred used was running UNIX 4.2bsd. All of Dan's quotes are perfectly accurate. To add some info, after the "controlled ex[periment", Fred tried to obtain permission to try it out on other systems (in the instance, a DEC running TOPS-20). The local university "authorities" refused. -- Marco Papa 'Doc' [willing participant in Fred's controlled experiment] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
mkr%kestrel.philips.com@UDEL.EDU (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 4811; Sun, 02 Oct 88 00:31:04 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Sun, 02 Oct 88 00:31:02 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa28835; 1 Oct 88 9:04 EDT Received: from USENET by Louie.UDEL.EDU id aa28826; 1 Oct 88 9:03 EDT From: "Michael K. Reed" <mkr@kestrel.philips.com> Subject: Re: The ultimate fix!!! Message-ID: <36066@philabs.Philips.Com> Date: 29 Sep 88 18:03:39 GMT Organization: Spacely's Space Sprockets, Inc., Briarcliff Manor, NY To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU In article <2689@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) dreams: > >Or run a protected operating system like UNIX, where a virus has a *much* harder ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >time of it. >-- > Peter da Silva `-_-' peter@sugar.uu.net What is this, some kind of SICK JOKE??? Unix is well known as one of the premier systems to hack, second only to TWENEX (TOPS-20) for the award of "Most Abusable Operating System". (my opinion). There are, of course, special Secure UNIX versions, but straight UNIX is probably "login system of choice" for infiltrators... Michael ________________________________________________________________ | Michael Reed !allegra---- | | mkr@philabs.philips.com \ | | AI Department !steinmetz--->---!philabs!mkr | | Philips Laboratories / | | (914) 945-6069 !rutgers---- | +----------------------------------------------------------------+
dan-hankins%cup.portal.com%UDEL.EDU@cunyvm.cuny.edu (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 5676; Mon, 03 Oct 88 21:32:36 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Mon, 03 Oct 88 21:32:33 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id ar10567; 3 Oct 88 18:17 EDT Received: from USENET by Louie.UDEL.EDU id aa10486; 3 Oct 88 18:02 EDT From: dan-hankins%cup.portal.com@UDEL.EDU Subject: Re: The ultimate fix!!! Message-ID: <4398@louie.udel.EDU> Date: 3 Oct 88 22:02:07 GMT To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 7137; Fri, 30 Sep 88 23:16:16 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Fri, 30 Sep 88 23:16:13 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa16274; 30 Sep 88 19:41 EDT Received: from USENET by Louie.UDEL.EDU id aa16092; 30 Sep 88 19:28 EDT From: dan-hankins@cup.portal.com Subject: Re: The ultimate fix!!! Message-ID: <9548@cup.portal.com> Date: 29 Sep 88 03:20:54 GMT Organization: The Portal System (TM) XPortal-User-Id: 1.1001.5361 To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU In article <2689@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >Nope, it's a virus. Yep, it's a virus. >A trojan horse is a technique which you can use to get a virus into another >computer, and it's the way most viruses... including the Amiga bootblock >viruses... work. Sort of. I believe that the classic definition of a Trojan Horse is: A program that appears useful but which has been deliberately and directly modified to contain code unrelated to the program's overt function. This unrelated code may be directly harmful (erase your hard disk), indirectly harmful (release a virus), or innocuous (display a bouncing ball on your screen once per hour). >A virus is any program that hides in a computer system and replicates itself. Close. The first published definition of a computer virus is attributed to Dr. Fred Cohen, who experimented with a non-harmful virus on one of his university's computer systems. Being first, his definition should really be considered the most valid. It certainly holds the closest to the biological analogy: A computer virus is a piece of code that hides by attaching itself to other pieces of code, self-replicates by usurping the function of the host code, and may or may not inflict damage to the host systems. It may or may not have an incubation period, and a specific host trigger. The biological analogy holds up well: 'other pieces of code' are the programs and operating system of the machine, and correspond to cells in a body. Attaching is roughly equivalent to invading a cell. Replication by usurpation (is that a word?) is equivalent to the way a virus replaces the DNA of the target cell with its own. Incubation and triggers have obvious analogies with biological viruses. >Or run a protected operating system like UNIX, where a virus has a *much* harder >time of it. Not really. Fred Cohen's virus experiment was performed on a protected multiuser operating system. The longest it took a virus to attain system priviledges was an half an hour, the shortest five minutes, with an average of about fifteen, *even when the users knew a virus was around*. Dan Hankins
dan-hankins%cup.portal.com%UDEL.EDU%cunyvm.cuny.edu@cunyvm.cuny.edu (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 6555; Mon, 03 Oct 88 23:33:41 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Mon, 03 Oct 88 23:33:34 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id ab15979; 3 Oct 88 21:38 EDT Received: from USENET by Louie.UDEL.EDU id aa15914; 3 Oct 88 21:35 EDT From: dan-hankins%cup.portal.com%UDEL.EDU@cunyvm.cuny.edu Subject: Re: The ultimate fix!!! Message-ID: <4483@louie.udel.EDU> Date: 4 Oct 88 01:34:49 GMT To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 5676; Mon, 03 Oct 88 21:32:36 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Mon, 03 Oct 88 21:32:33 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id ar10567; 3 Oct 88 18:17 EDT Received: from USENET by Louie.UDEL.EDU id aa10486; 3 Oct 88 18:02 EDT From: dan-hankins%cup.portal.com@UDEL.EDU Subject: Re: The ultimate fix!!! Message-ID: <4398@louie.udel.EDU> Date: 3 Oct 88 22:02:07 GMT To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 7137; Fri, 30 Sep 88 23:16:16 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Fri, 30 Sep 88 23:16:13 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa16274; 30 Sep 88 19:41 EDT Received: from USENET by Louie.UDEL.EDU id aa16092; 30 Sep 88 19:28 EDT From: dan-hankins@cup.portal.com Subject: Re: The ultimate fix!!! Message-ID: <9548@cup.portal.com> Date: 29 Sep 88 03:20:54 GMT Organization: The Portal System (TM) XPortal-User-Id: 1.1001.5361 To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU In article <2689@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >Nope, it's a virus. Yep, it's a virus. >A trojan horse is a technique which you can use to get a virus into another >computer, and it's the way most viruses... including the Amiga bootblock >viruses... work. Sort of. I believe that the classic definition of a Trojan Horse is: A program that appears useful but which has been deliberately and directly modified to contain code unrelated to the program's overt function. This unrelated code may be directly harmful (erase your hard disk), indirectly harmful (release a virus), or innocuous (display a bouncing ball on your screen once per hour). >A virus is any program that hides in a computer system and replicates itself. Close. The first published definition of a computer virus is attributed to Dr. Fred Cohen, who experimented with a non-harmful virus on one of his university's computer systems. Being first, his definition should really be considered the most valid. It certainly holds the closest to the biological analogy: A computer virus is a piece of code that hides by attaching itself to other pieces of code, self-replicates by usurping the function of the host code, and may or may not inflict damage to the host systems. It may or may not have an incubation period, and a specific host trigger. The biological analogy holds up well: 'other pieces of code' are the programs and operating system of the machine, and correspond to cells in a body. Attaching is roughly equivalent to invading a cell. Replication by usurpation (is that a word?) is equivalent to the way a virus replaces the DNA of the target cell with its own. Incubation and triggers have obvious analogies with biological viruses. >Or run a protected operating system like UNIX, where a virus has a *much* harder >time of it. Not really. Fred Cohen's virus experiment was performed on a protected multiuser operating system. The longest it took a virus to attain system priviledges was an half an hour, the shortest five minutes, with an average of about fifteen, *even when the users knew a virus was around*. Dan Hankins
peter@sugar.uu.net (Peter da Silva) (10/04/88)
In article <9680@cup.portal.com>, dan-hankins@cup.portal.com writes: > >UNIX system, with root privileges only used for root commands, this could take > >quite a while. > Unlike a virus, > it does not attempt to alter the genetic code of host cells (read: alter > the executable code of legitimate programs) for reproduction and > camouflage. Ick. Now *this* is a tough job. I would think that a "virus" would have to remain a "bacterium" at least until a superuser executed it. Something a non-protected virus doesn't have to worry about. > Why would the user send a 68020 executable to a > person with a 68000 machine? He wouldn't. The virus is assured of being > copied to environments where it will execute with no problems. Why would someone send an executable from one machine to another in the first place? I have only ever seen one non-commercial program distributed in this way, and I *certainly* didn't run it. Given the near-universal availability of 'C', this is an awfully minor problem. Maybe UNIX viruses can spread pretty fast in academic environments, but here in the real world people don't pass around copies of rogue. And, again, any virus is restricted to one CPU family. I'm not really worried about a shell-script virus. You could probably hide one in a sharchive, but since it's human readable it'd become real obvious real quick who's responsible. > > Plus, there are interpreted languages that are at least somewhat > system-independent. Shell scripts and Rexx programs are as good if not > better vectors for a virus than raw executables. > > By the way, Fred Cohen's original research was done on a Unix machine, as > noted in an earlier posting. > > > Dan Hankins -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
dan-hankins@cup.portal.com (10/06/88)
In article <2747@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >In article <9680@cup.portal.com>, dan-hankins@cup.portal.com writes: >>>UNIX system, with root privileges only used for root commands, this could take >>>quite a while. >> >> Unlike a virus, >> it does not attempt to alter the genetic code of host cells (read: alter >> the executable code of legitimate programs) for reproduction and >> camouflage. > >Ick. Now *this* is a tough job. I would think that a "virus" would have to >remain a "bacterium" at least until a superuser executed it. Something a >non-protected virus doesn't have to worry about. It's not tough at all. The virus prepends itself to an executable file. Whenever someone executes the infected file, the virus gets control first. It does its dirty work, then moves the real executable back to where it is supposed to be in memory, then transfers control to the real executable. If the virus is worried about being caught by checksums or file size changes, it compresses the source and adds some bytes to spoof the checksum. >> Why would the user send a 68020 executable to a >> person with a 68000 machine? He wouldn't. The virus is assured of being >> copied to environments where it will execute with no problems. > >Why would someone send an executable from one machine to another in the first >place? I have only ever seen one non-commercial program distributed in this >way, and I *certainly* didn't run it. Given the near-universal availability >of 'C', this is an awfully minor problem. ... more comments about people not copying programs ... People copy executables all the time. Here are some scenarios: 1. Piracy 2. PD/Shareware that comes without source, particularly shareware. 3. Commercial OCO (object-code-only) distribution How often do people demonstrate programs for each other? A friend comes over and sticks his disk in your machine to show you a neat program. You run it, and bingo! you're infected. This was precisely how the Jerusalem Virus propagated. Or a consultant comes over to do some work for you (business scenario). He sticks his disk in your machine to help you, runs an infected utility program, and bingo! you're infected. How often do you really read the source code or recompile the program to make sure it's not infected? What if it's in Modula-2 and you don't have a Modula-2 compiler? I suppose you'll never run any of my programs; I don't write in C. >I'm not really worried about a shell-script virus. You could probably hide one >in a sharchive, but since it's human readable it'd become real obvious real >quick who's responsible. But Rexx is another story. Rexx programs can be quite large and complex, and people simply do not have the time to read every Rexx program that comes their way. And there are plenty of other interpreted languages: Forth, BASIC, Prolog, and so on. Each is a potential cross-architecture virus environment. Everywhere the infected program will run, so will the virus. Dan Hankins
peter@sugar.uu.net (Peter da Silva) (10/06/88)
In article <8810021843.AA10054@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes about viruses on UNIX: > No need to do that at all... one does not have to write the virus > in C. There are a whole host of interpreted languages from the SH or CSH > to AWK, PEARL, LISP, and others that do not require recompilation. Well, Perl and Lisp are out... not universally available. Awk differs too much from version to version. CSH or SH are possibilities. About the only avenue of attack for a *virus* would be in a sharchive. Remember, it has to be something that gets passed onto another machine with some frequency. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/07/88)
:Well, Perl and Lisp are out... not universally available. Awk differs too :much from version to version. CSH or SH are possibilities. About the only :avenue of attack for a *virus* would be in a sharchive. Remember, it has to :be something that gets passed onto another machine with some frequency. :-- : Peter da Silva `-_-' peter@sugar.uu.net : Have you hugged U your wolf today? Ever hear of network viri? Just about every server in existance is buggy, from FTP to SMTP to FINGER. Do you want to guess how many bugs exist in UUCP implementations? BITNET? *ARPA*net? There is no authentication over the ARPAnet! Now you know why the pentagon doesn't run FINGER servers. In anycase, SH and CSH are the most likely. Hardly possibilities... more like guarentees. Of course, nobody ever said that a virus had to be system portable, eh? Security is a figment of our imaginations. As the defense department and univerisities all over the nation have found out, the only reasonably secure system is an isolated one. -Matt
peter@sugar.uu.net (Peter da Silva) (10/08/88)
In article <9764@cup.portal.com>, dan-hankins@cup.portal.com writes: > ... more comments about people not copying programs ... > People copy executables all the time. Here are some scenarios: > 1. Piracy This is an easy one to solve. Don't. > 2. PD/Shareware that comes without source, particularly shareware. On *UNIX*? > 3. Commercial OCO (object-code-only) distribution Yeh, but if you get bit by this you know where to look. > How often do people demonstrate programs for each other? A friend comes > over and sticks his disk in your machine to show you a neat program. On UNIX? Generally he mails me a shar and I break it up and compile it. I don't think I've ever had someone give me anything on disk to show. For one thing it won't run... yeh, it's got a common object format sometimes, but that Vax code really doesn't run very fast on our '286es. [lots of other examples of infection deleted] We're talking UNIX here. You have to recompile it to run it. If the virus can survive 'tar xvf /dev/rmt0; env M_XENIX=1 make' we're doomed. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
peter@sugar.uu.net (Peter da Silva) (10/08/88)
In article <8810062045.AA04638@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > Ever hear of network viri? A fast network is effectively just one big machine. UUCP is not super-secure, but unless you've found a BIG hole in rnews and rmail, it can be made virus safe. > Security is a figment of our imaginations. As the defense department > and univerisities all over the nation have found out, the only reasonably > secure system is an isolated one. Exactly. And that's what most UNIX systems are. Even the ones on Usenet. UUCP is such a weird and narrow channel... I've bitched about that often enough, but it does have its advantages. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
karl@sugar.uu.net (Karl Lehenbauer) (10/08/88)
Let's just say, and I think Peter's point was, that it is at least more difficult to infect and subvert a Unix system than it is to do so on almost all of the prevalent personal computers which do not provide protection of any kind. Damage from a virus/trojan/etc could be significantly reduced on a Unix system by running new programs from a special signon that doesn't own anything important that could be lost. Once a user accepts any binary-only program and starts using it, they are of course vulnerable to that program doing things to them: it executes with their file permissions. If the superuser runs the program, the system is of course blown wide open. A lot of people make a big deal about having the source as protection against virii/trojans, and I will agree that it helps, but who really inspects all the source they pull off the net closely enough to insure that it isn't doing something "funny?" Testing doesn't insure against malicious software, either, as time delays are trivial to construct. -- -- "If it's soft and hard to find, it's wimpy!" -- Wimpy's Software -- uunet!sugar!karl, Unix BBS (713) 438-5018
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/09/88)
karl@sugar.uu.net (Karl Lehenbauer) Writes:
:Damage from a virus/trojan/etc could be significantly reduced on a Unix system
:by running new programs from a special signon that doesn't own anything
:important that could be lost.
Excuse me, bullshit. I wish people would drop this "virus's can be
stopped" crap, it just isn't possible. The whole thing can be characterized by
a single statement:
"Convenience Vs. Security"
Understand the point? The more convenient one makes a system, the
more security holes one puts in it. For example, search paths. Another
example (UNIX): .rhosts, A third example: remote logins. If you start
removing conveniences to give a machine more protection, users will stop
using your machine. It is as simple as that.
STOP TRYING to argue with those of us who provide 'examples', please.
We are only showing the uninformed the tip of iceburg with such examples.
In real-life, there are as many ways to write a virus as there are bytes of
memory in your favorite machine.
** This is the end of my involvement with this line of discussion **
-Mattdan-hankins@cup.portal.com (10/09/88)
In article <2762@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >> 2. PD/Shareware that comes without source, particularly shareware. > >On *UNIX*? No. On any system. This is comp.sys.amiga, after all. Agreed, Unix systems have a bunch of different architectures, so Unix code tends to be distributed as source. But this is the exception rather than the rule. Amigas have a common architecture. A fair amount of Amiga code sharing goes on via sneakernet; after all, even 2400 baud is pretty slow to transmit some packages. And people who supply BBS systems out of their own pockets often don't have the kind of money required to support Amiga software. So much Amiga sharing goes on via disk trading and copying. Take the Fish collection as an example. I'm worried about my *Amiga*. IBM System/370 machines have a common architecture, tend to be heavily networked, and tend to do a lot of OCO code sharing. Same for VAX/VMS, Sun, and so on. >> 3. Commercial OCO (object-code-only) distribution > >Yeh, but if you get bit by this you know where to look. You must not buy much software. Also, viruses with long incubation periods can start from *one* package and infect your entire system within a couple of months, altering file dates so that it is difficult to be sure of the date of infection. Six months later, when your system blows up, *everything* is infected. Still know where to look? >> How often do people demonstrate programs for each other? A friend comes >> over and sticks his disk in your machine to show you a neat program. > >On UNIX? Generally he mails me a shar and I break it up and compile it. No. On machines in general. The universe does not consist solely of Unix machines. >We're talking UNIX here. First of all, no, I wasn't discussing only Unix. Second, all it takes is for one infected file to get in, and then your entire system is infected. Maybe *you* read the source code for every program you get over the net, but I'll bet a virtual cup of coffee that not everyone does. Maybe *you* insist on seeing source code for everything, but again I'll bet not everyone else does. Third, it is possible for there to exist a virus which does the following: * gets control * infects the source code of each .c program over a certain size that has any writes done to it (like when you edit it). * when that .c program is recompiled, it is recompiled with a virus embedded in it. The same one that infected it in the first place. * when you share source, you then infect others. Across the net. Like I said before, how many people take the time to read *in detail* the source code of programs they get over the net? As you implied, the only reason for distributing programs with source is because they won't run on the target machine unless recompiled. Dan Hankins
karl@sugar.uu.net (Karl Lehenbauer) (10/09/88)
In article <8810081911.AA17305@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: I wrote: >:Damage from a virus/trojan/etc could be significantly reduced on a Unix system >:by running new programs from a special signon that doesn't own anything >:important that could be lost. > Excuse me, bullshit. I wish people would drop this "virus's can be > stopped" crap, it just isn't possible. The whole thing can be ... Excuse me, quote me and then say I said something else, goddammit. I said "reduced" not "stopped." Also my posting went on to say that even having the source code is no guarantee of protection AND that no amount of testing could guarantee a program didn't contain malicious code...hardly "virus's can be stopped" crap! -- -- "If it's soft and hard to find, it's wimpy!" -- Wimpy's Software -- uunet!sugar!karl, Unix BBS (713) 438-5018
peter@sugar.uu.net (Peter da Silva) (10/09/88)
In article <8810081911.AA17305@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > Excuse me, bullshit. I wish people would drop this "virus's can be > stopped" crap, it just isn't possible. The whole thing can be characterized > by a single statement: No, I'm not going to excuse you. This sort of language is inappropriate for this forum. I've flamed Matthew (weemba) Weiner for it before. Consider toasted royally just by the comparison. And I am *not* claiming that viruses can be stopped. I'm just claiming that a protected system can slow them down so far they can be easily controlled. Look at the example given to show how insecure UNIX is: a virus took 30 minutes to penetrate security. Compare that to the difficulty of infecting an MS-DOS system... a matter of milliseconds. It's like putting burglar bars on your windows, or an alarm system in your car. The burglar/virus author is after gain... monetary gain or notoriety. He can gain MUCH more pleasure from burning 10,000 PC owners than 50 academic UNIX systems. And he's much less likely to get caught. > "Convenience Vs. Security" > Understand the point? Yes, we understand the point. UNIX is in many ways a *lot* less convenient than AmigaDOS or Messydos. This is why it's more secure. I've deleted all your references, most of which seem to be specific to Berkeley UNIX. Outside the academic environment people generally don't let other people into their systems that easily. Individuals with UNIX systems don't trade binaries, they trade sources. Why? Well, suppose I have a Microport 286 system... a low-end machine. I *can't* use programs other people have running on their AT&T 7300s, their SysV/386, their Xenix 386 and Xenix 68000 systems. And I'm limiting myself too much if I just stick to other Microport people. No, I snarf a copy of the ray-tracer posted to comp.graphics from joe, and I compile it. Now, it may be a trojan horse. It may trash my system. But it's unlikely... it didn't trash Joe's. If it trashes mine, I'm going to have some words with Joe. And he knows it. And I know that it's not going to have any hard little binary nuggets tagged onto the head of its executables. No executables. You have to find some way to infect source. That's tricky. The only channel I can think of offhand would be a sharchive. And people use different sharchivers. And some people use cpio -c or tar. To be really sucessful you have to infect all of these channels... and you have to infect them in different instruction sets and a.out formats. Much easier for the virus vector to pay attention to the unprotected PC market. Let's look at this virus analogy for a minute. We live in a world of real viruses, any of which would kill us in days or hours if our cells didn't have some protective mechanisms. Yes, there are things like AIDS. But that doesn't mean we should all turn our immune systems off and give up. It's convenient to copy binary software. It's convenient to trade disks. It's convenient to run unprotected. But a little bit of security... from buggy software as well as viruses can keep your computer healthier longer. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/10/88)
:In article <8810081911.AA17305@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: :I wrote: :>:Damage from a virus/trojan/etc could be significantly reduced on a Unix system :>:by running new programs from a special signon that doesn't own anything :>:important that could be lost. : :> Excuse me, bullshit. I wish people would drop this "virus's can be :> stopped" crap, it just isn't possible. The whole thing can be ... : >-- uunet!sugar!karl, Unix BBS (713) 438-5018 Writes: :Excuse me, quote me and then say I said something else, goddammit. I said :"reduced" not "stopped." Also my posting went on to say that even having :the source code is no guarantee of protection AND that no amount of testing :>could guarantee a program didn't contain malicious code...hardly "virus's :>can be stopped" crap! Well, let me qualify that: (1) The first bullshit remark was in direct reply to you (2) The remarks following were general to the discussion and not to you (3) And anyway, what you suggest has already been done... in fact, it is done all the time. Since it has already been implemented, no virus writer bothers to write viri that take advantage of a lack of the implementation because everybody implements it. -Matt
lishka@uwslh.UUCP (Fish-Guts) (10/10/88)
In article <2774@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >In article <8810081911.AA17305@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >> Excuse me, bullshit. I wish people would drop this "virus's can be >> stopped" crap, it just isn't possible. The whole thing can be characterized >> by a single statement: > [A lot of followup replies and examples by Mr. da Silva deleted here] > >Let's look at this virus analogy for a minute. We live in a world of real >viruses, any of which would kill us in days or hours if our cells didn't >have some protective mechanisms. Yes, there are things like AIDS. But that >doesn't mean we should all turn our immune systems off and give up. Our disks have protective mechanisms: the write-protect tabs. We have virus-checking programs. However, there is a limit to how far one wants to protect oneself. For instance, the best protection against AIDS is abstinence. The same goes for software: if you don't want any possibility of a virus, do not introduce new software into it. Otherwise you "run the risk." I think what Mr. Dillon is getting annoyed at is the many radical ideas that have been posted. For instance, someone went as far as to propose putting boot-block checks in the Kickstart ROMs. Although I do not agree with Mr. Dillon's language, I do agree with his feelings (if I have indeed read them correctly, which I may not have). >It's convenient to copy binary software. It's convenient to trade disks. >It's convenient to run unprotected. But a little bit of security... from >buggy software as well as viruses can keep your computer healthier longer. Of the many aspects of life is getting a virus in your body every now and then. Almost everyone gets sick. The same can happen to your computer if you expose it to a lot of outside software. When people get sick, they take medicine. The same can be done with the computer. This agrees with your analogy. Personally, I have *never* caught a computer virus, and I get Fred Fish disks from the local users' group monthly, as well as commercial software. My friend, who is the President of the users' group, and who downloads a lot of programs from a local BBS, has also never encountered a virus. Other friends with other machines have not had any trouble with viruses. At least from my end, they do not appear to be that much of a problem that a lot of computer "antigens" (i.e. virus checkers) are needed. When I do get a computer virus, I will eliminate it from my disks, pull out my backups, recopy my important games (which I always run write-protected or using a copy), re-install my other bootables, and I will be virus-free. No problem. > Peter da Silva `-_-' peter@sugar.uu.net -- Christopher Lishka ...!{rutgers|ucbvax|...}!uwvax!uwslh!lishka Wisconsin State Lab of Hygiene lishka%uwslh.uucp@cs.wisc.edu Immunology Section (608)262-1617 lishka@uwslh.uucp ---- "...Just because someone is shy and gets straight A's does not mean they won't put wads of gum in your arm pits." - Lynda Barry, "Ernie Pook's Commeek: Gum of Mystery"
peter@sugar.uu.net (Peter da Silva) (10/11/88)
In article <9880@cup.portal.com>, dan-hankins@cup.portal.com writes: > In article <2762@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > >> 2. PD/Shareware that comes without source, particularly shareware. > >On *UNIX*? > No. On any system. This is comp.sys.amiga, after all. I *know* that. The discussion, however, has veered to "is UNIX safe from viruses", and I'm trying to defend the position that it's a lot safer than non-protected proprietary systems. I've never said that it's 100% safe, just that it's safe enough that people wanting to have a little malicious fun are likely to direct their attentions somewhere they get more bang for the buck. It all started when I tossed off a remark to the effect that if viruses worry you that much, switch to UNIX. See what you get when you jump into the conversation half-way through? (lots of smileys, OK?) > I'm worried about my *Amiga*. Me too. I practice safe computing, as much as I can, so I'm not *too* worried. I'll be more worried when I get a hard disk, but that's a ways off. I'll probably upgrade to a 2000 first. Or maybe, the way things are going, to a 3000 so I don't have to get a 3000-and-2 box. :-> > You must not buy much software. Again, on UNIX, no I don't buy much software. Come to think of it, I don't buy much Amiga software either. See previous paragraph, re "hard disk". > Second, all it takes is for one infected file to get in, and then your > entire system is infected. Maybe *you* read the source code for every > program you get over the net, Before I post it to alt.sources.amiga I at least give it an eyeball. And I test-run it on a system with no writable permanent devices. I guess a virus could get by. Let me know if it does, eh? > Third, it is possible for there to exist a virus which does the following: > * gets control > * infects the source code of each .c program over a certain size that has > any writes done to it (like when you edit it). This is probably a difficult (in the theoretical sense) for a virus to do automatically. I still haven't found a reliable 'ctags' that can deal with all the variations of 'c' source formatting that comes across my desk. I suspect this virus would have to have most of a complete 'C' parser, which would be rather big for a virus. Oh, I'm sure that there are ways of doing it, but again it's easier to write a program that infects the boot block or selected system commands. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
dan-hankins@cup.portal.com (10/11/88)
What protection the UNIX community has against viruses does *not* stem from memory protection. That is trivial for a virus to passively evade. What protection it has comes from the fact that UNIX has been ported to so many incompatible machine architectures. And it *is* possible to infect source. I would bet that less than one tenth of one percent of the UNIX users out there carefully inspect source code before compiling. And as I noted in a previous posting, it is indeed possible to infect .c *source* files. When compiled on whatever machine, they then (upon execution of the object) infect whatever other .c files they can find. One of the primary characteristics of viruses is that the traditional protection mechanisms designed to keep users away from other users' data (file protection, memory protection, logon passwords, etc.) are of little or no use. Dan Hankins
karl@sugar.uu.net (Karl Lehenbauer) (10/12/88)
I wrote: >Damage from a virus/trojan/etc could be significantly reduced on a Unix system >by running new programs from a special signon that doesn't own anything >important that could be lost. Matt Dillon wrote: > Excuse me, bullshit. I wish people would drop this "virus's can be > stopped" crap, it just isn't possible. The whole thing can be ... ...and to clarify... Matt <8810092209.AA09182@cory.Berkeley.EDU> > Well, let me qualify that: > > (1) The first bullshit remark was in direct reply to you The "bullshit," especially twice, is *really* offensive and I'm finding it hard not to yell. What is "bullshit" about my statement? I *never* claimed virii could be guaranteeably stopped. I *do* think we should do what we can to keep our systems from getting infected and practice good "damage control" when they do. Do you disagree that Unix systems are better protected than totally unprotected systems like the Amiga and the PC, are you saying that Unix is somehow wide open such that running mischevious code from any signon means the system's hosed (and if so, how?), that people shouldn't even bother with countermeasures, or what? Two context-free "bullshits" do not help to clarify why I am wrong. -- -- "We've been following your progress with considerable interest, not to say -- contempt." -- Zaphod Beeblebrox IV -- uunet!sugar!karl, Unix BBS (713) 438-5018
papa@pollux.usc.edu (Marco Papa) (10/12/88)
In article <2791@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes: > Do you disagree that Unix systems are better protected than totally ^^^^^^^^ Yep, I do. Regarding viruses and protection in general, UNIX is as (in)secore as anybody else's computer [ make your pick with or without the () ]. >unprotected systems like the Amiga and the PC, are you saying that Unix is >somehow wide open such that running mischevious code from any signon means >the system's hosed (and if so, how?), that people shouldn't even bother with >countermeasures, or what? You should have been around USC this week when as part of a Computer Security class students were instructed to build "benign" viruses on our Suns and VAXes running UNIX [USC has always been at the "avant-gard" in computer viruses theory and experiences for quite some time :-)]. Anyway, before speaking again why don't you do your research? Read about ANSI terminals and what "magic" things one can do with them. At least pick up one of the last issues of CACM and read how safe are UNIX systemes like mail, uucp, emacs and NFS. Gee, I said I would shut up, but when some ignorant [read the meaning of the word in Webster's pal, this is not an offense, just a fact] like you speaks, it is really too much. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
terry@wsccs.UUCP (Every system needs one) (10/12/88)
In article <9680@cup.portal.com>, dan-hankins@cup.portal.com writes: > In article <2720@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes: > > >I think you need to add "and has the ability to infect other systems it > >comes in contact with". > > I thought I had implied that; I didn't specify that the replication was > limited to a single system. I said, "replicates by usurping the function > of the host's code". I should think this would include inter-system > replication. > > >(2) It's harder for a virus to infect UNIX, also, because it's unlikely that > >68020 code from a sun would do much to a Microvax or even a 68010 machine > >like a 3b1. A binary standard is a two-edged sword. ken or dmr wrote one for UNIX way back when. It was part of the portable C compiler. It recognized login.c and altered it to accept an alternate password at compilation time. It was especially clever, since it also recognized the C compiler source and fixed it to fix the C compiler source and login, so even if you fixed it, it fixed itself back. > This provides no impedance whatsoever to a virus. An executable-program > virus is one that attaches itself to programs in the user's account. The > user then does the virus' work for it whenever he sends an executable > program to someone else. Why would the user send a 68020 executable to a > person with a 68000 machine? He wouldn't. The virus is assured of being > copied to environments where it will execute with no problems. It would be relatively simple to provide a virus which crawled through the net an replaced /bin/login by going through 2 or 3 holes in pre-5.3 uucp (raising any hackles, anyone?). This can be gotten around by protecting any of the 3 holes, the easiest of which is to mount the /usr/mail directory someplace other than the same volume as /etc. The other two involve breaking uucp for either calling in, out, or mail delivery. One other way would be to remove the C compiler entirely 8-(. > Plus, there are interpreted languages that are at least somewhat > system-independent. Shell scripts and Rexx programs are as good if not > better vectors for a virus than raw executables. What good is a virus people can read? (for that matter, what good is a virus, other than as an example of how to keep code running across a warm boot?). | Terry Lambert UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry | | @ Century Software OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'I have an eight user poetic liscence' - me |
karl@sugar.uu.net (Karl Lehenbauer) (10/12/88)
In article <12737@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: > Anyway, before speaking again why don't you do your research? Et tu, Marco? I asked for clarification to a remark calling my statement absurd without any specifics. It was NOT insistence that it was correct. >Read about ANSI > terminals and what "magic" things one can do with them. At least pick up > one of the last issues of CACM and read how safe are UNIX systemes like mail, > uucp, emacs and NFS. I am well aware of the abilities of *some* terminals to transmit data in response to certain escape codes and the ramifications thereof. I have a trap in my home directory at work that causes a cute program to run if someone cats the file. (We all have the same kind of terminals) What kind of terminal do I have? Your virus will need to know that -- already arbitrarily limiting the systems it can run on. In other words, your virus will not be nearly as universal to all Unix systems as an Amiga virus is to all Amigas. I saw the emacs problem in comp.risks. We don't have emacs here. I guess this system and hundreds of thounsands of other unix systems are invulnerable to malicious code propagating itself in this manner. Does the mail bug rely on transmitting escape sequences to the terminal or being read into emacs? My mailer maps unprintable characters and most others I'm aware of do as well -- hope it's more than that. uucp, huh? Are we talking security holes or places for virii to propagage? This is pretty far afield from my caveat-laden remark that it is somewhat safer to run unknown programs from a guest signon, which started this whole thing. NFS: I don't use it -- guess my unix system and hundreds of thousands of others are invulnerable to malicious NFS code. You at least give examples, but they are far from as universally contagious as ones targeting specific unprotected machines. Heck, in my original posting I said "No system is secure" and "even if you have the source code you can't be sure a program isn't malicious" -- hardly ignorant knee-jerk opinions and ones I think you strongly agree with. I'll look for the CACM articles you mention. Again, my message wasn't to repeat my "ignorance," it was to ask for specifics, thus I didn't propound ignorance by speaking twice, so I find your remarks that I spoke twice in ignorance to be incorrect, demeaning and offensive. -- -- "We've been following your progress with considerable interest, not to say -- contempt." -- Zaphod Beeblebrox IV -- uunet!sugar!karl, Unix BBS (713) 438-5018
ain@s.cc.purdue.edu (Pat-bob White) (10/13/88)
In article <2757@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >CSH or SH are possibilities. About the only >avenue of attack for a *virus* would be in a sharchive. Remember, it has to >be something that gets passed onto another machine with some frequency. Ever wonder why Matthew, Brent and I decided to test everything submitted before we posted it? trojan horse, virus.. same word different pronouncation. -- Pat White (I'd rather be sailing :-) ARPA/UUCP: k.cc.purdue.edu!ain BITNET: PATWHITE@PURCCVM PHONE: (317) 743-8421 U.S. Mail: 320 Brown St. apt. 406, West Lafayette, IN 47906 [let's all help Joe out... send your IFF pictures or music to joe@dayton.UUCP]
dan-hankins@cup.portal.com (10/13/88)
In article <2791@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes: >Do you disagree that Unix systems are better protected than totally >unprotected systems like the Amiga and the PC Not to answer for Matt, but yes, I think I disagree. It is not memory and file protection that protects Unix from viruses. As far as I can tell, there is only one real protection Unix has against viral attack. Unix runs on such a large number of incompatible architectures that people do not share executables. Instead they share source and do recompiles. Source sharing isn't perfect (it is possible to write a virus that will infect via a combination of source code and executables), but it's much better than sharing executable code. It doesn't protect against viral spread on a single machine (I would imagine that a lot less source sharing goes on on a single machine where the architecture is obviously compatible), but it does severely limit the spread of viruses over the net. >are you saying that Unix is somehow wide open such that running >mischevious code from any signon means the system's hosed (and if so, >how?), that people shouldn't even bother with countermeasures, or what? Maybe Matt's saying that, but I'm not. I do believe that there are measures which can be taken to severely limit the spread and destructiveness of viruses. However, these methods involve entirely new operating systems. For existing systems, the best that can be done is to have someone whose job it is to hunt down these suckers and come up with antidotes on a one-per-virus-class basis. This may not even be possible for some classes (for instance self-mutating viruses). I believe that the real answer to viruses (not total but very good) is to implement an object-oriented operating system in which objects are treated like users on a multiuser system. Implement 'need-to-know' and 'secret clearance' type restrictions on the objects in the system. Dan Hankins
peter@sugar.uu.net (Peter da Silva) (10/14/88)
In article <3599@s.cc.purdue.edu>, ain@s.cc.purdue.edu (Pat-bob White) writes: > Ever wonder why Matthew, Brent and I decided to test everything submitted > before we posted it? trojan horse, virus.. same word different pronouncation. Probably the same reason I test everything I post to alt.sources.amiga. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
lishka@uwslh.UUCP (Fish-Guts) (10/14/88)
In article <12737@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >In article <2791@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes: >> Do you disagree that Unix systems are better protected than totally > ^^^^^^^^ >Yep, I do. Regarding viruses and protection in general, UNIX is as (in)secore >as anybody else's computer [ make your pick with or without the () ]. > [...some text deleted here ...] > >At least pick up >one of the last issues of CACM and read how safe are UNIX systemes like mail, >uucp, emacs and NFS. No kidding! As a practical example, I offer the following: I lived with two other guys and cat named "Trout" one year. One of the guys forgot to get the cat some cat-food. The next day he received (over e-mail!) a "letter" from our cat (trout@1124Emerald) on his Unix machine, saying that the cat was hungry. He and I were truly impressed. No, our cat does not use computers. It was of course a practial joke performed by our other room-mate. We pressed him and he told us how it is done. Truly simple if you know what to do (no, I am not telling anyone). The moral of the story is: never take your email for granted; it is to easy to fake. As for Netnews, every year around April 1st there are all sorts of "interesting" postings. Unix, secure? HAH! [p.s. what Mr. Papa said about ANSI terminals of course is true -- it is well worth your while to see some of the totally SickAndDeranged that can be done with them!] >-- Marco Papa 'Doc' .oO Chris Oo. -- Christopher Lishka ...!{rutgers|ucbvax|...}!uwvax!uwslh!lishka Wisconsin State Lab of Hygiene lishka%uwslh.uucp@cs.wisc.edu Immunology Section (608)262-1617 lishka@uwslh.uucp ---- "...Just because someone is shy and gets straight A's does not mean they won't put wads of gum in your arm pits." - Lynda Barry, "Ernie Pook's Commeek: Gum of Mystery"
dan-hankins@cup.portal.com (Daniel B Hankins) (10/14/88)
In article <3599@s.cc.purdue.edu> ain@s.cc.purdue.edu (Pat-bob White) writes: >trojan horse, virus.. same word different pronouncation. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. The only similarities between Trojan horses and viruses are: 1. They both attack multiple systems. 2. They both tend to do bad things to systems on which they get control. Their methods of attack and spread are completely different. A virus is a piece of code that attaches itself to legitimate programs. It spreads by gaining control when the user runs an infected program and then attaching itself to other legitimate programs. It relies on users sharing legitimate code or demonstrating legitimate code for each other in order to propagate. It may or may not do damage to the systems it spreads to (viruses can be benign). A Trojan Horse is a legitimate program that has been deliberately modified by a human to contain a piece of code that implements a function outside the advertised scope of the program. Again this may be malicious (destroy data, for instance) or benign (print out a cute little message once and then get rid of itself). Note that a traditional Trojan horse may be used as the initial vector for a virus (that is, the unadvertised code inserted into the Trojan could be a virus). Dan Hankins
gmg@hcx.uucp (Greg M. Garner) (10/14/88)
In article <2809@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes: > > Probably the same reason I test everything I post to alt.sources.amiga. > -- > Peter da Silva `-_-' peter@sugar.uu.net > Have you hugged U your wolf today? I am missing out on good stuff since I am unable to get alt.sources.amiga the normal way. Is there anyone out there that is archiving the stuff off this group where I could snagg it via anonymous ftp? I know that the moderator of the group is supposed to do that (right?), but is anyone doing it for this group since there is no moderator? Thanks. Greg Garner gmg@hcx.uucp 501-442-4847 /* Come on guys, lets get busy and build a FTL drive! */
peter@sugar.uu.net (Peter da Silva) (10/14/88)
In article <9997@cup.portal.com>, dan-hankins@cup.portal.com writes: > I believe that the real answer to viruses (not total but very good) is to > implement an object-oriented operating system in which objects are treated > like users on a multiuser system. Implement 'need-to-know' and 'secret > clearance' type restrictions on the objects in the system. Oh, god no. I'm not willing to give up the convenience of UNIX for a mil-spec operating system. It'd still be open to a trojan horse... if you need a certain security capability, stick a program out there and wait until someone wit the capability you need runs you. If that doesn't work, wait until someone with the set-capability capability runs you. The Navy has a team they use to test out systems, the Tiger Team. Last I heard they had been slowed by secure systems but not stopped by any. Do you put your car in an armored garage every night? Keep an armed guard on it? No. Not even the military does that except for VERY expensive "cars". It's too expensive and inconvenient. We're not dealing with the Soviets here, just the kid down the block who wants to go for a joyride. If you lock your car and your neighbor doesn't, who's going to find his car abandoned in a drainage ditch tomorrow? Given that hardly anyone bothers with cyber-locks these days, a little security is plenty. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
rminnich@super.ORG (Ronald G Minnich) (10/14/88)
In article <9997@cup.portal.com> dan-hankins@cup.portal.com writes: >Source sharing isn't perfect (it is possible to write a virus that will >infect via a combination of source code and executables), but it's much >better than sharing executable code. OK, go read (i sound like a broken record) Thompson's ACM article on such things. You can build bad things into a compiler and then hide them easily. It is TRIVIAL. Somebody got on this discussion with me the other day. Suppose you wanted to infect everybody. What you might do is take a freely redistributable program and add enhancements to it, then hand it out in source form. The program you really want to use would be a really big one, say 40-60k lines or so, and you want the infection to be 10-20 lines, so that you could easily hide what you are doing. You would also want the lowest common denominator bug common to all unix systems, but that is easy. Now from this description most of you ought to be able to think of such a program and such a bug, and realize they ALREADY EXIST, and you might even wonder: Has it already happened? (well, actually it has, once, unintentionally) You can't trust programs, only people. ron
peter@sugar.uu.net (Peter da Silva) (10/15/88)
In article <906@cseg.uucp>, gmg@hcx.uucp (Greg M. Garner) writes: > In article <2809@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes: > > Probably the same reason I test everything I post to alt.sources.amiga. > Is there anyone out there that is archiving the stuff off > this group where I could snagg it via anonymous ftp? > but is anyone doing it for this group since there is no moderator? Thanks. Well, there is a moderator for a.s.a. I am it and it am I. I send everything I post to uunet and it ends up in uunet!~/amiga-sources. I don't know the internet numerical address for uunet, but I'm sure you can find it. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
dan-hankins@cup.portal.com (Daniel B Hankins) (10/20/88)
In article <729@wsccs.UUCP> terry@wsccs.UUCP (Every system needs one) writes: >What good is a virus people can read? (for that matter, what good is a >virus, other than as an example of how to keep code running across a warm >boot?). 1. In theory, a virus would be a good way to implement distributed processing. However, its potential for mischief makes this much too dangerous a path to pursue. 2. Remember the CHRISTMA bacterium? It was in Rexx, and it wasn't even compressed. Anybody could read it, yet it managed to clog IBM's network in a matter of hours. I was one of the poor suckers who looked at the first page of code, looked at who it was from, and concluded that it was okay to run it. Boy was I wrong. Ever try to read a LISP program or APL program of more than fifty lines? Was it fun? Most people won't bother to read source code for their interpreters, even the more understandable ones. An assumption that has permeated this entire virus discussion is that the sole purpose of viruses is to damage as many systems as possible. I say that this is not the case. Computer vandalism is simply the most *visible* form of hostile code. I find it easy to imagine a thief creating a virus that does no destruction of data; rather it propagates till it reaches a bank system or corporate accounting database and then proceeds to transfer funds. Or a spy creates one that propagates until it reaches systems on which sensitive data are kept. It then transmits the data to a 'drop' point. You are unlikely to hear reports of such programs here or on the news; First, such viruses (if well-written) are unlikely to attract attention until after they have completed their objectives. Secondly, banks and the military are loathe to admit that their system security has holes. Dan Hankins