vancleef@iastate.edu (Van Cleef Henry H) (04/04/91)
I have been asked to consider the possibility of virus, trojan horse, etc. attacks on a distributed Unix fileserver system. My role with Iowa State is as a consultant--Unix is new here, and the system we are building, known as "Vincent," while not new in concept, is new in many details of its implementation. My credentials may be verified with Dr. George Strawn, director, and George Covert, associate director, of the Iowa State Computation Center. My study begins with some assumptions, which I should state here. a. That MS-Dos viruses (is this an all-encompassing term for things that tamper with and destroy the OS and programs?) have conceptual parallels in the Unix o/s. i.e. the kernel is equivalent to COMMAND.COM, the file system superblock is equivalent to the FAT, etc. b. That all "security" to read and write as a superuser has already been breached and that this breach has gone undetected. c. That one workstation with a bootable hard disk is accessible to the individual planning to damage the system. d. That the individual is sufficiently sophisticated to avoid leaving obvious clues (file sizes, dates, etc.). e. We should consider that the individual may have access to the o/s source code. I am particularly interested in comments about: a. Known attacks on Unix o/s involving tampering with the o/s kernel and commands. b. Methodes for checking integrity of these. c. Methods for damage control to prevent propogation throughout the net. The purpose in making this post is to establish contact with others working with similar issues. Iowa State is not presently prepared to quarantine or work with actual "virus" code. Our concern is to plan for dealing with attacks of this nature when, as, and if they appear. (Since they are not in my signature file) Henry van Cleef 219 Durham Center, Iowa State Univ. 515-294-2903 (voice)
CHESS@YKTVMV.BITNET (David.M.Chess) (04/05/91)
vancleef@iastate.edu (Van Cleef Henry H): > I have been asked to consider the possibility of virus, trojan horse, > etc. attacks on a distributed Unix fileserver system... > > My study begins with some assumptions, which I should state here... > > b. That all "security" to read and write as a superuser has already > been breached and that this breach has gone undetected. > > c. That one workstation with a bootable hard disk is accessible to the > individual planning to damage the system... Those are fine assumptions if you only want to worry about traditional sorts of attacks (Bad Guy breaking into your system and doing Bad Things by typing at his terminal/workstation). But if you also want to worry about the new sorts of risks that come with viruses, you should make assumptions that are more like: < b'. That, although the technical security of the system may be intact < and unbreached, there may be program-sharing patterns that would < allow a spreading virus to get from an "exposed" user to one with < superuser authority, through innocent actions of authorized users. < < c'. That, rather than a single individual actively attempting to do < damage on your system, there may be viruses in the outside world < that could inadvertantly be brought into the organization through < the innocent actions of authorized users importing programs. The new dangers that viruses add are that they can cause an "attacker's" code to run with privileges on your system even if your system's security is unbreached, no passwords have been guessed, everyone with access to your system is well-intentioned, and the attacker has in fact never touched a workstation attached to your system (he may never even have *heard* of your system). DC
VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) (04/06/91)
>Date: Wed, 03 Apr 91 21:10:57 +0000 >From: vancleef@iastate.edu (Van Cleef Henry H) >... >b. That all "security" to read and write as a superuser has already >been breached and that this breach has gone undetected. If the first part of this is true, *all* bets are off. See Ken Thompson' Turing Award lecture "On Trusting Trust" for an example. If you are permitting the intruder super-user access and source access, about the *only* way to recover is to scrub the disks and re-install the system from known good tapes from the locked vault. You will have to first format the disks, then convince yourself that the distribution tapes are in fact clean - don't trust your backup tapes, they might be bad. Then re-install the operating system. Then restore user files, checking each one for any and all possible trojans that might still be left in them. Under Unix, if you don't trust your kernel, you can't trust ANYTHING. Your only hope is if you can find a "trick" that the intruder didn't trap against in his kernel hacking. However, Dijkstra once said: "Testing can show the presence of bugs, but not their absence." So if you DONT find anything, that does NOT prove your system is clean, it only means that it's *either* clean *or* the intruder is a step ahead of you. The second part - the assertion that the breach is undetected - is also quite suspect. Remember - we've only caught the second best computer criminal. The best is so good that we'll never catch him. If your system check (whatever its form) actually *finds* anything, then it won't be an undetected breach anymore. If you are planning a *serious* research effort on Unix, you should be addressing the issues of access right compartmentalization - i.e. work on closing the *holes* so that the guy can't *GET* to superuser status... Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute
mrs@netcom.com (Morgan Schweers) (04/08/91)
Greetings,
A few words on "Unix" viruses... As far as I can tell they are
not very likely. First off, the 'kernel' is *NOT* comparable to
COMMAND.COM... The kernel is more comparable to IBMBIO.COM and
IBMDOS.COM. The '?sh' programs are more comparable to COMMAND.COM.
If you are to assume that 'root' has been breached, then you are
in trouble already. If a person breaches 'root', they are much less
likely to install a virus as install a trapdoor (patching login.c) or
such. The reasons are manifold... A few reasons would be that 1) the
executable file format is (as far as I know, anyone care to correct
me?) not as available. 2) REAL security (as in, file-level access) is
implemented in Unix. This means that non-prived person <X> can't
modify (usually) prived program <Y>. 3) Most viruses exist from the
binary level, so far. This is difficult to 'spread' since many
machines can be running Unix, but not be binary compatible.
That generally explains why a virus won't spread too far. Now let
me take the other side... I've seen (yes, SEEN) a 'worm' under Unix
that can be very unfortunate. The example in particular that I saw
involved the PATH statement of most people's .login's, and the fact
that many people put '.' first in their PATH. Thus, say you 'cd' to
a directory, and do an 'ls', and there is an 'ls' program in their
directory... Well, you get the idea. It was substantially more
complicated than that, but that's the basic idea. *THIS* (and silly
other security precautions, like proper passwording (or shadowing, or
any of the other miscellaneous topics)) is far more important to deal
with than worrying about viruses under Unix.
Under MS-DOS, it's not possible to close all the security holes
without throwing out the OS and starting anew. Under Unix, the
features are there and it's just a matter of implementing them. The
same is true of most multi-user OS's. If it's made to provide
seperation between users, then it's magnitudes harder to write a
successful virus.
One final note... I believe it has been done by one Fred Cohen,
but I never learned the details of his experiment. However, the
likelyhood of it spreading *OFFSITE* is virtually nil, which means
your likelyhood of getting it is equivelant.
I'm *NOT* a Unix guru, however. I'd *VERY MUCH* like people to
correct me on matters of fact.
-- Morgan Schweers
P.S. It has been pointed out to me that it is possible to spread a BSI over a
BBS if it's done on purpose. I apologize. Anything is possible if it's
done on purpose. What I meant to say is getting a BSI off a BBS is far
less likely than getting a file infector, and that's a pretty small chance
anyway. <Sigh>
+------------------
I don't speak for my company, since my company doesn't do Unix work. I do,
and I love it, but I don't get paid for it, so there. -- mrs@netcom.com
- ------------------+lev@slced1.Nswses.Navy.Mil (Lloyd E Vancil) (04/09/91)
VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) writes: to vancleef@iastate.edu (Van Cleef Henry H) >"Testing can show the presence of bugs, but not their absence." > >So if you DONT find anything, that does NOT prove your system is >clean, it only means that it's *either* clean *or* the intruder is a >step ahead of you. > >computer criminal. The best is so good that we'll never catch him. >If your system check (whatever its form) actually *finds* anything, >then it won't be an undetected breach anymore. A very scary thought when you consider that the bad guy in "The Cookoo's egg" was caught because of a billing error and the tenacity of one individual. The insights that book offers into the foilables of the typical system manager and the attitudes towards this type of thing are interesting. Would it be better to take for granted that your security has been breached and operate based on that? If you did make that assumption, what would you do to make a first level check? Trust.... - -- * suned1!lev@elroy.JPL.Nasa.Gov sun!suntzu!suned1!lev . lev@suned1.nswses.navy.mil + . + * S.T.A.R.S.! The revolution has begun! * - ----------------- My employer has no opinions. These are mine! --------------- - -