[1577] in WWW Security List Archive
Re: _DNS_ security problems
daemon@ATHENA.MIT.EDU (smb@research.att.com)
Sun Mar 3 01:59:35 1996
From: smb@research.att.com
To: Dan Stromberg <strombrg@hydra.acs.uci.edu>
cc: Rich Salz <rsalz@osf.org>, ekr@terisa.com, www-security@ns2.rutgers.edu
Date: Sat, 02 Mar 96 23:06:12 EST
Errors-To: owner-www-security@ns2.rutgers.edu
Are you saying that the folks working on sendmail are _not_
responsible for knowing the implications of using syslog?
Eric scheduled and deployed a fix - the java team has
apparently scheduled one.
Again, DNS should be made safer - It's just not sensible to be
able to publish information about addresses you've not been
delegated. Again, the bind folks could add a routine that
checks for PTR's (and hope no one is using an old libresolv or
old named.xfer(?)), but this is more taxing for both name
server hardware and application programmers (who can't be
guaranteed to be knowledgeable about all things), than just
going to the source of the problem.
Fools ignore complexity.
Pragmatists suffer it.
Geniuses eliminate it (without creating undue inflexibility).
The sendmail vs. syslog() case and the Java vs. DNS case are not
identical, despite some seeming similarities. In my opinion, Java and
syslog() *must* change, while sendmail *may* change. And changing the
DNS is a separate issue entirely.
Syslog() had to change because it doesn't meet Programming 101 specs.
That is, programs should do sensible things with illegal inputs. At
best, one can claim that programs that are only called by a small
number of privileged (and hence presumably trusted) programs may be
excused from that. Syslog() can be called by anyone -- not just from
the local machine, but by anyone on the Internet -- there's nothing in
the architecture that blocks me from sending packets to your UDP port 514.
And even if you have a firewall blocking me from talking to it directly,
there are any number of programs on your machines that I can (perhaps)
subvert into sending such messages for me -- sendmail, netnews, ftp, uucp,
probably others. The only way to close this hole is to fix syslog.
This also makes it clear why fixing sendmail is at best a bandaid. As
long as it itself doesn't suffer from buffer overflow problems, and as
long as there is no *architectural* limit on syslog messages, it's
perfectly proper to try to log everything, no matter how weird or how
long it is. As a pragmatic matter, it's sometimes easier to install a
new sendmail -- the biggest offender here -- than a new syslog(), but
the root problem was in syslog(), not sendmail. (That both were
written by the same person is testimony to the complexity of
programming. Writing large, complex, correct programs is not just
hard, it's probably impossible -- and that, of course, is why I run
screaming from large complex programs in any sensitive settings.)
Java, on the other hand, chose to rely on the architecture of the DNS
as part of its security definition. That may or may not be a good idea
(well, it's not -- see below); nevertheless, if you're going to rely on
an architecture, you need to understand it and its limits. There is
absolutely nothing in today's DNS that makes this attack illegal. And
in turn that means that there is no reasonable way to prevent it, on an
architectural level, if one is going to rely solely on DNS semantics.
Can the DNS architecture be changed? Sure -- and there's even a change
in progress that will solve part of the problem; see the recent work on
digitally signed DNS records. But I don't think they solve this
problem, because the goal here was to verify the authenticity of the
records by tying the labels -- the record names -- to the
duly-delegated owner of the domain. But if it's my domain, I can put
in any sort of garbage I want, and digitally sign the trash.
Could we make a further change, to demand strict accountability?
Maybe, though it would be pretty tricky. Zones often have to have
foreign A records, for delegation if nothing else. And the case for
this sort of change is much less compelling. I, for one, would oppose
it unless I was presented with a much stronger argument than this Java
incident.
Finally, I should note that relying on the integrity of the DNS is a
poor idea. DNS cache contamination isn't very hard, though bind 4.9.3
goes a long way towards preventing it. See my paper from last June's
Usenix UNIX Security Symposium.
--Steve Bellovin
