Skip Menu |
 

Download (untitled) / with headers
text/plain 10.5KiB
From tytso@MIT.EDU Wed Nov 20 16:32:44 1996
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id QAA27462 for <bugs@RT-11.MIT.EDU>; Wed, 20 Nov 1996 16:32:44 -0500
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA11549; Wed, 20 Nov 96 16:32:17 EST
Received: by dcl.MIT.EDU (5.x/4.7) id AA21639; Wed, 20 Nov 1996 16:32:16 -0500
Message-Id: <9611202132.AA21639@dcl.MIT.EDU>
Date: Wed, 20 Nov 1996 16:32:16 -0500
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: krb5-bugs@MIT.EDU
Subject: [Oliver Friedrichs: [linux-security] Serious BIND resolver problems.]

Show quoted text
>Number: 211
>Category: krb5-misc
>Synopsis: [Oliver Friedrichs: [linux-security] Serious BIND resolver problems.]
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: krb5-unassigned
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Wed Nov 20 16:33:01 EST 1996
>Last-Modified: Fri Nov 22 16:21:44 EST 1996
>Originator:
>Organization:
>Release:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:

Responsible-Changed-From-To: gnats-admin->krb5-unassigned
Responsible-Changed-By: bjaspan
Responsible-Changed-When: Fri Nov 22 15:21:57 1996
Responsible-Changed-Why:

State-Changed-From-To: open-closed
State-Changed-By: bjaspan
State-Changed-When: Fri Nov 22 16:16:33 1996
State-Changed-Why:

I fixed all occurrences of this problem in the krb5 source tree. In
each case, memcpy or memmove was being used to copy from hp->h_addr to
a sin_addr using h_length as the length. I replaced h_length with
sizeof(sin_addr), using the correct variables names etc. of course. I
then recompiled the system and ran the lib/kadm5 unit tests to make
sure everything still worked. It did, and this is not surprising
since h_length == sizeof(sin_addr) all the time anyway.

The following list shows the affected files. Those files preceeded by
a Y were updated. Those files preceeded by an N use h_length but do
not do so in an incorrect manner; typically, that means that allocate
a buffer h_length bytes long to copy into.

The upshot of this is that if you run find . -type f -print | xargs
grep -l h_length in the source tree, the only files listed should be
ChangeLogs and those in the N list below.

Y ./appl/bsd/kcmd.c
Y ./appl/gss-sample/gss-client.c
Y ./appl/gssftp/ftp/ftp.c
Y ./appl/simple/client/sim_client.c
Y ./appl/simple/server/sim_server.c
Y ./appl/telnet/telnet/commands.c
Y ./appl/telnet/telnet/commands.c
Y ./appl/user_user/client.c
Y ./kadmin.v4/server/kadm_ser_wrap.c
Y ./kadmin/v4server/kadm_ser_wrap.c
Y ./lib/rpc/clnt_generic.c
Y ./lib/rpc/clnt_simple.c
Y ./lib/rpc/getrpcport.c
Y ./mac/gss-sample/gss-client.c
Y ./slave/kprop.c
Y ./tests/misc/test_getsockname.c
Y ./windows/gss/gss-client.c

N ./include/krb5/kwinsock.h
N ./include/krb5/macsock.h
N ./lib/crypto/os/c_localaddr.c
N ./lib/gssapi/generic/util_canonhost.c
N ./lib/krb4/g_phost.c
N ./lib/krb4/macsock.c
N ./lib/krb4/realmofhost.c
N ./lib/krb4/send_to_kdc.c
N ./lib/krb5/os/hostaddr.c
N ./lib/krb5/os/macsock.c
N ./lib/krb5/os/sn2princ.c


Show quoted text
>Unformatted:
This is a problem we need to address. The exploit which the author
mentions isn't directly applicable to the Kerberized kcmd, since it
allows you to overwrite sockaddr_in from. Nevertheless, we should
sweep through our tree and make sure we're not vulernable to this.

- Ted
------- Forwarded Message

Resent-Date: Tue, 19 Nov 1996 15:08:20 -0500
Old-X-Envelope-From: oliver@silence.secnet.com Tue Nov 19 14:16:34 1996
Date: Tue, 19 Nov 1996 13:13:37 -0700 (MST)
From: Oliver Friedrichs <oliver@secnet.com>
To: linux-security@tarsier.cv.nrao.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-Id: <"MjJGd1.0.En6.qEXao"@redhat.com>
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
X-Mailing-List: <linux-security@redhat.com> archive/latest/20
X-Loop: linux-security@redhat.com
Precedence: list
Resent-Sender: linux-security-request@redhat.com
Subject: [linux-security] Serious BIND resolver problems.


[Mod: I am approving this message even though it is just a rehash of known
vulnerabilities of DNS. Please in future lets avoid rehashing what was
alreadt discussed in probably every single mailing list that deals with UNIX
security several years ago? -- alex ]


###### ## ## ######
## ### ## ##
###### ## # ## ##
## ## ### ##
###### . ## ## . ###### .

Secure Networks Inc.

Security Advisory
November 18, 1996

Vulnerability in Unchecked DNS Data.

In research for our upcoming network auditing tool, we have uncovered a
serious problem present in implementations of BIND which trust invalid data
sent to them. This vulnerability specifically applies to hostname to address
resolution and can result in local and remote users obtaining root privileges.

It is recommended that security conscious users upgrade to the latest version
of the BIND resolver immediately. Information on obtaining the latest
official release is provided at the end of this message.

Technical Details
~~~~~~~~~~~~~~~~~

When a standard hostname lookup is performed on internet connected systems,
the resulting address should be 4 bytes (Forgetting about IPv6 for now).
Assuming that the address will always be 4 bytes, many privileged and
unprivileged programs (including network daemons) trust the address length
field which is returned from gethostbyname() in the hostent structure. By
trusting the length field returned by DNS to be 4 bytes, it then copies the
address into a 4 byte address variable. The vulnerability exists due to the
fact that we can specify the size of IP address data within the DNS packet
ourselves. By specifying a size larger than 4 bytes, an overflow occurs, as
the program attempts to copy the data into the 4 byte structure it has
allocated to store the address.

One example of this vulnerability occurs in rcmd.c, the standard BSD library
routine which is used by rsh and rlogin to remotely connect to systems. Note
that the code itself is not faulty, however the resolver implementation is.
Example code follows:

hp = gethostbyname(*ahost);
if (hp == NULL) {
herror(*ahost);
return (-1);
}
*ahost = hp->h_name;

.
.
.

bzero(&sin, sizeof sin);
sin.sin_len = sizeof(struct sockaddr_in);
sin.sin_family = hp->h_addrtype;
sin.sin_port = rport;
bcopy(hp->h_addr_list[0], &sin.sin_addr, hp->h_length);

In this example, we copy hp->h_length ammount of data into the address
variable of a sockaddr_in structure, which is 4 bytes. The hp->h_length
variable is taken directly from the DNS reply packet. If we now look at how
rcmd() declares it's variables, and after looking through rlogin with a
debugger, we can determine that this is a dangerous situation.

int rcmd(ahost, rport, locuser, remuser, cmd, fd2p)
char **ahost;
u_short rport;
const char *locuser, *remuser, *cmd;
int *fd2p;
{
struct hostent *hp;
struct sockaddr_in sin, from;
fd_set reads;

On further testing, and implementation of exploitation code, we can verify
that this is indeed possible via the rlogin service. In order to exploit the
problem, we first start a program to send a fake DNS replies.

[root@ariel] [Dec 31 1969 11:59:59pm] [~]% ./dnsfake
oakmont.secnet.com(4732)->idoru.secnet.com(53) : lookup: random-domain.com (1:1)
sent packet fake reply: 270 bytes
idoru.secnet.com(53)->oakmont.secnet.com(4732) : reply: random-domain.com (1:1)

We then cause rcmd() within rlogin to do a host lookup and response with
our false data.

[oliver@oakmont] [Dec 31 1969 11:58:59pm] [~]% whoami
oliver
[oliver@oakmont] [Jan 01 1970 00:00:01am] [~]% rlogin random-domain.com
random-domain.com: Connection refused
# whoami
root
#

Impact
~~~~~~

By checking common BSD sources, we can see that over 20 local programs are
vulnerable to this attack, and possibly 2 remote daemons. The possibility
of exploiting local programs may seem insignificant, however if one considers
an attacker somewhere on the internet intercepting DNS lookups, and inserting
their own replies, it isn't. There is a real threat of passive attacks
present here, whereby any user on a network running any of these programs can
be a victim. Take for instance traceroute, or ping both of which fall prey
to this problem.

Aside from stock UN*X programs which ship with most vendor operating systems,
there appears to be problems related to h_length in external software packages.
Due to the flaw, FWTK (Firewall Toolkit) a freely available firewall kit
appears vulnerable. The generic routine, conn_server(), which is utilizied
by the proxy servers, appears to trust the data as well.

Vulnerable Systems
~~~~~~~~~~~~~~~~~~

At this point we would assume that most vendor systems who have incorporated
BIND directly into their operating system are vulnerable.

Solaris is not vulnerable according to Casper Dik <Casper.Dik@Holland.Sun.COM>

Fix Information
~~~~~~~~~~~~~~~

The maintainers of BIND, and CERT were notified of this problem several
months previous to this posting.

We recommend upgrading to the latest release of BIND which solves this
problem due to the incorporation of IPv6 address support.

The latest official release of BIND is availible at:

ftp.vix.com in the directory /pub/bind/release/4.9.5



We wish to acknowledge and thank Theo Deraadt, the maintainer of the OpenBSD
operating system for his help in finding and analyzing this problem. More
information on OpenBSD can be found at http://www.openbsd.org.

- Oliver Friedrichs <oliver@secnet.com>

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia

mQCNAzJATn0AAAEEAJeGbZyoCw14fCoAMeBRKiZ3L6JMbd9f4BtwdtYTwD42/Uz1
A/4UiRJzRLGhARpt1J06NVQEKXQDbejxGIGzAGTcyqUCKH6yNAncqoep3+PKIQJd
Kd23buvbk7yUgyVlqQHDDsW0zMKdlSO7rYByT6zsW0Rv5JmHJh/bLKAOe7p9AAUR
tCVPbGl2ZXIgRnJpZWRyaWNocyA8b2xpdmVyQHNlY25ldC5jb20+iQCVAwUQMkBO
fR/bLKAOe7p9AQEBOAQAkTXiBzf4a31cYYDFmiLWgXq0amQ2lsamdrQohIMEDXe8
45SoGwBzXHVh+gnXCQF2zLxaucKLG3SXPIg+nJWhFczX2Fo97HqdtFmx0Y5IyMgU
qRgK/j8KyJRdVliM1IkX8rf3Bn+ha3xn0yrWlTZMF9nL7iVPBsmgyMOuXwZ7ZB8=
=xq4f
-----END PGP PUBLIC KEY BLOCK-----

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Oliver Friedrichs - (403) 262-9211 - Secure Networks Inc.
Suite 440, 703-6th Avenue S.W. Calgary, AB, Canada, T2P 0T9




------- End Forwarded Message