Skip Menu |

This queue is for tickets about the Net-DNS CPAN distribution.

Report information
The Basics
Id: 23961
Status: resolved
Priority: 0/
Queue: Net-DNS

People
Owner: Nobody in particular
Requestors: hjp [...] hjp.at
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in:
  • 0.57
  • 0.58
  • 0.59
Fixed in: (no value)



Subject: id sequence is predictable and the same in all child processes.
The sequence of ids is determined in Net::DNS::Header.pm: { my $id = int rand(MAX_ID); sub nextid { return $id++ % (MAX_ID + 1); } } This sets $id when the Module is used. After that it is simply incremented. This has two negative consequences: 1) The sequence is easily predictable which simplifies DNS spoofing attacks. 2) If Net::DNS is used in a forking server, it will normally be used in the parent process. Unless the parent process makes DNS queries between accepting requests, each child will start with the same value of $id and go through the same sequence of ids. Since the source port may also be fixed (at least on some Linux systems, although I don't yet understand why), it is quite possible that one child may receive an answer to a query sent by a previous child. This has been noticed with qpsmtp and spamassassin. See the thread starting at http://www.nntp.perl.org/group/perl.qpsmtpd/;msgid=20060314190403.GC19939[at]teal.hjp.at and http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3D3997 Fix (proposed by Robert Spier in http://www.nntp.perl.org/group/perl.qpsmtpd/;msgid=87ac1o9o7k.wl_rs[at]pobox.com) : Just return a random id: sub nextid { return rand(MAX_ID); }
From: hjp [...] hjp.at
On Sa. 16. Dez. 2006, 15:48:10, hjp@hjp.at wrote: Show quoted text
> 2) If Net::DNS is used in a forking server, it will normally be used > in > the parent process. Unless the parent process makes DNS queries > between > accepting requests, each child will start with the same value of $id > and > go through the same sequence of ids. Since the source port may also be > fixed (at least on some Linux systems, although I don't yet understand > why), it is quite possible that one child may receive an answer to a > query sent by a previous child.
Attached a script which demonstrates the problem: The ids are the same in each child.
Download net-dns-id-sequence-demo
application/octet-stream 785b

Message body not shown because it is not plain text.

Subject: Re: [rt.cpan.org #23961] id sequence is predictable and the same in all child processes.
Date: Sun, 17 Dec 2006 15:19:10 +0100
To: bug-Net-DNS [...] rt.cpan.org
From: "Olaf M. Kolkman" <olaf [...] dacht.net>
Good point! I am embarrassed I did never 'notice' before. I'll fix this in a next release (may take a while to appear). --Olaf On 16Dec 2006, at 9:48 PM, Peter J. Holzer via RT wrote: Show quoted text
> > Sat Dec 16 15:48:10 2006: Request 23961 was acted upon. > Transaction: Ticket created by hjp@hjp.at > Queue: Net-DNS > Subject: id sequence is predictable and the same in all child > processes. > Broken in: 0.57, 0.58, 0.59 > Severity: Important > Owner: Nobody > Requestors: hjp@hjp.at > Status: new > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=23961 > > > > The sequence of ids is determined in Net::DNS::Header.pm: > > { > my $id = int rand(MAX_ID); > > sub nextid { > return $id++ % (MAX_ID + 1); > } > } > > > This sets $id when the Module is used. After that it is simply > incremented. This has two negative consequences: > > 1) The sequence is easily predictable which simplifies DNS spoofing > attacks. > > 2) If Net::DNS is used in a forking server, it will normally be > used in > the parent process. Unless the parent process makes DNS queries > between > accepting requests, each child will start with the same value of > $id and > go through the same sequence of ids. Since the source port may also be > fixed (at least on some Linux systems, although I don't yet understand > why), it is quite possible that one child may receive an answer to a > query sent by a previous child. > > This has been noticed with qpsmtp and spamassassin. See the thread > starting at > http://www.nntp.perl.org/group/ > perl.qpsmtpd/;msgid=20060314190403.GC19939[at]teal.hjp.at > and > http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3D3997 > > Fix (proposed by Robert Spier in > http://www.nntp.perl.org/group/perl.qpsmtpd/;msgid=87ac1o9o7k.wl_rs > [at]pobox.com) > : > > Just return a random id: > > sub nextid { > return rand(MAX_ID); > } > >
------------------------------------------------------ Ik dacht net... heel even maar.
Download PGP.sig
application/pgp-signature 227b

Message body not shown because it is not plain text.

Resolved on the trunk, from the changes file: |Fix rt 23961 | Randomized the ID on the queries. Thanks to "hjp" for reporting and | sugesting a fix. | | The randomization of the src port is supposed to be handled by the | setting the source port to "0" (default). Overriding the default | or using persistent sockets may be problematic. | | Also see: | http://www.potaroo.net/ietf/idref/draft-hubert-dns-anti-spoofing/ Let me know what to fill in for "hjp" :-)
Resolved on the trunk, from the changes file: |Fix rt 23961 | Randomized the ID on the queries. Thanks to "hjp" for reporting and | sugesting a fix. | | The randomization of the src port is supposed to be handled by the | setting the source port to "0" (default). Overriding the default | or using persistent sockets may be problematic. | | Also see: | http://www.potaroo.net/ietf/idref/draft-hubert-dns-anti-spoofing/ Let me know what to fill in for "hjp" :-)
Resolved on the trunk, from the changes file: |Fix rt 23961 | Randomized the ID on the queries. Thanks to "hjp" for reporting and | sugesting a fix. | | The randomization of the src port is supposed to be handled by the | setting the source port to "0" (default). Overriding the default | or using persistent sockets may be problematic. | | Also see: | http://www.potaroo.net/ietf/idref/draft-hubert-dns-anti-spoofing/ Let me know what to fill in for "hjp" :-)
Resolved on the trunk, from the changes file: |Fix rt 23961 | Randomized the ID on the queries. Thanks to "hjp" for reporting and | sugesting a fix. | | The randomization of the src port is supposed to be handled by the | setting the source port to "0" (default). Overriding the default | or using persistent sockets may be problematic. | | Also see: | http://www.potaroo.net/ietf/idref/draft-hubert-dns-anti-spoofing/ Let me know what to fill in for "hjp" :-)
Resolved on the trunk, from the changes file: |Fix rt 23961 | Randomized the ID on the queries. Thanks to "hjp" for reporting and | sugesting a fix. | | The randomization of the src port is supposed to be handled by the | setting the source port to "0" (default). Overriding the default | or using persistent sockets may be problematic. | | Also see: | http://www.potaroo.net/ietf/idref/draft-hubert-dns-anti-spoofing/ Let me know what to fill in for "hjp" :-)
Patch made it into release 0.60