VIRUS-L Digest Tuesday, 14 Feb 1989 Volume 2 : Issue 47 Today's Topics: Valetine's Day trojan horse (VAX/VMS) Re: Valentine's Day VTxxx trojan horse mail message (VAX/VMS) VIRUS-L LISTSERV files now available via anonymous FTP --------------------------------------------------------------------------- Date: Tue, 14 Feb 89 11:21 EST From: Cincinnati Bengals. Subject: Valetine's Day trojan horse (VAX/VMS) This rumor is an obvious attempt to capatilize on the virus hysteria and cause people to be afraid to do anything on the computer. I'd be willing to bet money that it's impossible that when a mail message is read, the message causes files to be deleted. Either the rumor was improperly relayed, or someone is trying to cause fear in VAX/VMS users all over by spreading an absolutely absurd rumor. Tom Kummer ------------------------------ Date: Tue, 14 Feb 89 13:10:16 est From: Stuart Labovitz Subject: Re: Valentine's Day VTxxx trojan horse mail message (VAX/VMS) In order to get some "expert" opinions on this virus/trojan alert, I forwarded a copy of the VALERT message to the Info-VAX mailing list (Info-VAX@KL.SRI.COM). Jerry Leichter has responded directly to VIRUS-L, but appended below is another response (refering to Jerry's message) from Stephen Dowdy. I will forward any other relevant responses on to VIRUS-L, as well. LT Stuart L Labovitz USAF Electronic Technology Laboratory arpa: Labovitz%Etd2.decnet@Wpafb-avlab.arpa I bark, therefore I am. --Descarte's dog = = = = = = = = = = message from Stephen Dowdy follows = = = = = = = = = = = LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ") writes: ] The rumor is that a Valentine's Day message has been prepared ] that has the potential for causing lots of personal (and operational) ] havoc. Any user who reads this message, on a VAX system, using a ] standard DEC terminal, will have all of his files deleted. This ] little nastygram is rumored to also put a sweet message and heart on ] the screen while doing its dirty work. A nice touch. ] ]This "rumor" is a wonderful example of a kind of "denial of service" ]virus. It infects the "wetware" of susceptible users. Different ]forms of this rumor have been floating around for several days now; ]they've been passed around internally to DEC, for example. ] ]There is NO truth behind this rumor. What it describes is ]impossible, ... (there is a lot of truth to the concept. DO NOT BLOW THIS OFF AS IMPOSSIBLE) ] a) The VMS MAIL program filters out escape and control sequences ] when presenting mail to the user. Even if there were a ] sequence which could cause damage, it can never reach the ] terminal as long as you use only READ to look at the message. VMS Mail did not always filter out control characters. I remember reading (in 3.7 i believe) a mail file of the famous Champagne Glass Line drawing set animation. ] b) A message COULD suggest that you type EXTRACT TT:, which would ] copy the message unfiltered to your terminal. This trick ] is often used to send, say, ReGIS pictures through the mail. ] Obviously, this is a deliberate action - you have to be wil- ] ling to do it. Just on general principles, you should NOT do ] this with a message from someone you don't know. ] ] A message could also tell you: Type EXTRACT FOO.COM, CTRL/Z, ] and @FOO. If you go ahead and do that, you will create and ] execute a command file which could do anything at all. ] ] Then again, the message COULD tell you "Shoot yourself in the ] head". Then again, the people who are hit by this form of trojan horse are not generally computer literate. If the message does say EXTRACT/NOHEAD FOO.COM the user *WILL* do it. ] d) UDK's (User Defined Keys) are a slightly different story. You can ] load them from the host but: ] ] 1. It is impossible for the host to force the terminal to ] send the contents of a UDK - you must deliberately ] type SHIFT with a function key to get the value sent. ] ] 2. When you load UDK's, you may ask the terminal to "lock" ] them. Once the UDK's are locked, any further attempts ] load them are ignored. Nothing the host sends can ] unlock the UDK's - it can be done only from SETUP or ] by power-cycling the terminal. ] ] If you don't use UDK's, (1) should protect you. If you DO use ] UDK's, (2) can protect you (though you have to make sure you ] lock the definitions). Ah, but again, the kind of user who falls for this type of trojan horse is not literate enough to know these things. It doesn't matter how many ways there are to divert mal-intented individuals, the common user is not going to use them. (and *someone* will have to restore their files, or the OS if the person has privs) ] In any case, on the VT330 and VT340, there is a SETUP option ] which disables block mode, so this becomes a non-issue. (once again... Joe User may not even know how to use SETUP.) ] I have no particular compatibles in mind here - there may not ] actually BE any which have made this kind of change. But to ] be safe, you have to be wary. I'd be ESPECIALLY wary of ter- ] minal emulation programs running on PC's - they often have the ] opportunity to provide all sorts of nifty, but dangerous, ] features which the hardware manufacturers find too expensive ] to include. ] -- Jerry Back in the days of 4.2 BSD Unix, when the ttys weren't protected by group ownership 'ttys', i wrote a program exploiting a "feature" of the Televideo 912/910 that allowed one to write to a user's terminal (in BSD, if they had MESG Y), and have the terminal send that command back. Needless to say, any person with mesg y, and root on a tvi was asking the system to go down. (i never use any of these things for malicious purposes, just to get the point across to people that there are *MANY* non-obvious ways to break security). Though, i agree that this reported trojan horse is probably not real, in it's reported form, it is *VERY* real as a general security issue. If i download your keys with a string, and you press that key, you're are in trouble. And no amount of convincing is going to make non-knowledgable users do what they should (lock keys, reset the terminal before logging in...; heck, i don't even do these things, since it is such a pain) Take a word of caution from the message. It is possible to do these things. (and though i would really like to make my process name in double wide characters for show users, i understand DECs approach to dropping out control characters, it is probably the correct approach in dealing with overly-"smart" terminals) - --stephen - -- $!####################################################################### $! stephen dowdy (UNM CIRT) Albuquerque, New Mexico, 87131 (505) 277-8044 $! Usenet: {convex,ucbvax,gatech,csu-cs,anl-mcs}!unmvax!charon!sdowdy $! BITNET: sdowdy@unmb $! Internet: sdowdy@charon.UNM.EDU $! Team SPAM in '87! SPAAAAAAAAAAAAAAAAAAAAMMMMMMM! $!####################################################################### = = = = = = = = = = message from Stephen Dowdy ends = = = = = = = = = = = = ------------------------------ Date: Tue, 14 Feb 89 14:06:35 est From: ubu!luken@lehi3b15.csee.lehigh.edu Subject: VIRUS-L LISTSERV files now available via anonymous FTP Internet (including ARPAnet, MILNET, NSFNET, etc.) users can now access the VIRUS-L archives and backlogs via anonymous FTP to IBM1.CC.LEHIGH.EDU. Once logged in, issue a CD (or CWD) command to connect to either VIRUS-L (for the log files) or VIRUS-P (for the archive programs). At that point, the standard GET command will retrieve files, and the DIR command will list available files. The anonymous FTP is very new on our VM/CMS machine, so please report any problems to me. We currently know of some quirks when FTPing from Sun workstations - it takes several commands before anything happens. It has successfully been tested from other machines, however, including VAX/VMS (CMU TCP/IP) and Zenith PCs (NCSA TCP/IP). I hope that this adds to the functionality of the forum somewhat, even though loading files onto the LISTSERV filelist is still as difficult as ever... Ken van Wyk ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253