Date: Fri, 30 Mar 90 02:17:48 PST Subject: Security Digest V2 #10 Security Digest Volume 2 Issue 10 subject(s): POSSIBLE LIST CHANGES Internet Intruder Warning Re: Annex boxes Re: Annex boxes Re: Annex Boxes Re: Annex Boxes annex lattelnet break-ins SunOS pty's (the real problem) (long) answering machines vs. call back modems How to make answering machines deliver ransom messages SunOS 4.0.3 UUCICO problems, WIDE open Re: CBW crypt/CBW Re: crypt/CBW crackers and passwords Re: More hacker signs - probably the same ones Fwd: archiving security password checking program wanted Possible problem with Intergraph Soft-PC Potential problem with Intergraph PC Emulator I just had the oddest phone call... YP passwd bugs - SunOS 4.0.3 Re: * Xterm Security hole [X Windows Ver. 11, Release 3 and 4] Re: Xterm Security hole [X Windows Ver. 11, Release 3 and 4] fixes/6 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: Fri, 30 Mar 90 00:55:58 PST From: neil (Neil Gorsuch) Subject: POSSIBLE LIST CHANGES [ Because of certain recent events, I am considering some major changes to the security list, including a possible paring down of the list membership. Also, uninet.cpd.com itself will join the internet as soon as I have time to hook it up (the hardware and leased line have been sitting around for over a month now). That will also play a part in the changes I am contemplating. - neil ] ------------------------------------------------------------------------ Date: Mon, 19 Mar 90 15:42:52 EST From: "J. Paul Holbrook" Subject: Internet Intruder Warning CERT Advisory March 19, 1990 Internet Intruder Warning There have been a number of media reports stemming from a March 19 New York Times article entitled 'Computer System Intruder Plucks Passwords and Avoids Detection.' The article referred to a program that attempts to get into computers around the Internet. At this point, the Computer Emergency Response Team Coordination Center (CERT/CC) does not have hard evidence that there is such a program. What we have seen are several persistent attempts on systems using known security vulnerabilities. All of these vulnerabilities have been previously reported. Some national news agencies have referred to a 'virus' on the Internet; the information we have now indicates that this is NOT true. What we have seen and can confirm is an intruder making persistent attempts to get into Internet systems. It is possible that a program may be discovered. However, all the techniques used in these attempts have also been used, in the past, by intruders probing systems manually. As of the morning of March 19, we know of several systems that have been broken into and several dozen more attempts made on Thursday and Friday, March 15 and 16. Systems administrators should be aware that many systems around the Internet may have these vulnerabilities, and intruders know how to exploit them. To avoid security breaches in the future, we recommend that all system administrators check for the kinds of problems noted in this message. The rest of this advisory describes problems with system configurations that we have seen intruders using. In particular, the intruders attempted to exploit problems in Berkeley BSD derived UNIX systems and have attacked DEC VMS systems. In the advisory below, points 1 through 12 deal with Unix, points 13 and 14 deal with the VMS attacks. If you have questions about a particular problem, please get in touch with your vendor. The CERT makes copies of past advisories available via anonymous FTP (see the end of this message). Administrators may wish to review these as well. We've had reports of intruders attempting to exploit the following areas: 1) Use TFTP (Trivial File Transfer Protocol) to steal password files. To test your system for this vulnerability, connect to your system using TFTP and try 'get /etc/motd'. If you can do this, anyone else can get your password file as well. To avoid this problem, disable tftpd. In conjunction with this, encourage your users to choose passwords that are difficult to guess (e.g. words that are not contained in any dictionary of words of any language; no proper nouns, including names of "famous" real or imaginary characters; no acronyms that are common to computer professionals; no simple variations of first or last names, etc.) Furthermore, inform your users not to leave any clear text username/password information in files on any system. If an intruder can get a password file, he/she will usually take it to another machine and run password guessing programs on it. These programs involve large dictionary searches and run quickly even on slow machines. The experience of many sites is that most systems that do not put any controls on the types of passwords used probably have at least one password that can be guessed. 2) Exploit accounts without passwords or known passwords (accounts with vendor supplied default passwords are favorites). Also uses finger to get account names and then tries simple passwords. Scan your password file for extra UID 0 accounts, accounts with no password, or new entries in the password file. Always change vendor supplied default passwords when you install new system software. 3) Exploit holes in sendmail. Make sure you are running the latest sendmail from your vendor. BSD 5.61 fixes all known holes that the intruder is using. 4) Exploit bugs in old versions of FTP; exploit mis-configured anonymous FTP Make sure you are running the most recent version of FTP which is the Berkeley version 4.163 of Nov. 8 1988. Check with your vendor for information on configuration upgrades. Also check your anonymous FTP configuration. It is important to follow the instructions provided with the operating system to properly configure the files available through anonymous ftp (e.g., file permissions, ownership, group, etc.). Note especially that you should not use your system's standard password file as the password file for FTP. 5) Exploit the fingerd hole used by the Morris Internet worm. Make sure you're running a recent version of finger. Numerous Berkeley BSD derived versions of UNIX were vulnerable. Some other things to check for: 6) Check user's .rhosts files and the /etc/hosts.equiv files for systems outside your domain. Make sure all hosts in these files are authorized and that the files are not world-writable. 7) Examine all the files that are run by cron and at. We've seen intruders leave back doors in files run from cron or submitted to at. These techniques can let the intruder back on the system even after you've kicked him/her off. Also, verify that all files/programs referenced (directly or indirectly) by the cron and at jobs, and the job files themselves, are not world-writable. 8) If your machine supports uucp, check the L.cmds file to see if they've added extra commands and that it is owned by root (not by uucp!) and world-readable. Also, the L.sys file should not be world-readable or world-writable. 9) Examine the /usr/lib/aliases (mail alias) file for unauthorized entries. Some alias files include an alias named 'uudecode'; if this alias exists on your system, and you are not explicitly using it, then it should be removed. 10) Look for hidden files (files that start with a period and are normally not shown by ls) with odd names and/or setuid capabilities, as these can be used to "hide" information or privileged (setuid root) programs, including /bin/sh. Names such as '.. ' (dot dot space space), '...', and .xx have been used, as have ordinary looking names such as '.mail'. Places to look include especially /tmp, /usr/tmp, and hidden directories (frequently within users' home directories). 11) Check the integrity of critical system programs such as su, login, and telnet. Use a known, good copy of the program, such as the original distribution media and compare it with the program you are running. 12) Older versions of systems often have security vulnerabilities that are well known to intruders. One of the best defenses against problems is to upgrade to the latest version of your vendor's system. VMS SYSTEM ATTACKS: 13) The intruder exploits system default passwords that have not been changed since installation. Make sure to change all default passwords when the software is installed. The intruder also guesses simple user passwords. See point 1 above for suggestions on choosing good passwords. 14) If the intruder gets into a system, often the programs loginout.exe and show.exe are modified. Check these programs against the files found in your distribution media. If you believe that your system has been compromised, contact CERT via telephone or e-mail. J. Paul Holbrook Computer Emergency Response Team (CERT) Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Internet E-mail: cert@cert.sei.cmu.edu Telephone: 412-268-7090 24-hour hotline: CERT personnel answer 7:30a.m.-6:00p.m. EST, on call for emergencies other hours. Past advisories and other information are available for anonymous ftp from cert.sei.cmu.edu (128.237.253.5). ------------------------------------------------------------------------ Date: Sun, 11 Mar 90 21:16:02 -0800 From: uunet!ucsd.edu!brian (Brian Kantor) Subject: Re: Annex boxes In the anonymous FTP area of UCSD.EDU you will find a set of diffs to apply to the Xylogics/Annex 4.1 erpcd source that makes for a little bit more flexible security control policy. What we have done is add a third case to the security switch. The original software allows one to deny or allow access based on addresses (some or all of which may be wildcarded). We have added a third case that demands a login and password before allowing access. That way we allow dial-up access to many of our campus hosts, deny dial-up access to other hosts and certain networks, and demand that the user supply a login and password before he may gain access to the rest. The means that all Internet access from UCSD is (in theory, anyway) validated: a user cannot access the internet without having logged on either to a campus host which has access, or logged on to the Annex. It also saves us from having to issue dial-in logins and passwords for every student with a modem - as they can access the couple of dozen machines on which classwork is done directly. For a quick hack it's quite acceptable. The Annex code uses the same password mechanism as normal Unix systems do, which allows us to use all of the normal Unix tools to manage the authorization file, and which, by the same token, opens us up to the same attacks. I think it's good enough, at least for now. ------------------------------------------------------------------------ Date: Mon, 12 Mar 90 19:46:32 PST From: uunet!oce.orst.edu!pvo (Paul O'Neill) Subject: Re: Annex boxes Equally disturbing is the ability to telnet *into* an annex from the internet and then back out again. Very useful for someone trying to cover their tracks. This is what the "modified telnet" cracker was doing about 6 months ago. We traced him to our annex, then back to a cisco on the east coast, then ..... "rats, he's logged off already." No accounting records. To catch someone doing this you must be notified immediately of an incoming telnet to your annex (I know of no valid reason to be telneting *into* an annex) and start tracing back immediately. I don't administer our annexes, and don't understand why we can't turn off incoming telnets, but we can't. So I wrote this little perl script. It is run by cron every minute. It sends mail to appropriate people if someone is telneting in, and automatically does the first level of traceback (via `finger' and `rusers'). This data is included in the mail message. (Notice that you don't have to log into an annex and do a "who" command. It's much quicker to just "finger @annex". (So far it's only caught CERT personal!!) ------------------------------------------ #!/usr/bin/perl # fannex # 11 mar 90 # finger annex for incoming internet login # Paul V. O'Neill # Coastal Imaging Lab # OSU, Corvallis, OR 97331 $SEC_HONCHO = 'root@homeck.podunk.edu'; ###### CONFIG FOR YOUR SITE ##### @ANNEXES = ('annex5', 'annex10'); ###### CONFIG FOR YOUR SITE ##### for(@ANNEXES) { @x = split(/\n/, `finger @$_`); $annexid = shift @x; $header = shift @x; $offadd = index($header, 'Address'); $i = 0; for(@x) { $i++; chop; $add = sprintf("%-16s", substr($_, $offadd, 16)); # print "$add\n"; if( $add =~ /\d*\.\d*\.\d*\.\d*/ ) { ########## COMMENT OUT THE NEXT 2 LINES FOR TESTING ############## open(MAIL, "| /usr/ucb/mail -s annex $SEC_HONCHO"); select(MAIL); print "$annexid\n"; print "$header\n"; print "$_\n"; print "$x[$i]\n\n"; do who_fing(); do who_ru(); close(MAIL); } } } sub who_fing { $at = '@'; @users = `finger @$add`; $hostname = `/usr/local/bin/hname $add`; $hostname =~ /= (.*)$/; $host = $1; print "@users\n"; print "$hostname\n"; 1; } sub who_ru { @users2 = `rusers -l $host`; print @users2; } ------------------------------------------------------------------------ Date: Tue, 13 Mar 90 12:54:34 EST From: uunet!cs.purdue.edu!trinkle Subject: Re: Annex Boxes If you are running Annex-UX R4.1 (and possibly earlier versions as well), you only need to set the annex parameter "enable_security" to Y. With security enabled, if you telnet to the annex and then select the "cli" rotary, it will request a username and a password before you are allowed CLI access. Note that this does not restrict access on any of the serial lines (coming IN through the serial line) unless they have one of "cli_security", "connect_security", or "port_server_security" turned on. If you are using a serial line rotary and telnet TO the annex to get access to the serial rotary, there may be some restrictions. We do not use this locally and cannot conveniently test it. ------------------------------------------------------------------------ Date: Thu, 15 Mar 90 18:51:18 PST From: uunet!oce.orst.edu!pvo (Paul O'Neill) Subject: Re: Annex Boxes Yikes!! I haven't gotten so much mail in ages. OK -- Most folks can and do easily lock up annexes to incoming telnets. HOWEVER -- 1) Some folks want or need incoming telnet access and want to run "fannex". 2) If you have been attacked from a poorly administered annex at another sight, you will want to run "fannex" pointing it at *that* annex, not one of your own, to catch the cracker on his next attempt. It has been pointed out to me that fannex requires a very recent version of perl (3.0 patchlevel 12). (patchlevel 15 is current) Here is a version that runs at 3.0 patchlevel 8 and maybe lower: Also -- here is the source to hname. Needed for IP address -> host name resolution and the 'rusers -l' call. This is an extremely handy tool to have on hand. Basically an nslookup reverse-pointer query without all the hairball syntax. Here is a typical mail message from fannex: ----------------------------------------------------------------------- >From root@homeck.podunk.edu Thu Mar 15 18:30:05 1990 To: root@homeck.podunk.edu Subject: annex [badannex@HARVARD.EDU] Port What User Location When Idle Address v1 CLI --- --- 9:29pm 128.193.64.35 [128.193.64.35] Login Name TTY Idle When Where pvo Paul O'Neill co Thu 15:32 128.193.64.35 = sapphire.OCE.ORST.EDU pvo sapphire.OCE:console Mar 15 15:32 -------------------------------------------------------------------- [ ooopps -- busted !! :-) ] -------------------------------------------------------------------------- # This is a shell archive. Remove anything before this line, # then unpack it by saving it in a file and typing "sh file". # # Wrapped by sapphire!pvo on Thu Mar 15 18:36:26 PST 1990 # Contents: fannex hname.c echo x - fannex sed 's/^@//' > "fannex" <<'@//E*O*F fannex//' #!/usr/bin/perl # fannex # 11 mar 90 # finger annex for incoming internet login # Paul V. O'Neill # Coastal Imaging Lab # OSU, Corvallis, OR 97331 # 15 may 90 # indirect the '@' for older perls $SEC_HONCHO = 'root@homeck.podunk.edu'; ###### CONFIG FOR YOUR SITE ##### @@ANNEXES = ('annex5', 'badannex@harvard.edu'); ##### CONFIG FOR YOUR SITE ##### $at = '@'; for(@ANNEXES) { @x = split(/\n/, `finger $at$_`); $annexid = shift @x; $header = shift @x; $offadd = index($header, 'Address'); $i = 0; for(@x) { $i++; chop; $add = sprintf("%-16s", substr($_, $offadd, 16)); # print "$add\n"; if( $add =~ /\d*\.\d*\.\d*\.\d*/ ) { ########## COMMENT OUT THE NEXT 2 LINES FOR TESTING############## open(MAIL, "| /usr/ucb/mail -s annex $SEC_HONCHO"); select(MAIL); print "$annexid\n"; print "$header\n"; print "$_\n"; print "$x[$i]\n\n"; do who_fing(); do who_ru(); close(MAIL); } } } sub who_fing { $at = '@'; @users = `finger $at$add`; $hostname = `/usr/local/bin/hname $add`; #### wants hname in /usr/local/bin $hostname =~ /= (.*)$/; $host = $1; print "@users\n"; print "$hostname\n"; 1; } sub who_ru { @users2 = `rusers -l $host`; print @users2; } @//E*O*F fannex// chmod u=rw,g=rw,o=r fannex echo x - hname.c sed 's/^@//' > "hname.c" <<'@//E*O*F hname.c//' #include #include #include #include #include main(argc, argv) char **argv; { int i; if (argc == 1) { char string[80]; while (! feof(stdin)) { printf("> "); fflush(stdout); lookup(gets(string)); } } else for (i=1; ih_name); } @//E*O*F hname.c// chmod u=rw,g=r,o=r hname.c exit 0 ------------------------------------------------------------------------ Date: Wed, 7 Mar 90 22:13:50 EST From: a.e.mossberg Subject: lattelnet break-ins Up until several days ago I was running a lattelnet service on our Microvax II, which allowed people who signed on to a DECserver (either via a hard-wired terminal or modem) to connect to an arbitrary TCP/IP host (subject of course to network accessibility). Apparently someone was using the service to break in to MOSAIC-PLUS.AF.MIL through my machine, because I got a call from its system administrator and a officer from Defense Intelligence Agency. The lattelnet service (which comes with the Ultrix operating system beginning, I think, with version 2.2) has no capability for password security, or restricting which hosts someone can connect to. After requests from our DEC software coordinator, we were able to get a patched version of /usr/ucb/telnet, which logged the port and DECserver identification of lattelnet connections. Repeated abuse of the service has prompted me to disable it. ------------------------------------------------------------------------ Date: Mon, 26 Feb 90 15:23:12 EST From: Viktor Dukhovni Subject: SunOS pty's (the real problem) (long) A number of posters to this list have pointed out a security hole associated with SunOS pty's and background processes waiting to read them. And indeed I was quite surprised that to be able to read input from idle pty's after someone connects. The reason for my surprise is that this is not caused permissions of the pty itself. Users ought to be able to open pty master/slave pairs, but it should always be the case that the open on the master side shuts down any streams associated with the slave side hanging around from previous sessions, a read on a PTY after the master is closed and reopened should return EIO. ( Thus one should always open the master first! ) Granted shelltool etc., ought to fchown(slave,user,tty) and fchmod(slave,0660), this would allow only "biff" and "talk" access to the terminal and the user to change the mode to disable either or both. I have modified the shelltool/cmdtool/tektool here to run setuid and chown the tty to the user in question make the utmp entry as "root" and then revoke the privs before forking the user shell. This allows us to have a more 644 /etc/utmp file, closing the utmp hole the right way! I have sent my fixes to sun, they said they are working on something similar, don't know when they will release a working setuid window system. No messing around with permissions will be able to close the PTY driver hole, since the "cracker" can telnet to a port, leave a background job running and log out. This will be much harder to exploit under POSIX style terminal sessions due out in 4.1, so Fixed in 4.1 :-) Apart from the ability to read other user's input, a much more serious problem enables one to *generate* input on all tty's psuedo or otherwise. This problem is common to all Berkeley derived terminal drivers. And causes a serious security hole on DecStations, Suns, Berkeley vaxen, etc. There is no *simple* fix. Again POSIX sessions to the rescue fixed in BSD4.4 In the interim we all have to live with cheese cloth for security the terminal drivers, let's keep those fingers crossed... A related problem in the PTY driver was the "half-remote" pty's left behind by cmd-tools under 4.0, this caused hanging telnet sessions or one's that exited at the first character typed (depending on the user's setting of "filec"). I will include the 4.0 note below, though it recommends a fix for the half-remote problem, the real solution should be to shut down the slave side completely inside ptcopen(). Included-From: auspex!guy@uunet.uu.net (Guy Harris) If you get a pseudo-tty into the state where it acts as if "every character typed is a ^D", or "it runs billions of 'ls'es", or something like that, or get it into a state where it isn't in "raw" or "no-echo" mode but doesn't echo what you type, under 4.0, it's probably because it's gotten into an invalid "half-remote mode" state. Basically, "cmdtool" puts it into "remote mode", which is described (to some degree) in PTY(4). If you ran something from the "cmdtool" in the background, and left it around after you quit from the "cmdtool", it holds the "slave" side of the pty in remote mode, but not the master side. The "remote" mode explains the seeming "raw, no-echo" state; the "every character typed is a ^D" stuff seems to come from the bizarre stuff the C shell does when you do "set filec", and the "billions of 'ls'es" are just the C shell's response to an end-of-file (^D) when not at the end of the line - it's showing you the options for the file name you're trying to complete. There is a fix; I've mentioned it to Sun. (For those of you with source and an adventurous spirit, you want to make the pseudo-tty master/controller open routine "ptcopen" send an M_CTL streams message with an MC_DOCANON code upstream on the slave side if it's open and has a stream; check out the code in "ptcioctl" that handles a TIOCREMOTE "ioctl" with a zero argument. I've not tried this, but I think it should fix it; if it blows up and scribbles "I am a duck" all over your root file system, don't ask me about it.) ------------------------------------------------------------------------ Date: Thu, 15 Feb 90 10:03:45 PST From: Ritchey Ruff Subject: answering machines vs. call back modems In risks 9.68 Denis Coskun tells how to use an answering machine as a phone message relay (I include the two messages below). A computer security issue about this is it could possibly be used to defeat a modem callback security system. If the machine records touch tones it will probably record low baud rate modem tones (300 or 1200 baud). The following is a portion of the entire V9.I68 RISKS Digest: In RISKS-7.69 Vince Manis tells us that his General Electric answering machine has only 256 possible access codes for remote message retrieval. I have the same machine. Valid combinations are 3 consecutive touch tones of the form [0-7][0-7][0-3]. In RISKS-7.73 William Curtiss points out that most answering machines just ignore digits until you get the correct security code. "As long as the incoming stream contains the code somewhere you are given access. Since 256 combinations needs three digits, a carefully constructed string of 258 digits will contain every possible combination (for example, if the code is a triplet composed of just the numbers 1 and 2 then the string 1211122212 contains all eight triplets)." The shortest string of digits that I was able to generate for defeating my answering machine was 452 digits: 000100200301101201302102202303103203304004104204305005105205 306006106206307007107207311121131221231321331401411421431501 511521531601611621631701711721732223233240241242243250251252 253260261262263270271272273330034034134234335035135235336036 136236337037137237344044144244345045145245346046146246347047 147247354054154254355055155255356056156256357057157257364064 164264365065165265366066166266367067167267307407417427437507 51752753760761762763770771772773 DTMF decoding chips are required to recognize a tone as short as 50 milliseconds with an interdigit interval of another 50 milliseconds, making a total of 100 ms for each digit. So the whole 452 digit string could be dialed within 45.2 seconds using a demon dialer. Since my answering machine will wait a minute or more while you leave a message, it could be cracked with just one phone call. Can anyone suggest an algorithm to generate a shorter string than I have above, or better yet, an optimal string? A string length of 258 digits is a lower bound, but is there necessarily a solution that short? I checked more than a dozen different answering machines on the market that allow remote message retrieval using touch tones, and the best let you select combinations of the form [0-9][0-9][0-9]. A key space of 1000 combinations is hardly any improvement. ------------------------------ Date: Fri, 9 Feb 90 20:22:57 est dcoskun@alias (Denis Coskun) Subject: How to make answering machines deliver ransom messages I discovered a security weakness that would allow you to trick answering machines with remote message retrieval into making phone calls and delivering untraceable ransom messages! Here's how: Dial someone's answering machine and leave a message with the format: 1. 14 seconds of nonsense talking (to keep the tape running) 2. dial, say, 555-1234 using touch tones (which will be recorded) 3. a few more seconds of random talking 4. finally your ransom message Now dial the security code (which you discovered as described in my companion article) to get the answering machine to play back the messages. As soon as you hear the start of your nonsense message, hang up. The machine will continue playing the messages, oblivious to the fact that no one is listening. The telephone exchange will supply dial tone to the answering machine's line 12 seconds after you hang up (12 seconds at my exchange). Two seconds later, the answering machine will play the recorded touch tones 555-1234, effectively dialing that number. A few seconds later, the person at 555-1234 answers and your message is delivered! And it cannot be traced to you. Of course, you would call back the answering machine and clean up the evidence. I believe that the technique will work on all answering machines with remote message retrieval provided that: 1. You have the security code (see my other posting about how good these are). 2. The exchange will supply dial tone to the callee after the caller hangs up. This is true on all modern switches. 3. The phone line of the answering machine permits touch tone dialing. This is a way to secure your answering machine: switch to pulse dialing only service. 4. The machine and its tape reproduce touch tones with enough fidelity. Mine do. 5. The machine will ignore dial tone. There are no guaranteed electrical changes on the line when a caller hangs up, so watching for dial tone would be the only reliable indicator, which my machine ignores. 6. The machine will record touch tones. Mine will record everything (except that the 3 digit security code gets it to play back the messages). The security hole could be plugged if the machine would stop recording as soon as it got any touch tone. 7. The machine will play all touch tones recorded on its tape. I did have some trouble here since the machine cannot tell if a tone is coming from the tape or from the caller on the line. During playback, my machine will interpret a "1" as a command to fast forward and "3" to fast reverse, and thus disrupt the dialing if these digits are part of the number. A more likely hazard than untraceable ransom messages is the relaying of long distance messages that are charged to some innocent answering machine owner, or harassing the owner by having him billed for random toll calls (long distance, overseas, 976, 900, etc.). ------------------------------------------------------------------------ Date: Fri, 2 Mar 90 15:37:53 EDT From: uunet!telxon!teleng!gorpong (Gordon C. Galligher) Subject: SunOS 4.0.3 UUCICO problems, WIDE open It appears (at least at my site) that the uucico distributed with SunOS 4.0.3 is a little wide open. Me, as a normal user, executed the command: /usr/lib/uucp/uucico -r1 -ssysname -x5 and it proceded to show me the debug output from the call, INCLUDING the phone number, login name, and password used, on the remote machine! On standard Berkeley UUCP's (with 4.2 and 4.3) it doesn't allow non-root to use the -x option. On HoneyDanBer UUCP (with Interactive Systems Corporation's 386/ix), it does allow the -x option, but replaces the secure information with question marks (ie: Dialing ????). With SUNs way of doing things, anyone who has access to your SUN can execute the uucico command, grab the output from the debug portion, and then have another number and login to try to break. Maybe this isn't as big a problem as I feel it is. What are your opinions? ------------------------------------------------------------------------ Date: Sun, 4 Mar 90 14:14:32 EST From: John Robert LoVerso Subject: Re: CBW > Unfortunately, they also know about the "Code Breakers Workbench", CBW will not be of much help if the crypt'd file was compressed first. ------------------------------------------------------------------------ Date: 12 Mar 90 09:59:04+0100 From: uunet!iis!prl Subject: crypt/CBW There are, of course a number of sites recieving this list who are not permitted to have copies of crypt(1), anyway, due to US export restrictions. A good implementation of DES, including CBC file encryption was distributed on the Usenet newsgroup comp.sources.unix, v18i007 (was this numbering mere coincidence? :-) and v18i008. It was written by Antti Louko (alo@kampi.hut.fi) at Helsinki Technical University, and was distributed from Australia so that most sites in the non-US part of the world recieved it without it going through the US. Throughput is about 6Kbytes/sec on a Sun 3/280 with Fujitsu Eagle disks. It is relatively compact; 24Kbytes on a Sun 3. It can be FTP'd from kampi.hut.fi (128.214.3.9) and can be obtained from most Usenet archive servers. The code is freely redistributable, but bears the following Copyright notice: ``Copyright 1989 Antti Louko. All Rights Reserved. ``This is a DES implementation written by Antti Louko (alo@kampi.hut.fi). It is based on DES description found in D.E.R. Denning's book Cryptography and Data Security. At this time you may use this program for non-commercial use. If you modify the program, you must add a comment in the modified file indicating who modified it. For commercial purposes please contact me [Antti Louko - prl]. ``If you find bugs or otherwise modify this program, please send changes back to me [Antti Louko - prl].'' The library code for Antti Louko's DES has also been designed to ``drop in'' to Kerberos and the X11R4 XDMCP encrypted authentication protocol. ------------------------------------------------------------------------ Date: Mon, 12 Mar 90 02:15:09 PST From: uunet!paralogics!shaw (Guy Shaw) Subject: Re: 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.. That might help a small number of people for a short time, but it is a scheme which relies on ignorance of your encoding algorithm, and so, it is not suitable as a standard to be widely used. It would be easy to modify CBW to look for the magic number at the beginning of a compressed file. So, widespread use of compress(crypt()) would result in even weaker security. ------------------------------------------------------------------------ Date: Mon, 5 Mar 90 01:51:31 -0500 From: der Mouse Subject: crackers and passwords >> 3) Crackers have copies of *very* fast password code. How fast does that mean, by the way? I sped up crypt(3) by about an order of magnitude simply by doing an efficient implementation of the algorithm instead of a straightforward and dumb one. Of course, my version (particularly the VAX assembly version) is not as easy to read, but that's the price one pays.... > Would using shadow password files help in this regard? > Shadow password files would be a major improvement and go a long way > towards protecting passwords. If the hackers [sic] can't get your > password file, they certainly can't run the fast password code to > break accounts. (Well, they can run it, but it won't help!) A smaller change would be to tweak crypt(3) slightly and recompile, and then - important! - relink everything at once: login and passwd, in particular, must be relinked together. What do I mean by "tweak slightly"? Any of a number of things; changing the constant (currently 0) which is repeatedly encrypted and changing the way the salt tweaks the E-box are two which come to mind immediately and have effectively unlimited potential for rendering useless all that lovely fast password cracking code. (Just don't everybody change the constant to 1! Flip a coin many times or something.) ------------------------------------------------------------------------ Date: Tue, 13 Mar 90 17:25:53 EST From: uunet!bu-it.bu.edu!budd (Phil Budne) Subject: Re: More hacker signs - probably the same ones >I would immediately check every program the /etc/rc* files run at boot >for a trojan horse (get known good copies off of a tape and do a cmp.) I'd also check crontab and scripts run therefrom. I've seen auto-trojans there as well!! ------------------------------------------------------------------------ Date: Tue, 13 Mar 90 17:21:21 -0800 (PST) From: Barry Lustig Subject: Fwd: So much for security. [ As I stated in the volume 2 issue 6 digest that went out 14-feb-90, I spoke to Steve Simmons and he agreed not to make the security list publically accessable in any way. - neil ] ---------- Forwarded message begins here ---------- We are currently archiving three mailing lists: the old Andrew Bert security digest, the new Neil Gorsuch security digest, and Bjorn Satedevas systems administration mailing list. The material is available for anonymous ftp from terminator.cc.umich.edu. Look in the directory ~ftp/unix/sysadmin. At some point anon uucp access will be offered, but no date has been set. ------------------------------------------------------------------------ Date: Fri, 16 Mar 90 09:40:54 PST From: neil (Neil Gorsuch) Subject: archiving security [ Because of numerous internet computer breakins over the last six months or so, I ask that you PLEASE PLEASE PLEASE don't archive this list. I would prefer that you plug any listed holes and then DUMP THE DIGEST(S). If you must archive the list, make sure that the system it is archived on has ALL known security holes fixed, and for good measure disable every network service that isn't absolutely essential. And USE SHADOW PASSWORDS, they're an easy way to prevent someone with an account on your system and an IBM PC at home to crack root. I can't emphasize enough that the complete list archives details many security holes that have not been fixed on a signifigant number of systems. - neil ] ------------------------------------------------------------------------ Date: Tue, 20 Mar 90 15:34:28 -0500 From: uunet!orion.mc.duke.edu!bet (Bennett Todd) Subject: password checking program wanted I just got a note from someone telling me that a cracker had run through my machine on the way to theirs, using a login with an easily guessable password. I've changed that one, but I'm sure there may be more. Does anyone have a program I can use to scan /etc/passwd for easily guessable passwords? ------------------------------------------------------------------------ Date: Mon, 19 Mar 90 13:06:02 MST From: Subject: Possible problem with Intergraph Soft-PC Subject: Potential problem with Intergraph PC Emulator Intergraph Unix sites may want to examine the things that can be done with SoftPC, the MS-DOS emulator. It may be necessary to remove SoftPC from the pull-down menu or at least restrict it's use to trusted people. SoftPC allows a Unix directory to be mapped as the D: disk. Normal Unix protections may not be enforced as to directory access. I won't elucidate, but any system manager who runs SoftPC should experiment a little and convince himself why and how this can be very dangerous. [ The point of this list is so that we can elucidate, please do - neil ] ------------------------------------------------------------------------ Date: Mon, 26 Mar 90 14:28:41 CST From: uunet!pex.eecs.nwu.edu!phil (William LeFebvre) Subject: I just had the oddest phone call... It may be nothing, but I thought I should share it with you anyway. Someone called my office and said that he wanted to know the number to call to access the computers. I asked him who he was. I didn't recognize the name. I asked him what computer he wanted to connect to and he said "well, a unix computer". I said "which one?" He said "I don't really know." I said, "if you don't know what computer you want to connect to, then what good will dialing up do you?" This was answered with silence. After an uncomfortably long period of silence, I asked if he was still there. He hung up without saying anything more. Maybe he really was confused. Maybe not.... Maybe he was trying to get a number out of me when he had no business using it. Maybe. Moral: don't just give out your dialup numbers to anybody. Know who you're giving them to. I think in the future I may insist that someone come by my office to get the number, unless I *know* who they are and I know that they can't come by for some reason. This is by no means a complete way to protect yourself, but it is, I think, a step in the right direction. ------------------------------------------------------------------------ Date: Tue, 27 Mar 90 09:43:27 PST From: uunet!tc.fluke.com!deb (Deb Lilly) Subject: YP passwd bugs - SunOS 4.0.3 Two serious problems exist under SunOS 4.0.3 with the Yellow Pages passwd map. Sun Bug ID # 1033972 /bin/yppasswd leaves YP passwd map world writable Description: When a user runs yppasswd to change the password on an account in the Yellow Pages, the YP passwd map is recreated with mode 666 (world writable). This is a serious security problem. Fix: Add commands to /var/yp/Makefile on the YP master server to set the mode on the /var/yp/DOMAINNAME files for the maps passwd.byname, passwd.byuid, and publickey.byname: chmod 644 $(YPDBDIR)/$(DOM)/MAP.pag $(YPDBDIR)/$(DOM)/MAP.dir; \ (Substitute each map name for "MAP" in the above command.) Concurrent /bin/yppasswd sessions trash the YP passwd map. Description: When multiple users change their passwords simultaneously, the yellow pages passwd map is updated concurrently, apparently with no file locking. This can trash the YP passwd map. The *source* file for the passwd map is *not* affected. When this problem occurs, it is easy to recreate good passwd maps on the YP master server: cd /var/yp rm passwd.time make passwd However, there is no fix yet to avoid the problem. This bug has been duplicated by Sun under SunOS 4.1 and is still under investigation by Sun Engineering. ------------------------------------------------------------------------ Date: Tue, 13 Mar 90 10:24:03 -0800 From: uunet!aerospace.aero.org!strauss Subject: Re: * Xterm Security hole [X Windows Ver. 11, Release 3 and 4] MIT just released fix-6 which corrects xterm so that it doesn't allow logging to be turned on with an escape sequence. It is very nice to see these things fixed quickly for a change. Good work X Consortium! ------------------------------------------------------------------------ Date: Tue, 13 Mar 90 13:32:06 -0500 From: uunet!wayback.cs.cornell.edu!parmelee (Larry Parmelee) Subject: Re: Xterm Security hole [X Windows Ver. 11, Release 3 and 4] [ This is the last message in this digest - neil ] The X Consortium has now released an official patch for the xterm security hole reported earlier in the week, and they've apparently included a few other bug fixes as well. You probably should apply this patch instead of my original patch. Related to the security hole, they have added 3 pre-processor flags that control various aspects of the hole: ALLOWLOGFILEONOFF - If defined, allow the escape sequences which turn logging on and off. ALLOWLOGFILECHANGES - If defined, allow the escape sequences which change the logfile name. ALLOWLOGFILEEXEC - If defined, allows a logfile name beginning with a "|" to form a pipelined command. By default these will all be undefined. Defining "ALLOWLOGFILECHANGES" may allow an attacker to overwrite a user's files. If "ALLOWLOGFILEEXEC" is also defined, the attacker can at least lay a booby-trap for the user (assuming "ALLOWLOGFILEONOFF" is not defined), such that something nasty can happen at a much later time if/when the user happens to turn on logging in the xterm window. Of course, if all three are defined, the attacker can lay a booby-trap and trigger it immediately. Defining "ALLOWLOGFILEONOFF" and "ALLOWLOGFILEEXEC" but leaving "ALLOWLOGFILECHANGES" undefined is probably reasonably safe- The attacker can turn logging on and off all he wishes, but can not specify a new log file name, hence cannot overwrite random files, nor specify commands. However, having "ALLOWLOGFILEEXEC" defined allows users to log their xterm activity to a pipeline: xterm -l -lf '| SomeCommand' and if this is done, rapidly turing logging on and off may have some other side effects. Lastly, defining only "ALLOWLOGFILEONOFF" seems harmless enough, and may be useful under some circumstances. The X Consortium patch follows below. -Larry Parmelee parmelee@cs.cornell.edu Date: Tue, 13 Mar 90 11:35:06 EST Message-Id: <9003131635.AA14970@expo.lcs.mit.edu> From: Xstuff service Subject: fixes/6 In-Reply-To: Request from parmelee@wayback.cs.cornell.edu (larry parmelee) dated Tue Mar 13 11:30:04 EST 1990 To: parmelee@cs.cornell.edu This patch fixes a security hole in xterm that has been there since X.V10R4. To apply it, cd to the top of the X tree and apply with "patch -p0" and remake in mit/clients/xterm. *** /tmp/,RCSt1a24884 Mon Mar 12 11:27:20 1990 --- mit/clients/xterm/Imakefile Mon Mar 12 11:25:46 1990 *************** *** 34,39 **** --- 34,40 ---- #endif MAIN_DEFINES = -DUTMP $(TTYGROUPDEF) $(PUCCPTYDDEF) + MISC_DEFINES = /* -DALLOWLOGFILEEXEC */ SRCS1 = button.c charproc.c cursor.c data.c input.c \ main.c menu.c misc.c screen.c scrollbar.c tabs.c \ *************** *** 50,64 **** DEPLIBS2 = PROGRAMS = xterm resize #ifdef CrayArchitecture ! TERMCAPLIB = -lcurses #else ! TERMCAPLIB = -ltermcap #endif AllTarget($(PROGRAMS)) SpecialObjectRule(main.o, ,$(MAIN_DEFINES)) NormalProgramTarget(xterm,$(OBJS1),$(DEPLIBS1),XawClientLibs,$(TERMCAPLIB) $(PTYLIB)) InstallProgramWithFlags(xterm, $(BINDIR), $(INSTUIDFLAGS)) --- 51,75 ---- DEPLIBS2 = PROGRAMS = xterm resize + #ifndef TermcapLibrary + #if SystemV && !defined(MacIIArchitecture) #ifdef CrayArchitecture ! #define TermcapLibrary -lcurses /* special case of system v */ #else ! #define TermcapLibrary -ltermlib /* usually in here */ #endif + #else + #define TermcapLibrary -ltermcap /* bsd puts it here */ + #endif + #endif + TERMCAPLIB = TermcapLibrary + AllTarget($(PROGRAMS)) SpecialObjectRule(main.o, ,$(MAIN_DEFINES)) + SpecialObjectRule(misc.o, ,$(MISC_DEFINES)) + SpecialObjectRule(charproc.o, ,$(MISC_DEFINES)) NormalProgramTarget(xterm,$(OBJS1),$(DEPLIBS1),XawClientLibs,$(TERMCAPLIB) $(PTYLIB)) InstallProgramWithFlags(xterm, $(BINDIR), $(INSTUIDFLAGS)) *** /tmp/,RCSt1a24650 Mon Mar 12 11:11:45 1990 --- mit/clients/xterm/button.c Mon Mar 5 11:47:01 1990 *************** *** 1,5 **** /* ! * $XConsortium: button.c,v 1.49 89/12/10 20:45:17 jim Exp $ */ --- 1,5 ---- /* ! * $XConsortium: button.c,v 1.50 90/03/05 11:46:57 keith Exp $ */ *************** *** 35,41 **** J. Gettys. */ #ifndef lint ! static char rcs_id[] = "$XConsortium: button.c,v 1.49 89/12/10 20:45:17 jim Exp $"; #endif /* lint */ #include "ptyx.h" /* Xlib headers included here. */ --- 35,41 ---- J. Gettys. */ #ifndef lint ! static char rcs_id[] = "$XConsortium: button.c,v 1.50 90/03/05 11:46:57 keith Exp $"; #endif /* lint */ #include "ptyx.h" /* Xlib headers included here. */ *************** *** 489,497 **** PointToRowCol(event->xbutton.y, event->xbutton.x, &row, &col); } ExtendExtend (row, col); - lastButtonUpTime = event->xbutton.time; - /* Only do select stuff if non-null select */ if (startSRow != endSRow || startSCol != endSCol) { if (replyToEmacs) { if (rawRow == startSRow && rawCol == startSCol --- 489,495 ---- *************** *** 514,525 **** } TrackText(0, 0, 0, 0); } SaltTextAway(startSRow, startSCol, endSRow, endSCol, params, num_params); ! } else DisownSelection(term); ! ! /* TrackText(0, 0, 0, 0); */ ! eventMode = NORMAL; } #define Abs(x) ((x) < 0 ? -(x) : (x)) --- 512,542 ---- } TrackText(0, 0, 0, 0); } + } + SelectSet(event, params, num_params); + eventMode = NORMAL; + } + + HandleSelectSet(w, event, params, num_params) + Widget w; + XEvent *event; + String *params; + Cardinal *num_params; + { + SelectSet (event, params, *num_params); + } + + SelectSet (event, params, num_params) + XEvent *event; + String *params; + Cardinal num_params; + { + /* Only do select stuff if non-null select */ + if (startSRow != endSRow || startSCol != endSCol) { SaltTextAway(startSRow, startSCol, endSRow, endSCol, params, num_params); ! } else ! DisownSelection(term); } #define Abs(x) ((x) < 0 ? -(x) : (x)) *** /tmp/,RCSt1a24657 Mon Mar 12 11:11:48 1990 --- mit/clients/xterm/charproc.c Mon Mar 12 10:30:27 1990 *************** *** 1,5 **** /* ! * $XConsortium: charproc.c,v 1.121 89/12/15 19:07:43 jim Exp $ */ --- 1,5 ---- /* ! * $XConsortium: charproc.c,v 1.123 90/03/12 10:30:21 jim Exp $ */ *************** *** 149,155 **** #define doinput() (bcnt-- > 0 ? *bptr++ : in_put()) #ifndef lint ! static char rcs_id[] = "$XConsortium: charproc.c,v 1.121 89/12/15 19:07:43 jim Exp $"; #endif /* lint */ static int nparam; --- 149,155 ---- #define doinput() (bcnt-- > 0 ? *bptr++ : in_put()) #ifndef lint ! static char rcs_id[] = "$XConsortium: charproc.c,v 1.123 90/03/12 10:30:21 jim Exp $"; #endif /* lint */ static int nparam; *************** *** 180,186 **** static void HandleKeymapChange(); extern void HandleInsertSelection(); extern void HandleSelectStart(), HandleKeyboardSelectStart(); ! extern void HandleSelectExtend(); extern void HandleSelectEnd(), HandleKeyboardSelectEnd(); extern void HandleStartExtend(), HandleKeyboardStartExtend(); static void HandleBell(); --- 180,186 ---- static void HandleKeymapChange(); extern void HandleInsertSelection(); extern void HandleSelectStart(), HandleKeyboardSelectStart(); ! extern void HandleSelectExtend(), HandleSelectSet(); extern void HandleSelectEnd(), HandleKeyboardSelectEnd(); extern void HandleStartExtend(), HandleKeyboardStartExtend(); static void HandleBell(); *************** *** 250,255 **** --- 250,256 ---- { "select-start", HandleSelectStart }, { "select-extend", HandleSelectExtend }, { "select-end", HandleSelectEnd }, + { "select-set", HandleSelectSet }, { "select-cursor-start", HandleKeyboardSelectStart }, { "select-cursor-end", HandleKeyboardSelectEnd }, { "set-vt-font", HandleSetFont }, *************** *** 1489,1498 **** --- 1490,1508 ---- update_reversewrap(); break; case 46: /* logging */ + #ifdef ALLOWLOGFILEONOFF + /* + * if this feature is enabled, logging may be + * enabled and disabled via escape sequences. + */ if(func == bitset) StartLog(screen); else CloseLog(screen); + #else + Bell(); + Bell(); + #endif /* ALLOWLOGFILEONOFF */ break; case 47: /* alternate buffer */ if(func == bitset) *************** *** 1687,1696 **** --- 1697,1708 ---- update_reversewrap(); break; case 46: /* logging */ + #ifdef ALLOWLOGFILEONOFF if(screen->save_modes[14]) StartLog(screen); else CloseLog(screen); + #endif /* ALLOWLOGFILEONOFF */ /* update_logging done by StartLog and CloseLog */ break; case 47: /* alternate buffer */ *** /tmp/,RCSt1a24743 Mon Mar 12 11:12:09 1990 --- mit/clients/xterm/misc.c Mon Mar 12 10:30:22 1990 *************** *** 1,5 **** /* ! * $XConsortium: misc.c,v 1.62 89/12/10 20:44:41 jim Exp $ */ --- 1,5 ---- /* ! * $XConsortium: misc.c,v 1.65 90/03/12 10:30:17 jim Exp $ */ *************** *** 58,64 **** static void DoSpecialLeaveNotify(); #ifndef lint ! static char rcs_id[] = "$XConsortium: misc.c,v 1.62 89/12/10 20:44:41 jim Exp $"; #endif /* lint */ xevents() --- 58,64 ---- static void DoSpecialLeaveNotify(); #ifndef lint ! static char rcs_id[] = "$XConsortium: misc.c,v 1.65 90/03/12 10:30:17 jim Exp $"; #endif /* lint */ xevents() *************** *** 388,393 **** --- 388,394 ---- register int i; static char *log_default; char *malloc(), *rindex(); + #ifdef ALLOWLOGFILEEXEC void logpipe(); #ifdef SYSV /* SYSV has another pointer which should be part of the *************** *** 395,400 **** --- 396,402 ---- */ unsigned char *old_bufend; #endif /* SYSV */ + #endif /* ALLOWLOGFILEEXEC */ if(screen->logging || (screen->inhibit & I_LOG)) return; *************** *** 408,413 **** --- 410,421 ---- strcpy(screen->logfile, log_default); } if(*screen->logfile == '|') { /* exec command */ + #ifdef ALLOWLOGFILEEXEC + /* + * Warning, enabling this "feature" allows arbitrary programs + * to be run. If ALLOWLOGFILECHANGES is enabled, this can be + * done through escape sequences.... You have been warned. + */ int p[2]; static char *shell; *************** *** 454,459 **** --- 462,472 ---- close(p[0]); screen->logfd = p[1]; signal(SIGPIPE, logpipe); + #else + Bell(); + Bell(); + return; + #endif } else { if(access(screen->logfile, F_OK) == 0) { if(access(screen->logfile, W_OK) < 0) *************** *** 500,505 **** --- 513,519 ---- screen->logstart = screen->TekEmu ? Tbuffer : buffer; } + #ifdef ALLOWLOGFILEEXEC void logpipe() { register TScreen *screen = &term->screen; *************** *** 510,516 **** --- 524,532 ---- if(screen->logging) CloseLog(screen); } + #endif /* ALLOWLOGFILEEXEC */ + do_osc(func) int (*func)(); { *************** *** 518,523 **** --- 534,540 ---- register int mode, c; register char *cp; char buf[512]; + char *bufend = &buf[(sizeof buf) - 1]; /* leave room for null */ extern char *malloc(); Bool okay = True; *************** *** 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; --- 548,554 ---- mode = 10 * mode + (c - '0'); if (c != ';') okay = False; cp = buf; ! while(isprint((c = (*func)()) & 0x7f) && cp < bufend) *cp++ = c; if (c != 7) okay = False; *cp = 0; *************** *** 550,555 **** --- 567,577 ---- break; case 46: /* new log file */ + #ifdef ALLOWLOGFILECHANGES + /* + * Warning, enabling this feature allows people to overwrite + * arbitrary files accessible to the person running xterm. + */ if((cp = malloc((unsigned)strlen(buf) + 1)) == NULL) break; strcpy(cp, buf); *************** *** 556,561 **** --- 578,587 ---- if(screen->logfile) free(screen->logfile); screen->logfile = cp; + #else + Bell(); + Bell(); + #endif break; case 50: ------------------------------------------------------------------------ End of Security Digest Volume 2 Issue 10 **********************