[ntp:hackers] Security and binding to IP addresses
brad at stop.mail-abuse.org
Mon Feb 28 12:18:47 PST 2005
At 10:18 AM -0800 2005-02-28, John Pettitt wrote:
> On a higher level there is a general principle that applications should
> not bind to network addresses without being told to - no matter how good
> the internal controls in the app are (e.g restrict) it's always better
> to not talk to the intruder at all rather then listen then try to ignore
> (particularly with a spoofable protocol like UDP).
While I may agree with the general principle of not binding to
any address you're not specifically told to bind to, I think we've
also got to consider POLA violations as well.
Virtually every TCP/IP service I can think of has by default
automatically bound to INADDR_ANY (or otherwise done the operational
equivalent of binding to all available addresses), and has done so as
far back as my memory goes -- at least back into the mid-80s, and
probably quite a bit further back than that. It has been a
relatively recent modification of system behaviour to take the more
conservative approach, and I think a lot of people could be seriously
burned if we made that kind of a change too quickly.
> This brings up the issue of listening for replies from remote servers
> that ntpd queries - there is no reason for the requests to come from 123
> if ntp is only a client (not symmetric mode). A fact clearly
> demonstrated by the lare number of servers behind NAT devices.
I think it would be a good idea to put the system changes in
place so that we could specify what addresses to bind to, and I could
also support a protocol change to allow us to use "non-standard"
ports as an option. After all, most other programs I know of will
allow you to run them on whatever port you want -- the port number is
a de facto standard, but the protocol should be capable of running on
any port you choose.
However, I think we need to be really careful and deliberate
about doing those kinds of things by default.
> Danny makes the point that fixing this would require a major rewrite -
> this may be true but it doen't change the underlying wisdom of doing
> so. I'm not sying this is a "drop everying and fix it" issue - just
> that it should proably be fixed in the long term.
I'm not disagreeing with you, but I am saying that I think we
have higher priorities at the moment, and that when the time comes to
do this work, we should be extra careful about changing the default
behaviour of the programs.
Brad Knowles, <brad at stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/> for more info.
More information about the hackers