lath@geocub.greco-prog.fr (Laurent Lathieyre) (07/24/90)
Does somebody known if there was some cases of viral infection that came through other than floppy exchange and data interchange over Internet ? I think to other networks, through atmospheric radio transmissions, magnetic induction, ... Alike, did some Trojan horses be discovered in some operating systems ? I wonder if operating systems shouldn't preferably be delivered in source form rather than in compiled form... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- !\/! It's !\/! | Laurent Lathieyre | (oo) Better (o-) | E-mail : lath@geocub.greco-prog.fr | =\/= Manually =\/= -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) (07/25/90)
>Date: 24 Jul 90 13:42:46 +0000 >From: lath@geocub.greco-prog.fr (Laurent Lathieyre) >Subject: other ways for viral injection ? >... > > Alike, did some Trojan horses be discovered in some >operating systems ? I wonder if operating systems shouldn't >preferably be delivered in source form rather than in >compiled form... Even source form is not foolproof.... Consider the following (due to either (I think) Thompson or Ritchie, I forget which): (/bin/login is the Unix login processor, /bin/cc is the C compiler) They took the source for /bin/login, put in a trapdoor. They recompile, then put the old source back. OK.. Backdoor installed, but it goes away the next time you recompile /bin/login. Step two: You modify /bin/cc to recognize when it is compiling /bin/login (takes a lot of context-sensitive matching, but can be done). Have it insert the code you want at the appropriate point. Now we have a clean source for /bin/login, that regenerates when you recompile it. However, recompiling the C compiler, and then recompiling /bin/login removes it. Step 3: You modify /bin/cc some more, to (a) insert the /bin/login modification and (b) insert itself if recompiling /bin/cc (i.e. a self-replicating modification). You then put in a *clean* version of the cc and login sources, and recompile EVERYTHING. The sources all look OK, and every time you recompile /bin/login, the trapdoor is inserted, and everytime you recompile /bin/cc, the code to INSERT the trapdoor is inserted. The only way to recover from this is to restore the C compiler from a backup tape, and recompile everything... The citation went on to say that they actually DID these changes to the C compiler, just to see if they were doable. No version was ever released to the outside world, but the NSA was bidding for Unix systems and there was great temptation.... Valdis Kletnieks
peter@ficc.ferranti.com (Peter da Silva) (07/27/90)
lath@geocub.greco-prog.fr (Laurent Lathieyre) writes: > Alike, did some Trojan horses be discovered in some > operating systems ? I wonder if operating systems shouldn't > preferably be delivered in source form rather than in > compiled form... (a) You need *some* executable code to get it up the first time. (b) There is no theoretical reason you can't put a virus in source code. I first brought this point up in a "hoax" posting a few weeks before the Internet Worm showed up (and when lots of people were saying that you couldn't do a UNIX virus). It's been reposted on virus-l, and I'm sure it's in the archives. - -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
john@uunet.uu.net (07/31/90)
> Does somebody known if there was some cases of >viral infection that came through other than floppy exchange >and data interchange over Internet ? I think to other networks, >through atmospheric radio transmissions, magnetic induction, ... I think back to a wonderful little nasty from the CP/M days. There was a version of MODEM7 floating around that had a patch in it that caused it to do all sorts of neat things when certain character sequences were received over the async channel. One of these nasty things was to take a character string coming in over the modem and patch it into the bios at a jump vector specified in the incoming string. I'm sure this was probably intended to allow someone to do something useful such as replace I/O drivers on the fly for things like remote tty services or other form of redirection. But, if you had a nasty streak and you knew about this 'backdoor', imagine the damage you could have done. (btw: it did this patching with no notification to the user of the 'patched' machine). This was actually one of the slickest little routines I ever saw in the CP/M 'virus/trojan' category and it has caused me to run all of my comm programs through a datagram analyzer while I'm 'breaking them in'. Especially if they are 'special' purpose comm programs or if they require passwords to be automatically sent by the package rather than manually entered by the user. As for other networks....I can't think of a network that HASN'T come under attack in one way or another. Magnetic induction? Hmmmm...I don't think the technology is advanced enough to permit a focused field of the precision required to affect a machine (selectively altering bits that is) from an external source. Of course a good magnetic 'bulk eraser' provides a quick method of simplifying your file management :) ____________________________________________________________________________ === =--==== AT&T Canada Inc. John Benfield =----==== 3650 Victoria Park Ave. Network Support Analyst (MIS) =----==== Suite 800 ==--===== Willowdale, Ontario attmail : ~jbenfield ======= M2H-3P7 email : uunet!attcan!john === (416) 756-5221 Compu$erve: 72137,722 ____"Sometimes it just happens...People explode...Natural causes."__________
rick@pavlov.ssctr.bcm.tmc.edu (Richard H. Miller) (08/05/90)
lath@geocub.greco-prog.fr (Laurent Lathieyre) writes: > Alike, did some Trojan horses be discovered in some >operating systems ? I wonder if operating systems shouldn't >preferably be delivered in source form rather than in >compiled form... A nice thought, but very impratical for the following reasons: 1) Many users of PC level products just want to load their systems and go. To require them to compile and build their O/S would effectively eleminate their ability to install the systems themselve. Thus a PC "expert" would come in and do it. This could also lead to even more problems since this person COULD insert whatever was desired and the user would probable not know the difference. 2) The amount of time and effort to build an O/S cna be very long, especially when one moves into the mini and mainframe arena. It takes almost 24 hours of wall time to build OS-1100 for Unisys machines. I don't even want to think how long it would take to compile and build MVS from source. 3) When you release source and the tools to build the O/S, local code WILL creep into the O/S. Maintenance and upgrades become a royal pain, especially when no one documents what they did. ["I know I will remember what I did two years from now and why when we have to upgrade"]. 4) O/S source is a trade secret for many vendors. (As one vendor found out going against IBM) - -- Richard H. Miller Email: rick@bcm.tmc.edu Asst. Dir. for Technical Support Voice: (713)798-3532 Baylor College of Medicine US Mail: One Baylor Plaza, 302H Houston, Texas 77030