Bug#493599: pushing udns into squeeze
* 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.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#493599: pushing udns into squeeze
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 is 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 = 0x (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
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#493599: pushing udns into squeeze
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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#493599: pushing udns into squeeze
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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#493599: pushing udns into squeeze
* 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. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#493599: pushing udns into squeeze
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 Description: Digital signature
