Return-Path: <mhpower@MIT.EDU>
Received: from MIT.EDU by po12.mit.edu (8.9.2/4.7) id WAA17450; Mon, 29 Jan 2001 22:55:36 -0500 (EST)
From: <mhpower@MIT.EDU>
Received: from customer-care.infrastructure.org by MIT.EDU with SMTP id AA24512; Mon, 29 Jan 01 22:57:29 EST
Received: (qmail 26750 invoked by uid 7783); 30 Jan 2001 03:55:31 -0000
Message-Id: <20010130035531.26749.qmail@customer-care.infrastructure.org>
Date: Mon, 29 Jan 2001 22:55:31 -0500
To: security-internal@MIT.EDU
Subject: new named vulnerability; updated sentry.mit.edu bind
X-Evolution: 00000071-0000

I updated the bind package on sentry to bind-8.2.3-0.5.x.i386.rpm,
which presumably will address the VU#196945 and VU#325431 issues in

   http://www.cert.org/advisories/CA-2001-02.html

Running "rpm -Uvh bind-8.2.3-0.5.x.i386.rpm" left the old version of
named running, so the machine was still vulnerable. It was necessary
to do "/etc/rc.d/init.d/named restart". For the new named, the version
string is 8.2.3-REL, i.e.,

  % dig @sentry.mit.edu -c chaos -t txt version.bind
  ...
  VERSION.BIND.           0S CHAOS TXT    "8.2.3-REL"

If the chart at http://www.isc.org/products/BIND/bind-security.html is
accurate, Athena Solaris and Irix machines (using the version 8.1.2
BIND named) are vulnerable only to "It is possible to construct a
inverse query that allows the stack to be read remotely exposing
environment variables." In that case, we would probably not ever be
sending mail to owners of machines with a 8.1.2 named, telling them
they needed to upgrade.

Linux-Athena machines running the supported IS release should have
8.1.2 also. Machines running the old sipb Linux-Athena based on Red
Hat 5.2 will often have a vulnerable named unless the owner happened
to patch it on their own today. The named version string on these
machines would, I think, be 8.2.2-P7 if the owner installed all
previous bind updates. If the owner didn't install any bind updates,
the might have bind-8.1.2-5.i386.rpm (the original version that was
shipped with Red Hat 5.2), and in that case they wouldn't have any
named vulnerabilities allowing remote access.

I'm not sure how many machines there are running the sipb
debian-athena Linux distribution, but the one I know of has a named
version string of 8.2.2-P7-NOESW, which would be a vulnerable version.

People who installed Red Hat 6.2 or 7.0 on their own (non-Athena
versions) would have 8.2.2-P7 if they installed the patch from
November 2000, and 8.2.2-P5 if they didn't -- both of these are
vulnerable versions.

For all vulnerable versions, my guess is that remote root compromise
is possible, but we don't have any evidence suggesting that attacks
have begun, and I don't know of publicly available exploit code.

Matt