[1536] in WWW Security List Archive
_DNS_ security problems
daemon@ATHENA.MIT.EDU (Dan Stromberg)
Sun Feb 25 14:59:36 1996
Date: Sun, 25 Feb 1996 08:26:20 -0800 (PST)
From: Dan Stromberg <strombrg@test34a.acs.uci.edu>
To: EKR <ekr@terisa.com>
cc: www-security@ns2.rutgers.edu, ekr@itech.terisa.com, smb@research.att.com
In-Reply-To: <199602241809.KAA13793@itech.terisa.com>
Errors-To: owner-www-security@ns2.rutgers.edu
Saying java is responsible for fixing this problem, is like saying
sendmail is responsible for fixing the syslog problem. Eric added a fix
for the syslog problem in sendmail, and he should be commended for it,
but that doesn't fix the syslog problem for other programs that use
syslog. The heart of the problem is in the (old, BSD-derived) C library's
syslog routines.
In this case, yes, a fix for this should be added to java, and if sun
chooses to do so, it should be commended for it, but that is only _because_
DNS is insecure. The DNS should still be fixed, it's just a longer-term,
(much) more time-consuming fix. If there is no longer a list of what
addresses have been delegated where (ahhh shortsightedness!), an effort
to (re)build the information should be mounted; Ensure a hierarchy of
machines providing a canonical list (in distributed manner) of who can
legitimately advertise what addresses and names (covers A, CNAME, MX,
whatever), and check for validity when moving up the tree. You can lie
about your own HINFO's if you want, in practice they aren't highly
accurate anyway.
Explicit, case-by-case, overrides should be made available, to
handle the EIS/ftp situation you've outlined (or just use their name/ip
when using their resources). By analogy, you should be _allowed_ to make
your files mode 777, but this should not be the default. Instead, you
should use something like 770, or establish an ACL (posix style).
These changes could probably be phased in with remote-syslog'd diagnostics
and eventual cutoffs, over a period of 2 to 10 years after implementation.
This has become an issue for the bind list, not www-security.
(But that's the way it's always been! We can't _change_ it! ...or can we?)
