Debian Bug report logs - #493599
Transaction ID and Source Port not random enough

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Thadeu Lima de Souza Cascardo <cascardo@minaslivre.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Transaction ID and Source Port not random enough

Date: Sun, 3 Aug 2008 11:42:27 -0300

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Package: udns
Subject: udns: Transaction ID and Source Port not random enough
Version: 0.0.9-2
Severity: grave
Tags: security

Consecutive queries use the same initial fixed random port and
consecutive transaction IDs. This allow exploits using spoofing, as
described in CVE-2008-1447, related to bind and others.

- - - -- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.26 (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkiVw9MACgkQyTpryRcqtS0pYQCcDee7Sb4lk/Q+EPnlbh6ZE6eR
qAUAoIK5L3GexOc5NUXGHhmrsDjge9Nn
=8APJ
-----END PGP SIGNATURE-----

Message #10 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Thadeu Lima de Souza Cascardo <cascardo@minaslivre.org>

To: 493599@bugs.debian.org

Subject: Rationale for Sequential Transaction ID

Date: Sun, 3 Aug 2008 12:39:50 -0300

[Message part 1 (text/plain, inline)]

I've checked that TIDs and source ports are not random enough dumping
the traffic using dnsget. Then, reading the code so I could fix it, I
found the rationale from Michael Tokarev, which I reproduce below.

  /* this is how we choose an identifier for a new query (qID).
   * For now, it's just sequential number, incremented for every query, and
   * thus obviously trivial to guess.
   * There are two choices:
   *  a) use sequential numbers.  It is plain insecure. In DNS, there are two
   *   places where random numbers are (or can) be used to increase security:
   *   random qID and random source port number.  Without this randomness
   *   (udns uses fixed port for all queries), or when the randomness is weak,
   *   it's trivial to spoof query replies.  With randomness however, it
   *   becomes a bit more difficult task.  Too bad we only have 16 bits for
   *   our security, as qID is only two bytes.  It isn't a security per se,

n those 16 bits - an attacker can just flood us with fake
   *   replies with all possible qIDs (only 65536 of them), and in this case,
   *   even if we'll use true random qIDs, we'll be in trouble (not protected
   *   against spoofing).  Yes, this is only possible on a high-speed network
   *   (probably on the LAN only, since usually a border router for a LAN
   *   protects internal machines from packets with spoofed local addresses
   *   from outside, and usually a nameserver resides on LAN), but it's
   *   still very well possible to send us fake replies.
   *   In other words: there's nothing a DNS (stub) resolver can do against
   *   spoofing attacks, unless DNSSEC is in use, which helps here alot.
   *   Too bad that DNSSEC isn't widespread, so relying on it isn't an
   *   option in almost all cases...
   *  b) use random qID, based on some random-number generation mechanism.
   *   This way, we increase our protection a bit (see above - it's very weak
   *   still), but we also increase risk of qID reuse and matching late replies
   *   that comes to queries we've sent before against new queries.  There are
   *   some more corner cases around that, as well - for example, normally,
   *   udns tries to find the query for a given reply by qID, *and* by
   *   verifying that the query DN and other parameters are also the same
   *   (so if the new query is against another domain name, old reply will
   *   be ignored automatically).  But certain types of replies which we now
   *   handle - for example, FORMERR reply from servers which refuses to
ss EDNS0-enabled packets - comes without all the query parameters
   *   but the qID - so we're forced to use qID only when determining which
   *   query the given reply corresponds to.  This makes us even more
   *   vulnerable to spoofing attacks, because an attacker don't even need to
   *   know which queries we perform to spoof the replies - he only needs to
   *   flood us with fake FORMERR "replies".
   *
   * That all to say: using sequential (or any other trivially guessable)
   * numbers for qIDs is insecure, but the whole thing is inherently insecure
   * as well, and this "extra weakness" that comes from weak qID choosing
   * algorithm adds almost nothing to the underlying problem.
   *
   * It CAN NOT be made secure.  Period.  That's it.
   * Unless we choose to implement DNSSEC, which is a whole different story.
   * Forcing TCP mode makes it better, but who uses TCP for DNS anyway?
   * (and it's hardly possible because of huge impact on the recursive
   * nameservers).
   *
   * Note that ALL stub resolvers (again, unless they implement and enforce
   * DNSSEC) suffers from this same problem.
   *
   * So, instead of trying to be more secure (which actually is not - false
   * sense of security is - I think - is worse than no security), I'm trying
   * to be more robust here (by preventing qID reuse, which helps in normal
   * conditions).  And use sequential qID generation scheme.
   */


I think that using random ports together with the random qIDs may solve
the robustness issue, if you don't have a "collision", which could be
tracked using the queries issued themselves. This is a not a trivial
patch.

So, for now, I would recommend the same recommendations for glibc,
regarding this issue.

Thadeu Cascardo.

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Thomas Viehmann <tv@beamnet.de>

To: 493599@bugs.debian.org

Cc: debian-release@lists.debian.org

Subject: removing udns from lenny?

Date: Fri, 29 Aug 2008 20:46:00 +0200

Hi,

udns has the recent DNS problem in a pretty bad way (i.e. no random, not
even query IDs vs. not enough). And there is no indication that anyone
is working on getting it solved at the moment. (Last upstream release is
Jan 2007, the  upstream mailing list archives have 2007 no activity
since the announcement of that, too.)
As udns is not in wide use across our archive, with only two packages
using it, it might be good to not release it with lenny.
For the two packages:
- jabberd2 is not in testing,
- libapache2-mod-defensible can be compiled without udns.

Even better would be fixing, but I think this might be involved (based
on the "our design doesn't allow for port randomization") ...
Opinions?

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/

Message #20 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Thadeu Lima de Souza Cascardo <cascardo@minaslivre.org>

To: Thomas Viehmann <tv@beamnet.de>, 493599@bugs.debian.org

Cc: debian-release@lists.debian.org

Subject: Re: Bug#493599: removing udns from lenny?

Date: Fri, 29 Aug 2008 19:29:22 -0300

[Message part 1 (text/plain, inline)]

On Fri, Aug 29, 2008 at 08:46:00PM +0200, Thomas Viehmann wrote:
> Hi,
> 
> udns has the recent DNS problem in a pretty bad way (i.e. no random, not
> even query IDs vs. not enough). And there is no indication that anyone
> is working on getting it solved at the moment. (Last upstream release is
> Jan 2007, the  upstream mailing list archives have 2007 no activity
> since the announcement of that, too.)
> As udns is not in wide use across our archive, with only two packages
> using it, it might be good to not release it with lenny.
> For the two packages:
> - jabberd2 is not in testing,
> - libapache2-mod-defensible can be compiled without udns.
> 
> Even better would be fixing, but I think this might be involved (based
> on the "our design doesn't allow for port randomization") ...
> Opinions?
> 
> Kind regards
> 
> T.
> -- 
> Thomas Viehmann, http://thomas.viehmann.net/
> 
> 

Hello.

This bug is likely a WONTFIX for the reasons already pointed out,
because:

a) udns design was intended to make it simple to write an application
using it, which is accomplished by using only one socket. This restricts
it to only one source port for all queries. Introducing random source
port into the code would break its design.

b) The author believes random query IDs would do more harm than
incremental ones, since DNS error responses does not allow to
distinguish the query responded by anything else than the query ID,
which in the case of a collision (which is likely for only 16 bits).
This could break robustness of the software giving only a slight
security.

Despite all this, since some other software have the same or similar
security issues and are also used as stub resolvers (like glibc), we
could do the same that was done for them: release an advisory warning
the users about the possible issues and workarounds (stub resolvers need
a trusted resolver in a trusted network).

However, I think udns should still be left out of stable, since the
upstream author has requested this from me in the last release, because
he believes the software is still experimental (mainly the library
API/ABI).

Best Regards,
Thadeu Cascardo.

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Luk Claes <luk@debian.org>

To: Thadeu Lima de Souza Cascardo <cascardo@minaslivre.org>, 493599@bugs.debian.org

Cc: Thomas Viehmann <tv@beamnet.de>, debian-release@lists.debian.org

Subject: Re: Bug#493599: removing udns from lenny?

Date: Sat, 30 Aug 2008 11:00:15 +0200

Thadeu Lima de Souza Cascardo wrote:
> On Fri, Aug 29, 2008 at 08:46:00PM +0200, Thomas Viehmann wrote:
>> Hi,
>>
>> udns has the recent DNS problem in a pretty bad way (i.e. no random, not
>> even query IDs vs. not enough). And there is no indication that anyone
>> is working on getting it solved at the moment. (Last upstream release is
>> Jan 2007, the  upstream mailing list archives have 2007 no activity
>> since the announcement of that, too.)
>> As udns is not in wide use across our archive, with only two packages
>> using it, it might be good to not release it with lenny.
>> For the two packages:
>> - jabberd2 is not in testing,
>> - libapache2-mod-defensible can be compiled without udns.
>>
>> Even better would be fixing, but I think this might be involved (based
>> on the "our design doesn't allow for port randomization") ...
>> Opinions?
>>
>> Kind regards
>>
>> T.
>> -- 
>> Thomas Viehmann, http://thomas.viehmann.net/
>>
>>
> 
> Hello.
> 
> This bug is likely a WONTFIX for the reasons already pointed out,
...
> However, I think udns should still be left out of stable, since the
> upstream author has requested this from me in the last release, because
> he believes the software is still experimental (mainly the library
> API/ABI).

removal hint added

Cheers

Luk

Message #30 received at submit@bugs.debian.org (full text, mbox, reply):

From: Thomas Viehmann <tv@beamnet.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Re: Bug#493599: removing udns from lenny?

Date: Sat, 30 Aug 2008 13:23:32 +0200

Package: libapache2-mod-defensible
Severity: serious
Version: 1.4-2

Hi Julien,

Debian tries to drop udns from lenny, your package is the only
dependency in testing. Could you rebuild without udns, please?
If you are busy, don't hesitate to reply if you prefer to have the
upload done for you.

Kind regards

T.

Background:
[in udns bug #493599]:
> [udev-maintainer Thadeu Lima de Souza Cascardo]
>> However, I think udns should still be left out of stable, since the
>> upstream author has requested this from me in the last release, because
>> he believes the software is still experimental (mainly the library
>> API/ABI).
> 
> removal hint added
> 
> Cheers
> 
> Luk
-- 
Thomas Viehmann, http://thomas.viehmann.net/

Message #35 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Thomas Viehmann <tv@beamnet.de>

To: debian-release@lists.debian.org

Cc: 493599@bugs.debian.org

Subject: Re: Bug#493599: removing udns from lenny?

Date: Sat, 30 Aug 2008 14:12:44 +0200

Luk Claes wrote:
>> This bug is likely a WONTFIX for the reasons already pointed out,
> ...
>> However, I think udns should still be left out of stable, since the
>> upstream author has requested this from me in the last release, because
>> he believes the software is still experimental (mainly the library
>> API/ABI).
> 
> removal hint added
I filed #497164 for libapache2-mod-defensible.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/

Message #40 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Julien Danjou <acid@debian.org>

To: Thomas Viehmann <tv@beamnet.de>

Cc: debian-release@lists.debian.org, 493599@bugs.debian.org

Subject: Re: Bug#493599: removing udns from lenny?

Date: Wed, 3 Sep 2008 10:55:10 +0200

[Message part 1 (text/plain, inline)]

At 1220098364 time_t, Thomas Viehmann wrote:
> I filed #497164 for libapache2-mod-defensible.

And it has been fixed in 1.4-3, that should probably be unblocked.

Cheers,
-- 
Julien Danjou
.''`.  Debian Developer
: :' : http://julien.danjou.info
`. `'  http://people.debian.org/~acid
  `-   9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD

[signature.asc (application/pgp-signature, inline)]

Message #45 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Luk Claes <luk@debian.org>

To: Julien Danjou <acid@debian.org>, 493599@bugs.debian.org

Cc: Thomas Viehmann <tv@beamnet.de>, debian-release@lists.debian.org

Subject: Re: Bug#493599: removing udns from lenny?

Date: Wed, 03 Sep 2008 19:26:06 +0200

Julien Danjou wrote:
> At 1220098364 time_t, Thomas Viehmann wrote:
>> I filed #497164 for libapache2-mod-defensible.
> 
> And it has been fixed in 1.4-3, that should probably be unblocked.

unblocked

Cheers

Luk

Message #50 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Thadeu Lima de Souza Cascardo <cascardo@minaslivre.org>

To: 493599@bugs.debian.org

Cc: pkg-xmpp-devel@lists.alioth.debian.org, mjt+udns@corpit.ru

Subject: pushing udns into squeeze

Date: Sat, 11 Jul 2009 19:55:43 -0300

[Message part 1 (text/plain, inline)]

Hello, folks.

While udns has no entered etch or lenny, we should reconsider that
situation in the case of squeeze. Some software in Debian depends or may
be improved while depending on udns. libapache2-mod-defensible, for
example, was rebuilt without udns for the lenny release. Now, jabberd2
depends on udns and can only go into a stable release if udns goes too
or udns stops being used by it.

Although Michael didn't think it was ready for release some three years
ago and not a lot has changed in the library since then, it has being
used by these software in response to its usefulness and quality. I
don't know if Michael has reconsidered, but I'd like to know his opinion
as of now.

Regarding the security issue, which Michael has already answered about
in his comments in the source code even before people have published
their exploit results and many servers had their code changed to make
them safer, I don't think udns requires any change.

It's a stub resolver and many other stub resolvers have not changed
anything in response to the announcement of the increased possibility of
an attack. And stub resolvers should use secure servers in a secure
environment/network.

I think we could release some notes in README.Debian regarding this and
close this bug altogether and let udns move into squeeze and keep it
there for the release, allowing other packages to follow, including
jabberd2.

Regards,
Cascardo.

[signature.asc (application/pgp-signature, inline)]

Message #55 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt+udns@corpit.ru>

To: Thadeu Lima de Souza Cascardo <cascardo@minaslivre.org>

Cc: 493599@bugs.debian.org, pkg-xmpp-devel@lists.alioth.debian.org

Subject: Re: pushing udns into squeeze

Date: Sun, 12 Jul 2009 12:12:13 +0400

Thadeu Lima de Souza Cascardo wrote:
> Hello, folks.

Hello.
Thank you for bringing this issue up again.

> While udns has no entered etch or lenny, we should reconsider that
> situation in the case of squeeze. Some software in Debian depends or may
> be improved while depending on udns. libapache2-mod-defensible, for
> example, was rebuilt without udns for the lenny release. Now, jabberd2
> depends on udns and can only go into a stable release if udns goes too
> or udns stops being used by it.
> 
> Although Michael didn't think it was ready for release some three years
> ago and not a lot has changed in the library since then, it has being
> used by these software in response to its usefulness and quality. I
> don't know if Michael has reconsidered, but I'd like to know his opinion
> as of now.

Yes I had plans for udns, but now I don't think I'll ever finish it.
Maybe, who knows, but well...

I'm watching another project, ldns, which is a base for unbound and nsd
nameservers (see www.unbound.net).  It is much more adequate for today,
in my opinion anyway, than my attempt with udns.  And almost as easy to
use as udns, but at the same time much more correct and also supports
DNSSEC out of the box.

> Regarding the security issue, which Michael has already answered about
> in his comments in the source code even before people have published
> their exploit results and many servers had their code changed to make
> them safer, I don't think udns requires any change.

All the (similar) security issues with stub resolvers w.r.t. on LANs
are real issues, unfortunately.  Yes I added that "famous" comment to
the code explaining it (and it was interesting to re-read it today ;)
and noticed that it's very difficult to deal with the issue on LAN
with its speeds.  On LAN, the only way to solve all the issues of this
sort is to use DNSSEC or IPSEC between a stub resolver and nearby
(on the LAN) recursive resolver, or better yet, between local (on
localhost) caching resolver and nearby (on LAN) recursive resolver.
As I mentioned earlier, ldns has DNSSEC support out of the box.

> It's a stub resolver and many other stub resolvers have not changed
> anything in response to the announcement of the increased possibility of
> an attack. And stub resolvers should use secure servers in a secure
> environment/network.
> 
> I think we could release some notes in README.Debian regarding this and
> close this bug altogether and let udns move into squeeze and keep it
> there for the release, allowing other packages to follow, including
> jabberd2.

Given the fact that I did not update the code in all these years (oh
well)...  I've nothing against including udns into Debian anymore.

The only concern I had is that I planned to change the API.  But it
looks like it wont be done and better alternatives emerges.

Thanks!

/mjt

Message #60 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: Thadeu Lima de Souza Cascardo <cascardo@minaslivre.org>

Cc: 493599@bugs.debian.org, pkg-xmpp-devel@lists.alioth.debian.org, mjt+udns@corpit.ru

Subject: Re: Bug#493599: pushing udns into squeeze

Date: Sun, 12 Jul 2009 23:12:24 +0200

* Thadeu Lima de Souza Cascardo:

> While udns has no entered etch or lenny, we should reconsider that
> situation in the case of squeeze. Some software in Debian depends or
> may be improved while depending on udns.

udns doesn't handle truncation, so it won't play well with the
PowerDNS recursor (which doesn't support EDNS).

It does not use a connected UDP socket, so it won't notice ICMP
errors.  (This means that it's only suitable for long-running
processes.)

The escape sequences it uses inside TXT records are hexadecimal, not
decimal, as it is standard for DNS software.

The domain name parser triggers undefined behavior for certain inputs
because it performs out-of-bound pointer arithmetic.  This is unlikely
to cause practical problems with current GCC versions (but LTO might
change this).

Sorry for being unconstructive, but I really don't think we need yet
another DNS resolver in Debian.

Message #65 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@inutil.org>

To: Florian Weimer <fw@deneb.enyo.de>

Cc: Thadeu Lima de Souza Cascardo <cascardo@minaslivre.org>, 493599@bugs.debian.org, pkg-xmpp-devel@lists.alioth.debian.org, mjt+udns@corpit.ru

Subject: Re: Bug#493599: pushing udns into squeeze

Date: Tue, 8 Dec 2009 00:06:18 +0100

On Sun, Jul 12, 2009 at 11:12:24PM +0200, Florian Weimer wrote:
> * Thadeu Lima de Souza Cascardo:
> 
> > While udns has no entered etch or lenny, we should reconsider that
> > situation in the case of squeeze. Some software in Debian depends or
> > may be improved while depending on udns.
> 
> udns doesn't handle truncation, so it won't play well with the
> PowerDNS recursor (which doesn't support EDNS).
> 
> It does not use a connected UDP socket, so it won't notice ICMP
> errors.  (This means that it's only suitable for long-running
> processes.)
> 
> The escape sequences it uses inside TXT records are hexadecimal, not
> decimal, as it is standard for DNS software.
> 
> The domain name parser triggers undefined behavior for certain inputs
> because it performs out-of-bound pointer arithmetic.  This is unlikely
> to cause practical problems with current GCC versions (but LTO might
> change this).
> 
> Sorry for being unconstructive, but I really don't think we need yet
> another DNS resolver in Debian.

Thadeu, since no package uses current udns and upstream recommends
switching to ldns, should we go ahead and remove udns from the
archive?

Cheers,
        Moritz

Message #70 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Jérémy Lal <jerry@edagames.com>

To: 493599@bugs.debian.org

Subject: switching to ldns

Date: Thu, 11 Feb 2010 16:06:28 +0100

[Message part 1 (text/plain, inline)]

Hi,
i'm the maintainer of the nodejs package (in unstable),
and since you're considering dropping udns package,
i'm wondering if it is easy to switch an application that uses udns
to using ldns instead.
Any experience about that ?

Regards,
Jérémy Lal

[signature.asc (application/pgp-signature, attachment)]

Message #75 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Peter Folk <peter@volo.net>

To: 493599@bugs.debian.org

Subject: Jabberd2 still blocked on udns

Date: Thu, 11 Mar 2010 13:30:47 -0600

I wanted to note that since jabberd2 is still blocked by this bug, it 
might help for those wanting jabberd2 to switch away from udns to bump 
or comment on jabberd2's bug: 
https://bugs.launchpad.net/jabberd2/+bug/496824

Peter

Message #80 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Jérémy Lal <jerry@edagames.com>

To: 493599@bugs.debian.org

Subject: nodejs 0.1.94 moved from udns to libc-ares

Date: Fri, 07 May 2010 19:01:26 +0200

That's one less package depending on udns (to be uploaded soon).
The move to c-ares[0] might be instructive for jabberd2.

[0]
http://github.com/ry/node/commit/dc1f4ebd4478b9fe32039d79a553fac01efafcf5

Regards,
Jérémy Lal

Message #85 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: 493599@bugs.debian.org

Subject: Re: Bug#493599: Transaction ID and Source Port not random enough

Date: Wed, 01 Dec 2010 18:44:26 +0300

After several years of silence I'm about to release
a new version of udns, with just one bugfix and a change
from sequentional queue IDs for queries to random, using
a simple pseudo-random number generator by Bob Jenkins.

This affects queueIDs _only_, not source port, because
by design udns uses just one port for all queries.

The whole thing is still inherently insecure, even for
source port randomisation, as has been already said
several times - _all_ "simple" DNS resolves today are
vulnerable to attacks on high-bandwidth network such
as a typical LAN.  So this change is in fact not an
improvement, even if it feels like that.

I also plan to address a few defects and suggestions
I received during all these years.

Not that I'm saying udns should now enter Debian,
just adding some information to the bug report.

Thanks!

/mjt

Message #90 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Thadeu Lima de Souza Cascardo <cascardo@minaslivre.org>

To: Michael Tokarev <mjt@tls.msk.ru>, 493599@bugs.debian.org

Subject: Re: Bug#493599: Transaction ID and Source Port not random enough

Date: Wed, 1 Dec 2010 13:55:45 -0200

[Message part 1 (text/plain, inline)]

On Wed, Dec 01, 2010 at 06:44:26PM +0300, Michael Tokarev wrote:
> After several years of silence I'm about to release
> a new version of udns, with just one bugfix and a change
> from sequentional queue IDs for queries to random, using
> a simple pseudo-random number generator by Bob Jenkins.
> 
> This affects queueIDs _only_, not source port, because
> by design udns uses just one port for all queries.
> 
> The whole thing is still inherently insecure, even for
> source port randomisation, as has been already said
> several times - _all_ "simple" DNS resolves today are
> vulnerable to attacks on high-bandwidth network such
> as a typical LAN.  So this change is in fact not an
> improvement, even if it feels like that.
> 
> I also plan to address a few defects and suggestions
> I received during all these years.
> 
> Not that I'm saying udns should now enter Debian,
> just adding some information to the bug report.
> 
> Thanks!
> 
> /mjt
> 
> 

Thanks, Michael.

I agree that the simplicity of using only one file descriptor is one of
the strengths of udns. Although others have pointed out other problems
with that (absence of TCP support, for example), I'd say udns is a very
good library for stub resolving and it works very well with a full blown
recursive resolver at localhost, like bind.

Regarding the random TID support, will it require more memory
consumption by udns?

I still think udns can pretty much enter Debian, as long as we advise
the user not to use it in a network that is not trusted. Pointing it out
to a localhost recursive resolver should be enough. Perhaps, including a
Recommends for such a resolver would be a plus to indicate that to the
user.

Anyway, good to hear again from you and that you're working in udns.

Regards,
Cascardo.

[signature.asc (application/pgp-signature, inline)]

Message #95 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Florian Weimer <fw@deneb.enyo.de>

Cc: Thadeu Lima de Souza Cascardo <cascardo@minaslivre.org>, 493599@bugs.debian.org, pkg-xmpp-devel@lists.alioth.debian.org

Subject: Re: Bug#493599: pushing udns into squeeze

Date: Wed, 01 Dec 2010 21:13:37 +0300

Replying to an old email from more than a year ago.

I'm about to release a new version of udns, and
thought I'd put some missing dots under "i"s and
address the concerns...

I'm quoting whole thing just to show context, I have
a question for only one point below, with a few short
comments.

13.07.2009 01:12, Florian Weimer wrote:
> 
> udns doesn't handle truncation, so it won't play well with the
> PowerDNS recursor (which doesn't support EDNS).

One of the limitations of simplicity of design - only one
socket and it's obviously UDP.  With deployment of DNSSEC
everywhere EDNS support becomes a requiriment, because of
the size of DNSSEC records, so this problem becomes less
and less of an issue.  Yes I understand this is where
udns does not conform to standards.

> It does not use a connected UDP socket, so it won't notice ICMP
> errors.  (This means that it's only suitable for long-running
> processes.)

When I wrote udns I tried hard to find a way for unconnected
socket to actually receive errors such as ECONNREFUSED when
no listener is present at the destination, and to process them
more or less reliable.  I think nowadays a way to do so
exists at least on linux - or maybe I'm dreaming again.

But even complete lack of error handling like that is
not really problematic - the timeout before trying
next server is just one second.

I don't actually understand this "for long-running processes
only" part too.  Stuff like logresolve (to convert, say,
apache access.log from ip.add.res.ses to domain names
isn't usually long-living.

> The escape sequences it uses inside TXT records are hexadecimal, not
> decimal, as it is standard for DNS software.

This is fixed, and it was only in dnsget utility (which
is something like dig or host).

> The domain name parser triggers undefined behavior for certain inputs
> because it performs out-of-bound pointer arithmetic.  This is unlikely
> to cause practical problems with current GCC versions (but LTO might
> change this).

And here goes my main question.

http://www.corpit.ru/mjt/udns_dn.c is the code in question, the
domain parser.  Florian, can you please tell me where do you think
it performs such oob arith?  I assume you're talking about dns_ptodn()
routine, which converts asciiz (string) representation of a domain
name to on-wire series-of- labels form (the "dn" form).  But I just
don't see where it goes OOB.

The only case I can think of is this: if dp after next input
char points to de (very end of the output buffer), next input
char is dot so we just increment dp and continue, and there's
one more char in input.  In this case dp will be equal to
de+1, and the if condition is triggered for return case.
Simplified code:

  dnsc_t *dp;           /* current position in dn (len byte first) */
  dnsc_t *const de      /* end of dn: last byte that can be filled up */
      = dn + (dnsiz >= DNS_MAXDN ? DNS_MAXDN : dnsiz) - 1;

  while(np < ne) {

    if (*np == '.') {   /* label delimiter */
      c = dp - llab;            /* length of the label */
      llab[-1] = (dnsc_t)c;     /* update len of last label */
      llab = ++dp; /* start new label, llab[-1] will be len of it */
      ++np;
      continue;
    }

    /* check whenever we may put out one more byte */
    if (dp >= de) /* too long? */
      return dnsiz >= DNS_MAXDN ? -1 : 0;

    /* handle next input character */
  }

So basically, if de = 0xffffffff (on 32bit platform),
i.e. when the output buffer is at the very end of
address space, de+1 is 0, which may be bad.  But this
should never happen in practice.

There are a few other possible candidates for this
oob conclusion - usage of llab[-1].  But there, the
-1th address is always valid due to the way llab is
initialized.

Can you point me to the right direction please?

Thank you!

/mjt

Message #100 received at 493599@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: Thadeu Lima de Souza Cascardo <cascardo@minaslivre.org>, 493599@bugs.debian.org, pkg-xmpp-devel@lists.alioth.debian.org

Subject: Re: Bug#493599: pushing udns into squeeze

Date: Thu, 02 Dec 2010 21:06:21 +0100

* Michael Tokarev:

>> udns doesn't handle truncation, so it won't play well with the
>> PowerDNS recursor (which doesn't support EDNS).
>
> One of the limitations of simplicity of design - only one
> socket and it's obviously UDP.  With deployment of DNSSEC
> everywhere EDNS support becomes a requiriment, because of
> the size of DNSSEC records, so this problem becomes less
> and less of an issue.  Yes I understand this is where
> udns does not conform to standards.



>> The domain name parser triggers undefined behavior for certain inputs
>> because it performs out-of-bound pointer arithmetic.  This is unlikely
>> to cause practical problems with current GCC versions (but LTO might
>> change this).
>
> And here goes my main question.
>
> http://www.corpit.ru/mjt/udns_dn.c is the code in question, the
> domain parser.  Florian, can you please tell me where do you think
> it performs such oob arith?

I think I was referring to loop exit conditions such as:

  while(--s >= (dnscc_t *)addr) {

These are problematic if the compiler can prove that addr does not
point into an array of suitable struct ?_addr objects.

Message #105 received at 493599@bugs.debian.org (full text, mbox, reply):

From: "W. van den Akker" <wvdakker@wilsoft.nl>

To: <493599@bugs.debian.org>

Subject: Transaction ID and Source Port not random enough

Date: Mon, 10 Dec 2012 07:46:00 +0100

[Message part 1 (text/plain, inline)]

 

Hi, 

Version 0.2 of UDNS supports random selection of Transaction
ID and Source Port.
This would 'solve' the RC-bug. 

Not much packages
depens on UDNS, only Jabber2d does. Because Jabber2 won't
migratie to
another DNS-resolver I think UDNS has to continue in Debian. 

I have
uploaded the new package here: http://mentors.debian.net/package/udns
[1] 

Please take a look. 

Greetings, 

Willem vdAkker 



Links:
------
[1] http://mentors.debian.net/package/udns

[Message part 2 (text/html, inline)]

Message #110 received at 493599-close@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: 493599-close@bugs.debian.org

Subject: Bug#493599: fixed in udns 0.2-1

Date: Wed, 19 Dec 2012 21:17:33 +0000

Source: udns
Source-Version: 0.2-1

We believe that the bug you reported is fixed in the latest version of
udns, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 493599@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Tokarev <mjt@tls.msk.ru> (supplier of updated udns package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Wed, 19 Dec 2012 22:43:15 +0400
Source: udns
Binary: libudns0 libudns-dev udns-utils
Architecture: source i386
Version: 0.2-1
Distribution: unstable
Urgency: low
Maintainer: Michael Tokarev <mjt@tls.msk.ru>
Changed-By: Michael Tokarev <mjt@tls.msk.ru>
Description: 
 libudns-dev - async-capable DNS stub resolver library, development files
 libudns0   - async-capable DNS stub resolver library
 udns-utils - Several DNS-related utilities built on top of udns library
Closes: 493599
Changes: 
 udns (0.2-1) unstable; urgency=low
 .
   * new upstream version (Closes: #493599)
   * new maintainer, which is, part-time upstream author.
     Thank you Thadeu Lima for the previous work!
   * removed debian/README which explained that the software is under
     development with non-stabilized API
   * revisited all debian stuff: simplified debian/rules a bit,
     reviewed standards-version and debhelper compat rules,
     made the library multiarch.
Checksums-Sha1: 
 b3eea31e06df12b68a477e7d4e1f6576809ec0c9 1252 udns_0.2-1.dsc
 416da8c95283eae45f6d2e6fb055c4ef765a3f02 87308 udns_0.2.orig.tar.gz
 db4c86b09106e859823a3455b8232261aac35bba 4912 udns_0.2-1.debian.tar.gz
 2342a1d453a38940e937ec826309b6603af17c3f 28072 libudns0_0.2-1_i386.deb
 1b7e2c3efb084c0812001e24f50843cabb15bed1 59404 libudns-dev_0.2-1_i386.deb
 39adf42d42f15555f86a8b773d17c550923b9c4d 24514 udns-utils_0.2-1_i386.deb
Checksums-Sha256: 
 2d5df654ad03de72d31db30634e47b8a6050411e358a7aafe6bc74bc8c9db767 1252 udns_0.2-1.dsc
 558c7d7acc358e13f91f73ba7fef0ed094010716a8dcee286eef05d0ff264224 87308 udns_0.2.orig.tar.gz
 41bbfe9652571a7810d6f660dafd49dca9a0b5824a3606662eb598fa203023ae 4912 udns_0.2-1.debian.tar.gz
 bff855f46f8891a340d8b6031d240124ed5554d407309d0bf94e663d6d929a37 28072 libudns0_0.2-1_i386.deb
 1dfc91f7c7c75b7987c1af01abf8bfef1d56c53f5e92a5d3b7b15bbf60cb8767 59404 libudns-dev_0.2-1_i386.deb
 94a21845bb6395b9b219869aa7027996fd9feb831c89f3fa5c1df4dfc541369e 24514 udns-utils_0.2-1_i386.deb
Files: 
 0299bf301d7865a62a3e8a58837bd079 1252 net optional udns_0.2-1.dsc
 3fdaaef5e0f2ad71624959add1b77995 87308 net optional udns_0.2.orig.tar.gz
 2f1917c0cf434d2147bc13ae8e43bfbb 4912 net optional udns_0.2-1.debian.tar.gz
 00c43e12e99c3d5fa2b3e8fdce45fc8f 28072 libs optional libudns0_0.2-1_i386.deb
 9a440395af6a5e87288b3e2a34535db5 59404 libdevel optional libudns-dev_0.2-1_i386.deb
 5796469739e8122eff89dcc6873a2c87 24514 net optional udns-utils_0.2-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iJwEAQECAAYFAlDSLJoACgkQUlPFrXTwyDhOqwQA2KdTtQ7mGOxNzCkIiixnuRr2
Jc5cY6MubFqt1mBc4DpQVJvXj2WapMTsTFjldXGuHpLJ1TszHwziAlBQKpEFwbnk
AdDv+kw7AndCduimLVCdsGG2xMTb6SEgtbbReUGPpnKJxExfCilnxh0th5UVmYit
heeeyL3GCK0MAIl9IWE=
=HzVZ
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.