From: Rick Jones <rick.jones2@hp.com>
To: panther@balabit.hu
Cc: netdev@vger.kernel.org
Subject: Re: UDPv4 port allocation problem
Date: Thu, 23 Aug 2007 10:04:23 -0700 [thread overview]
Message-ID: <46CDBE17.7080909@hp.com> (raw)
In-Reply-To: <46CD3462.2070403@balabit.hu>
Tóth László Attila wrote:
> Hello,
>
> I noticed that it is possible that the kernel allocates the same UDP
_Which_ kernel - or rather which rev? There are lots of linux kernels
potentially out there...
> port to an application that was used and closed immediately before the
> new application got it. This means that applications that do not specify
> an exact port and rely on the kernel to allocate a port for them might
> see traffic originally meant for another application.
>
> Imagine that two applications want to resolve a name in DNS at about the
> same time. The following happens:
> * first app sends out the DNS query then closes the socket without
> waiting for an answer (e.g. it got interrupted by Ctrl+C)
> * second app opens an UDP socket, and gets the same port, originally
> assigned to app#1, sends out the DNS query
> * DNS server responds, the response goes to app#2
>
> DNS might not be the perfect example, but you get the idea.
> Applications do not expect to receive data on newly opened sockets, not
> to mention the security implications.
Actually, all applications using UDP are required to cope with just about
anything since there are no guarantees with UDP of anything other than the
checksum generally protecting one from corrupt data.
In the specific case of DNS, the resolver library will (damn well better) be
checking the answer it gets against the query it sent. There will be a
transaction ID check, and IIRC a check of the returned query against the query sent.
> TCP on the other hand increases the allocated port number for each new
> socket, the same behaviour for UDP would add certain amount of time that
> decreases this risk.
Does it always? If you wait for the length of TIME_WAIT before issuing another
bind() request does the port number still increase?
While it might be nice to step through the anonymous port space in some fashion
(I suspect the argument would be made that it should be somewhat random to
preclude guessing from the outside), applications using UDP are still required
to expect the unexpected wrt data arriving on their socket.
rick jones
>
> Is the current behaviour intended?
>
> Regards,
> Laszlo Attila Toth
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2007-08-23 17:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-23 7:16 UDPv4 port allocation problem Tóth László Attila
2007-08-23 17:04 ` Rick Jones [this message]
2007-08-23 18:32 ` [PATCH] udp: randomize port selection Stephen Hemminger
2007-08-25 6:10 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46CDBE17.7080909@hp.com \
--to=rick.jones2@hp.com \
--cc=netdev@vger.kernel.org \
--cc=panther@balabit.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).