robjohn@logdis1.oc.aflc.af.mil (CDC Contractor Bob Johnson;SCSS;) (06/04/91)
Ok, enuf already! I've paged through (seemingly) megabytes of information, blathering, lambasting, bickering, obscenity, arguing, and pontificating about a certain tty security hole. If you're not smart enough to figure it out by now from the clues, then you shouldn't be jumping up and down on this list. If you don't have time, then welcome to the world of "having a real job". There is a large body of system administrators (myself included) who just don't have the time to mess with finding a hole they don't have the source code to fix. What we need is a "bell for the cat" to know if someone is abusing the hole, and some common-sense "rules of thumb" to cut down on the opportunity for abuse. Unfortunately, this particular hole doesn't lend itself to monitoring very well. I could just as well spend my time worrying about being hit by a meteorite - it would do me about as much good. Now -- to the few who believe that the world has a right to any and all information about security holes, and who have knocked various "restricted" security lists... If you truly believe the world at large has the right to know - why not start your own "Security Issues" list and accept all comers? You can sign me up as the first person on the list. The way I see it, if a person is inclined to system cracking, they are going to find the holes one way or another. We might as well be privy to the same info. Why should only crooks have guns? Just be careful of the Computer Fraud and Abuse Act of 1987, which makes it a felony to tell someone how to crack a system ;-). But, more than anything (IMHO), if you're not willing to do something constructive, then..... QWITCHERBITCHIN! ------------------------------------------------------------------------------ Bob Johnson, Control Data Corporation (contractor to...) Tinker Air Force Base, Oklahoma robjohn@logdis1.oc.aflc.af.mil
stuart@tharr.UUCP (Stuart Tares) (06/08/91)
I totally agree with what has been said - certain System administrators do not have the time or source to plug these gaps and it could take long enough forthe hardware/software vendors to fix the problem. There is news over the front pages of the UK computer press about a major hack going on but we are not allowed to know what it is. it goes on to say that Cert have been given the deatils but have not issued a formal warning. Why not - does it take another sendmail bug to appear to let "ordinary" system administrator find out about thebugs ? -- BOVIS CONSTRUCTION LTD | Tel: +44 81 4223488 Fax: +44 81 4224055 142 Northolt Road, | UUCP: ...mcsun!ukc!axion!tharr!stuart South Harrow, HA2 0EE | MAIL: stuart@thar.uucp <-- tharr *free* public access to Usenet in the UK 0234 841503 -->
dylan@ibmpcug.co.uk (Matthew Farwell) (06/09/91)
In article <2201@tharr.UUCP> stuart@tharr.UUCP (Stuart Tares) writes: >It goes on to say that Cert have been given the deatils but have not >issued a formal warning. Why not - does it take another sendmail bug to >appear to let "ordinary" system administrator find out about thebugs ? I believe CERT don't generally announce bugs until a fix (either source or a binary patch) is made available. Dylan. -- Matthew J Farwell: dylan@ibmpcug.co.uk || ...!uunet!ukc!ibmpcug!dylan But you're wrong Steve. You see, its only solitaire.
ccsis@gdt.bath.ac.uk (Icarus Sparry) (06/11/91)
In article <1991Jun8.201142.8423@ibmpcug.co.uk> dylan@ibmpcug.CO.UK (Matthew Farwell) writes: >>It goes on to say that Cert have been given the deatils but have not >>issued a formal warning. Why not - does it take another sendmail bug to >>appear to let "ordinary" system administrator find out about thebugs ? > >I believe CERT don't generally announce bugs until a fix (either source >or a binary patch) is made available. However a source patch and a binary patch are available. Bath and Edinburgh Universities have developed both. This particular bug affects all machines running BSD systems. It is p_a_r_t_i_a_l_l_y_ fixed in SunOS4.1.1 and BSD4.3-reno. At the start of April, just over 100 sites in the UK were broken into. The intruders used this bug to gain 'root' access, having first logged in as a normal user. In the UK, the main network for academic sites is called JANET. It is an X.25 network, and runs its own set of protocols for things like file transfers. These involve giving a (username,password) pair for each transfer, rather than having something like '.rhosts' to pre-authenticate the transfer. In the name of User Convenience, the software has the ability to store, on the site which initiates the transfer, this information. It is held below a directory which is mode 700, owned by root. When the intruders gained root access, they read all of these files, to enable them to gain access to other sites. Before someone tells me that this is a very bad way to set up software, let me point out a few things. 1) It is. 2) It is no worse than BSD '.rhosts' files, and in some ways it is a lot better. e.g. The Internet worm demonstrated that in many cases if fred@machine_a is in fsmith@machine_b's .rhosts file, then in many cases the converse is true. If is root, then he can su to fsmith, and then rlogin as fred. 3) IF (big IF) people set up a system to do it, then we could simply implement the Multics 'card input password' system, where you have different passwords for file transfer and login. Given this, even if the intruders did get the files containing the card passwords, they still would not be able to log into the machines (unless the user used the same password for both of course!). The intruders in the UK removed system accounting files, in an attempt to cover their traces, and took copies of password files for off-line breaking. When we first phoned CERT, telling them that we had a problem, and saying where we thought the problem was, they said that they didn't know of any problems in that area. Two days later, when Edinburgh managed to capture the binary, and reverse engineer it, we again spoke to CERT who told us that this was 'an old problem, which the major manufacturers were silently closing'. I have a set of sources which fix the problem. Unfortunately they are not complete, in that I am unable to find copies of certain header files from BSD4.3-reno. They do not appear to be on uunet.uu.net. I have written to berkeley asking for the files, but so far have had no reply. W_h_e_n_ I get them, I will activly seek ways of distributing the fixes. Edinburgh have fixes based on BSD4.3-tahoe, which have already been distributed within the UK. The Computer Board, which is the main source of government grants to University computer centres in the UK, is in the process of setting up a UK-CERT. To sum up, 1) Yes there is a problem. 2) Fixes are known and being distributed. 3) They need to be able to get into your machine to be able to exploit the bug. (This includes being listed in /etc/hosts.equiv). 4) The Police are involved, and are activly seeking the culprits responsible for the UK breakins. 5) Binary patches exist. To do the job correctly you need source patches, but the binary ones make the holes a l_o_t_ harder to exploit. Icarus