[1541] in WWW Security List Archive
Re: _DNS_ security problems
daemon@ATHENA.MIT.EDU (Dan Stromberg)
Mon Feb 26 00:54:31 1996
Date: Sun, 25 Feb 1996 19:07:24 -0800
From: Dan Stromberg <strombrg@test34a.acs.uci.edu>
To: EKR <ekr@terisa.com>
CC: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
EKR wrote:
> >I'm not convinced that such
> >functionality belongs in gethostbyaddr(), but I do believe there should
> >at least be a function (if there isn't already, I don't work with this
> >stuff frequently) in the standard bind distribution, that does precisely
> >this (independent of your chosen #ifdef's).
> Yes, I agree. However, note that Java wasn't calling gethostbyaddr()
> but rather gethostbyname(), as far as I can tell. But you could
> imagine a similar modification to gethostbyname().
'not sure. Probably true. The source'd tell. bind-4.9.3 does appear
to only complain if there's no A, when checking a PTR (with SUNSECURITY
turned on).
> >2) Additionally, (and perhaps more importantly) purdue-thesis.ps, in
> >that same distribution, discusses advertising bogus PTR's, in addition
> >to bogus A's. The mechanisms of such advertising is discussed in a
> >somewhat hand-waving manner. From pages 42 and 43:
> [Description of how to spoof PTR records deleted]
> Yep. This is only one of a number of ways to spoof DNS. I indicated
> that this was possible in my original message. In fact, if you remember,
> I said
> '[As I'll discuss later, however, spoofing could be used
> to defeat the obvious defense against this attack.]'
>
> and ...
> 'Now, a real spoofing attack can be used to defeat this. The attacker
> would forge the reply for the reverse lookup for 4.5.6.7 and return
> attacker.com. DNS security is intended to prevent this from happening.'
The paper does not indicate that DNS spoofing is required for the
described attack that gets around PTR checking.
From section 3.3.1, "Assumptions to Facilitate Break-ins":
-----------------------------------------------------------------------
In our setup we assume that the attacker has complete control over
machine NS(b) running a legitimate primary nameserver for a DNS zone.
This strong assumption does not always need to be satisfied. It is
simply the easiest for an attacker if he controls a primary nameserver,
because of its capabilities and the fact that other machines believe
nameservers.
...
The control must include the associated inverse mapping tree. The
attacker might have successfully subverted such a machine or simply be a
renegade system administrator. Both have happened in the past (i.e.
[Sto89, Mad92]).
...
In the following discussion we will assume that the attacker has indeed
superuser access to a primary nameserver. With that assumption in place
we decrease the complexity of the following discussions.
-----------------------------------------------------------------------
The paper does also discuss DNS ID number, and TCP/IP sequence number
attacks, but it seems (not strongly) to suggest that they are not a
required part of the attacks outlined, but rather that their possibility
make the assumptions made by the paper a bit overstrong (and that the
assumptions were made only to help keep the discussion simple).
While this does not _assert_ that the PTR mapping can be subverted using
only root access to a primary nameserver, it does suggest it.
Are you fairly certain that it is impossible to fake PTR records, in the
same manner A records can be faked?
I might point out that bind-4.9.3 contains a NO_GLUE define in
named-xfer.c (on by default), that includes code to prune out data about
zones other than that being transfered, during a zone transfer.
However, bind-4.8.3 does not contain similar code in its named-xfer.c.
I do not know specifically, where in bind's history this check was
added, nor do I know for certain that there is no analogous check
_somewhere_ in 4.8.3, in another form, by another name. I gather many
vendors have DNS code derived from pretty early versions of bind, tho.
