[ntp:questions] ntpd and network sockets

Rick Jones rick.jones2 at hp.com
Thu Jan 10 18:53:19 UTC 2008


> > I suspect we are thinking of different buffers.  I was talking
> > about the socket buffer - aka SO_RCVBUF - overflowing if ntpd
> > simply bound a socket and never read from it.  I wasn't thinking
> > about a buffer overflow in the ntpd itself.  Just trying to see if
> > ntpd could avoid even doing the partial read of the datagram(s) on
> > the socket.

> Sorry, I missed that. Maybe you know better than me but I would not 
> expect the socket buffer to allow overflow or there would be major 
> problems with all O/S's since anyone can mount an attack to overflow 
> that buffer. I don't know the internals of most IP stacks.

I think you and I are thinking of different sorts of overflows.  In
the case of the SO_RCVBUF and a "socket buffer overflow" all that is
is a datagram arriving, and UDP looking to queue it to the SO_RCVBUF
and noting there isn't enough space to put it there.  UDP will then
simply drop the arriving datagram and increment a counter somewhere in
the stats.

It is not a buffer overflow a la moving too many bytes and overwriting
something.

> > I was wrong when I first said this - there will still be a window
> > where a new IP can be brought-up on the system, and some other
> > process can bind port 123 to that IP before ntpd can get there or
> > traffic to arrive.  Even if ntpd has a socket bound to the
> > wildcard IP.

> Binding to a wildcard address does not prevent another process
> binding to a different IP address that ntpd is not bound. At least I
> don't believe so.

We may be in semi-violent agreement there.  I am just mentioning it as
part of pointing-out that there are no guarantees that ntpd can
preclude other normally priviledged processes from potentially
receving traffic bound for port 123 and some IP address.

rick jones
-- 
denial, anger, bargaining, depression, acceptance, rebirth...
                                     where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com  but NOT BOTH...




More information about the questions mailing list