Open Access to Security Info

[Icarus Sparry]

In article <1991Jun8.201142.8423 at ibmpcug.co.uk> dylan at 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 at machine_a is in fsmith at 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