Date: Sun, 11 Mar 90 02:15:05 PST Subject: Security Digest V2 #9 Security Digest Volume 2 Issue 9 subject(s): Proper email addressing of postings * Annex info Welcome Banners interesting usenet news groups Contest announcement group ids group ids crypt/CBW crypt/CBW crypt/CBW * Xterm Security hole [X Windows Ver. 11, Release 3 and 4] The unix security mailing list is by invitation only and contains sensitive material which SHOULD NOT BE REVEALED to non-members. DO NOT PUT ANY LIST CONTENTS IN LOCATIONS ACCESSABLE TO NON-MEMBERS. If you must keep copies on-line, please encrypt them at the very least. PLEASE POST TO: security@uninet.cpd.com PLEASE SEND EMERGENCY ALERTS TO: security-emergency@uninet.cpd.com PLEASE SEND REQUESTS TO: security-request@uninet.cpd.com Postings that describe security holes/fixes have a * in their subject. ------------------------------------------------------------------------ Date: Sun, 4 Mar 90 23:36:49 PST From: neil (Neil Gorsuch) Subject: Proper email addressing of postings [ Please don't try to second-guess the posting addresses. The proper addresses are "security@uninet.cpd.com" for normal postings and "security-emergency@uninet.cpd.com" for emergency postings. The emergency postings go out to the whole list as a mail expander/reflector without any intervention on my part and with no delay (immediately). When you send stuff to ...-sendit there is no record kept in the official archives, only in the logs on all entry/exit points - neil ] ------------------------------------------------------------------------ Date: Tue, 06 Mar 90 22:24:57 EST From: Gene Spafford Subject: * Annex info A few sites on the Internet are running Annex boxes that allow callers to telnet out to anywhere in the world. This may appear to be convenient, but it also allows crackers to dial in and attack systems without leaving any logging information that would allow them to be traced. Thus, having an Annex box (or other terminal server) with unrestricted conection privileges should be viewed as "rude" in our shared environment, as well as unwise. If some major site gets hacked into through such a server, it might also be considered by corporate lawyers to be "actionable" -- i.e., civil lawsuits. On the theory that people out there don't know how to restrict their Annex boxes, I asked one of our site gurus, Richard Watterson, to provide an explanation of how we keep our Annex traffic "at home". Take it away, Richard: >> If you have a newer version of the Annex erpcd code (like what they >> ship with the annexII's), you may restrict annex users to certain >> networks. You can do this by setting connect_security to Y on the >> annex, and setting up the proper entries in the file >> /etc/acp_restrict. Normally you would want to restrict access to >> only those hosts on local network(s). Here is an example acp_restrict >> file that restricts annex annex01 to accessing only hosts on the >> 128.10 and 128.211 networks: >> >> annex01~ 128.10.*, 128.211.* >> *:* >> >> or to restrict all annexes on network 128.10 to accessing only 128.10 >> and 128.211 networks: >> >> 128.10.*~ 128.10.*, 128.211.* >> *:* >> >> The first line reads "all annexes on the 128.10 network (* is wildcard) >> can access (~ means allowed access to) all hosts on networks 128.10 >> and 128.211". The second reads no annex anywhere can access (: means >> don't allow access to what follows) anything anywhere. This second >> line will be consulted only if the request is not matched on the first >> line. >> >> If you have an old version of the annex code then you will have to >> change the source as it did not support wildcards in the >> /etc/acp_restrict file. Here is the segment that needs to be changed: >> ---------------------------------------------------------------------------- >> /* Check whether or not this is a restricted host for this Annex */ >> >> #ifdef PURDUE_CS >> /* Just verify net */ >> if (((rinet & ntohl(0xffff0000)) == ntohl(0x800a0000)) || >> /*include hosts on this network ^^^^^^^^ 128.10*/ >> (rinet & ntohl(0xffff0000)) == ntohl(0x80d30000)) >> /* and this network ^^^^^^^^ 128.211 */ >> #else /* !PURDUE_CS */ >> if(available(linet, rinet)) /* if OK, authorize and log */ >> #endif /* ! PURDUE_CS */ >> { >> (void)annex_to_net_authorize(Acp, REQ_GRANTED); >> log_message(linet, logid, port, service, EVENT_LOGIN, String); >> } >> else /* else reject and log */ >> { >> #ifdef PURDUE_CS >> outputstring(Acp,"\nSorry, only CS hosts allowed\n\n"); >> #endif /* PURDUE_CS */ >> (void)annex_to_net_authorize(Acp, REQ_DENIED); >> log_message(linet, logid, port, service, EVENT_REJECT, String); >> } >> >> /* terminate (exit()) this session */ >> ---------------------------------------------------------------------------- >> >> The PURDUE_CS ifdef delimits the new code. >> Questions about this can be directed to rlw@cs.purdue.edu ------------------------------------------------------------------------ Date: 2 Mar 90 21:14:52 GMT From: uunet!NIC.DDN.MIL!SCC Subject: Welcome Banners [ This is from DDN Security Bulletin 90-04 - neil ] COMPUTER SYSTEM "WELCOME" BANNERS 1. The Defense Communications Agency/Data Systems Management Division (DDO) is in the process of fielding a patch to all Defense Data Network (DDN) Terminal Access Controllers (TACs) that will remove the DDN "Welcome" banners. This is being accomplished as a security measure for the following principle reasons: a. To terminate the identification of the system as belonging to the DDN/MILNET, and to terminate the identification of the type of operating system or software in use on the system. All too often intruders stumble by chance upon a MILNET host because the system is identified in the banner as being "defense" and/or "For Official Use Only". Intruders can also use software or operating system information from the banner to facilitate an intrusion. Therefore, it is best not to identify a system at all in its banner. b. A court recently threw out a suit against a computer system intruder because the logon prompt was preceded with "Welcome to...". 2. Request Host Administrators and other addressees, in favor of tighter security, take an active role in getting their commands/units/organizations to change existing logon banners to make certain that the identity of their data systems is not displayed, and to halt the use of "Welcome". ------------------------------------------------------------------------ Date: Mon, 5 Mar 90 09:17:45 PST From: neil (Neil Gorsuch) Subject: interesting usenet news groups [ There are currently some very interesting discussions in the usenet news group comp.dcom.telecom about hackers and justice department seizures. Check it out 8-). - neil ] ------------------------------------------------------------------------ Date: Tue, 06 Mar 90 15:49:12 EST From: Gene Spafford Subject: Contest announcement The National Center for Computer Crime Data notes with interest the considerable controversy engendered by the trial and guilty verdict in the case of Robert T. Morris. In order to expand and focus the conversation, we announce the "If I were the Robert Morris case judge" essay contest. We will award $100 to the best essay of 250 words or less suggesting the appropriate sentence for Mr. Morris. Security Magazine has agreed to publish the winning essay in its May issue. Contestants need not be familiar with the federal guidelines for sentencing, but should assume, for the purpose of their essay, that the judge can impose any sanctions he or she thinks reasonable. All essays must be received by the National Center for Computer Crime Data, 1222-B 17th Avenue, Santa Cruz, CA, 95062 by March 28, 1990. J.J. Buck BloomBecker, Esq. Director [The real sentencing for Mr. Morris will be May 4. I am not affiliated in any way with the NCCCD --spaf] ------------------------------------------------------------------------ Date: Thu, 08 Mar 90 21:52:26 -0500 From: uunet!cis.udel.edu!pezely Subject: group ids There was a lot of messages about PC NFS security problems in the last Security Digest. I don't know about PC NFS, but here's a problem along similar lines. One problem I've seen on a Sun client workstation is having group id mismatches with what the client says and what the server says. On one client, the two group id's of `staff' and `other' were switched. I was a member of the `staff' group, but not the `other' group. Suddenly, I could access stuff from the client which I may not have been supposed to see and couldn't normally see from the server. It didn't matter since I had root priv's anyway, but you get the idea. My point is, what's to stop a client from playing around with /etc/group ? I don't know how far this could go, but is a potential problem. This was on a Sparcstation running SunOS 4.0.3 with the 3/180 server running the same version. ------------------------------------------------------------------------ Date: Sat, 10 Mar 90 03:31:24 EST From: Seth Robertson Subject: group ids >My point is, what's to stop a client from playing around with /etc/group ? >I don't know how far this could go, but is a potential problem. There is nothing to stop a client. You should probably make sure that people cannot become root on the clients to change things, but what I do for /etc/passwd, /etc/group and a few other files is to keep a generic client version in a directory on my server and use rdist or rcp to distribute them out to the various clients. NOTE: If you do this, be very, very sure that you do not accidently distribute the generic password file to the server. It might be slightly annoying if you had to manually regenerate your entire password file :-) ------------------------------------------------------------------------ Date: Tue, 6 Mar 90 13:32:54 EST From: "Scott E. Schwartz" Subject: crypt/CBW | 1) Hackers know about this list and have placed a "premium" on getting | copies of the list mailings. If you have old copies on disk, encrypt | them so that if someone does break in, they can't get them. Unfortunately, they also know about the "Code Breakers Workbench", available by ftp from uunet. The unix crypt command is very very very easy to break, especially given lengthy traffic with standard headers like this list has. It really is time for a DES based crypt(1). (Ironically, we recently caught some intruders and had occasion to use cbw to decrypt files that _they_ thought were safely encoded. It cuts both ways, I guess.) ------------------------------------------------------------------------ Date: 5 Mar 90 13:55:06 PST (Mon) From: elroy!zorch.SF-Bay.ORG!scott (Scott Hazen Mueller) Subject: crypt/CBW I was always under the impression that what CBW did was iterate to a decryption by relying on typical frequency counts and presenting the user with sample output for various keys. If this is the case, then would it not be true that encrypting compressed text would be a much stronger protection than simple encryption of straight text? not to mention the saved disk space.. ------------------------------------------------------------------------ Date: Mon, 05 Mar 90 09:04:01 -0500 From: Matt Bishop Subject: crypt/CBW If anyone wants it, there is an implementation of DES with all four modes recommended in FIPS 81 (ECB, CBC, CFB, OFB) available for anonymous ftp from bear.dartmouth.edu (login anonymous password your-id). Source is ~ftp/pub/cdes.c and the manual page is ~ftp/pub/cdes.1. THIS DOES NOT BREAK ANY CIPHERS -- IT SIMPLY IMPLEMENTS THEM!!!!!! One fudge: CFB and OFB require the size of the parameter to be a multiple of 8. This is because it's hard to do 5-bit CFB, and I wrote this thing as a one-day hack when some $%^@&$* broke into our machine. If anyone wants to add that, please send me the mods! (As Scott pointed out, crypt(1) just doesn't cut it.) A warning: no warranty, etc. So check the encryption before tossing the plaintext. If you find a problem, let me know; I don't know of any, but .... Also, if you lose your key, you're on your own; the NSA may -- MAY -- know how to recover a key from a known plaintext, or ciphertext only, attack, but I sure don't! ------------------------------------------------------------------------ Date: Fri, 9 Mar 90 15:49:28 -0500 From: uunet!wayback.cs.cornell.edu!parmelee (Larry Parmelee) Subject: * Xterm Security hole [X Windows Ver. 11, Release 3 and 4] [ This is the last message because of it's length, if you don't use X windows, you're done with this digest - neil ] The xterm terminal emulator provided as part of X windows has a rather bad security hole. This problem exists in X version 11, both releases 3 and 4, and possibly other versions as well. This problem was originally found by Hakon W Lie , whose report found its way to me via a mutual acquaintance. I have worked out a source-code patch to close the hole in X11 release 4, a similiar patch should work for release 3. To the best of my knowledge, this bug has not been used in a malicious or harmful way by anyone, but the potential is frightening. The xterm emulator has a feature that allows a user to keep a logfile of what's been typed in the xterm window. The feature also allows a command to be specified as the logfile, in which case what would normally be written to the logfile is instead written to the input of the given command (standard UNIX-style pipeline setup). The security hole arises because the xterm emulator defines some escape sequences which can be sent to the xterm window to control the logging feature: turning logging on or off and changing the logfile name. These escape sequences could conceivably be embedded in a mail message, and the message sent to a victim. If the victim displays the message in an xterm window (for example by running mail from within an xterm window), the escape sequences will effectively cause the victim to run whatever commands the attacker wishes. The victim will probably be unaware of the attack, since the escape sequences are not displayed in the xterm window. The following is a test file; the control codes that would make let this make use of the bug have been changed into harmless characters, namely the ascii "esc" code "^[" has been replaced by "$" and the ascii "bel" code "^G" has been replaced by "%". -------File: xterm.test1 ---- Cut here----- Set log file name $]46;/tmp/foobar% Turn Logging ON $[?46h% Well,. what now? testing one two three Turn Logging Off $[?46l% set a new logfile (a command, actually) $]46;|/bin/mail `whoami` < /tmp/foobar% Turn logging on, i.e. execute that command! $[?46h% Turn Logging Off $[?46l% set logfile name back to something harmless $]46;XtermLog.a1% -------File: xterm.test1 ---- END If you're on a UNIX system, you can test your xterm by saving the above text in a file and using the "tr" command to restore the proper control codes: tr '$%' '\033\007' < xterm.test1 If the above command is run in an xterm window, the effect will be to set the log file name to "/tmp/foobar", then turn logging on. The next few lines will be written to "/tmp/foobar", then logging is turned off. Then, a new log file name is given: since the "filename" begins with a vertical bar "|", it's actually a command. When logging is again turned on, the command "/bin/mail `whoami` < /tmp/foobar" will be executed, which will have the effect of mailing the "/tmp/foobar" file to the current user. Logging is then turned off and the logfile name reset to something harmless, so that turning logging on again at some future time will have no unexpected effect. The following patch closes the hole by disabling the xterm code that interprets the escape sequences dealing with the logging feature. It does this by enclosing the code in "#ifdef " "#endif" pairs. You may wish to actually delete the enclosed code, or use a different undefined symbol name, especially if you keep the X sources in publically accessable areas. It's probably not a good idea to give wandering eyes any unnecessary hints. This patch also adds a length check to prevent overflowing a buffer when interpreting escape sequences to change the title bar name or the Icon name on the xterm window. *** /tmp/,RCSt1a16140 Fri Mar 9 13:27:25 1990 --- mit/clients/xterm/charproc.c Wed Mar 7 11:36:22 1990 *************** *** 1488,1493 **** --- 1488,1494 ---- (*func)(&term->flags, REVERSEWRAP); update_reversewrap(); break; + #ifdef SecurityHole case 46: /* logging */ if(func == bitset) StartLog(screen); *************** *** 1494,1499 **** --- 1495,1501 ---- else CloseLog(screen); break; + #endif case 47: /* alternate buffer */ if(func == bitset) ToAlternate(screen); *************** *** 1567,1575 **** --- 1569,1579 ---- case 45: /* reverse wraparound */ screen->save_modes[13] = term->flags & REVERSEWRAP; break; + #ifdef SecurityHole case 46: /* logging */ screen->save_modes[14] = screen->logging; break; + #endif case 47: /* alternate buffer */ screen->save_modes[15] = screen->alternate; break; *************** *** 1686,1691 **** --- 1690,1696 ---- term->flags |= screen->save_modes[13] & REVERSEWRAP; update_reversewrap(); break; + #ifdef SecurityHole case 46: /* logging */ if(screen->save_modes[14]) StartLog(screen); *************** *** 1693,1698 **** --- 1698,1704 ---- CloseLog(screen); /* update_logging done by StartLog and CloseLog */ break; + #endif case 47: /* alternate buffer */ if(screen->save_modes[15]) ToAlternate(screen); *** /tmp/,RCSt1a16143 Fri Mar 9 13:27:51 1990 --- mit/clients/xterm/misc.c Wed Mar 7 13:16:29 1990 *************** *** 531,537 **** mode = 10 * mode + (c - '0'); if (c != ';') okay = False; cp = buf; ! while(isprint((c = (*func)()) & 0x7f)) *cp++ = c; if (c != 7) okay = False; *cp = 0; --- 531,537 ---- mode = 10 * mode + (c - '0'); if (c != ';') okay = False; cp = buf; ! while(isprint((c = (*func)()) & 0x7f) && cp < &buf[sizeof buf - 1]) *cp++ = c; if (c != 7) okay = False; *cp = 0; *************** *** 549,554 **** --- 549,555 ---- Changetitle(buf); break; + #ifdef SecurityHole case 46: /* new log file */ if((cp = malloc((unsigned)strlen(buf) + 1)) == NULL) break; *************** *** 557,562 **** --- 558,564 ---- free(screen->logfile); screen->logfile = cp; break; + #endif case 50: SetVTFont (fontMenu_fontescape, True, buf, NULL); ------------------------------------------------------------------------ End of Security Digest Volume 2 Issue 9 **********************