From: CSBVAX::CSBVAX::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 11-FEB-1989 01:30 To: MRGATE::"ARISIA::EVERHART" Subj: re: Alert against Possible VMS Virus/Trojan Horse Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Fri, 10 FEB 89 15:52:29 PDT Received: from Venus.YCC.Yale.Edu by KL.SRI.COM with TCP; Fri, 10 Feb 89 15:36:26 PST Date: Fri, 10 Feb 89 18:39 EST From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)" Subject: re: Alert against Possible VMS Virus/Trojan Horse To: labovitz%etd1.dnet@wpafb-avlab.ARPA, INFO-VAX@KL.SRI.COM, VIRUS-L@LEHIIBM1.BITNET X-VMS-To: IN%"labovitz%etd1.dnet@wpafb-avlab.ARPA",INFOVAX,IN%"VIRUS-L@LEHIIBM1.BITNET" I'm including more text than I normally do because of the nature of this message. [LT Stuart L Labovitz reports:] I am forwarding the following message, in full, from the VALERT virus alert mailing list. I do not know if this is a valid message, or even if such a trojan could be constructed, but definitely want to pass the warning along to all the Info-Vaxers out there. Please send copies of any comments on this warning to the original author (address at the end of the message), as to myself. I will forward any comments I receive to the Virus-L mailing list at Lehigh University (VIRUS-L@LEHIIBM1.BITNET, moderator is Ken Van Wyk, LUKEN@LEHIIBM1.BITNET or LUKEN@SPOT.CC.LEHIGH.EDU). ================ORIGINAL MESSAGE FOLLOWS============================== The following was posted on our local bulletin board, so we're definitely getting into third- and fourth-hand information here. This is really just a Trojan Horse rather than a virus, but I thought I'd pass it along. ------------------------ Folks, What I am about to relate was triggered by a second-hand rumor, but it reflects a very valid security concern and is something that we may wish to deal with immediately. 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. At the risk of being alarmist, I suggest that we immediately inform our users to be suspicious of any messages of unknown origin. Information is limited and we do not know if it will appear or how to recognize it if it does. If I get more information I'll send it along. ------------------------- I have a few questions for anyone who knows VTxxx terminals: 1) Is it possible to do this on a VT1xx or VT2xx terminal? I know it is possible to cause the answerback message to be echoed, but I don't know of a command to load the answerback message from the host; it is possible to load a definition into a (shifted) function key, but that requires the user to press the key; I know of no command to echo the contents of the screen back to the host as input. 2) If it is possible, is there a setup option that will immunize the terminal from this particular disease? This sort of attack has been known for years, especially on forms-oriented terminals, but I had believed that my terminal (a VT220) was not subject to this particular vulnerability. Has anyone else heard about this? Has anyone actually SEEN this beast? If you notice it ahead of time, it should be simple to determine what it does and where it came from (unless it's self-perpetuating like the XMAS EXEC -- but there's no easy list of destinations on VAX/VMS). Gary Ansok or P.S. The lack of a way for this thing to hide its origins from anyone who is looking for it makes me wonder if it is real. But I'll be looking over my incoming mail extra carefully for a few weeks anyway. -- Gary =============END OF ORIGINAL MESSAGE================================== 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, for several reasons: 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. It is theoretically possible, I suppose, that some non-ANSI- compatible terminals may be triggered by some sequence of characters that MAIL considers to be "just text", and so might be vulnerable. But I doubt it. 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". c) No mainline DEC terminal allows you to set the answerback message from the host; it can be changed only in SETUP. (And, no, you can't put the terminal into SETUP from the host.) I know the people who designed every DEC terminal since the VT100, and worked on some of the designs, so I'm 100% certain of this. I include the "mainline" qualifier only because there are so many variations, mainly in international markets, which I know nothing about that I can't make an absolute statement. But I would be very surprised if you could do this on ANY DEC ter- minal. 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). Again, I can speak only of "mainline" DEC terminals. One com- mon request is for the ability to have the UNSHIFTED function keys send the UDK sequences. This has never been done in a mainline DEC terminal; one reason is that it could make a user who doesn't normally use UDK's, but DOES use the function keys, vulnerable. Of course, if the choice of operational mode could be made only in SETUP, you'd still be safe. e) Several DEC terminals support block mode. I believe the VT131 and VT132 and the VT330 and VT340 are the only "mainline" terminals that do so. It MAY be possible to force such a terminal to send back data from the screen, in which case an attack of the nature being discussed here is possible. I'm not absolutely certain, and the situation may be different on the different models. What it comes down to is this: There is no defined sequence which tells the terminal to send data from the screen to the host; rather, such action is, in the documented cases, always initiated by the user typing something, usually ENTER. However, it is possible to operate these terminals in a mode in which ENTER sends a "data ready for you" message, and the host then replies with "OK, send it". What isn't clear is what happens, in all circumstances, if the host sends "OK, send it" when the terminal hasn't indi- cated it has data. Probably nothing, but I can't guarantee that. In any case, on the VT330 and VT340, there is a SETUP option which disables block mode, so this becomes a non-issue. f) ReGIS supports ways for the host to do some pretty complex things on the terminal, and get reports back. It MAY be possible to use ReGIS for this kind of attack. I've never seen a defini- tive analysis either way. g) The VT220 (and VT320) support neither block mode nor ReGIS, and as far as I know are not vulnerable to this kind of attack. (The same goes for most VT100-generation terminals. Some of them had firmware bugs which allowed "letter bombs" to disrupt the terminal, but none of those do anything permanent, or harm the connected system.) h) The above applies ONLY to DEC terminals. If you have a "DEC-com- patible", you have to read its documentation very, very care- fully to determine if you are safe. Some compatibles try to "improve" on the original terminals by adding such "over- looked" features as escape sequences that let you program the answerback message from the host, or read arbitrary stuff from the screen. Such "improvements" could leave you wide open. 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