severity 492465 important thanks Hi Robert,
On Monday 28 July 2008 07:27, Robert Edmonds wrote: > python-dnspython isn't a dns cache. it may be susceptible to forgery > resilience issues though. the qid field is explicitly randomized (but > with the standard library rng). Yes - as I understand it, a caching server makes forgery much more worthwhile but given that it's a lot easier to forge a response, even stub resolvers could be targeted successfully. For reference, DSA 1605 is about the (unfixed) glibc stub resolver: http://www.debian.org/security/2008/dsa-1605 > > Could you please look into this and see whether updated packages can and > > should be created for etch/lenny/sid? > > from my testing (by repeatedly calling dns.resolver.query), dnspython > opens a new socket for each query. on my kernel (2.6.25) the source > port numbers appear to be random, but maybe this is a kernel feature > introduced since 2.6.18. Yes, that's probably the kernel feature. > dnspython is a stub resolver, and not a general purpose one at that; i > would prefer to wait for upstream to provide an updated version. Surely a solution from upstream is preferable. Given that: (a) this lib is very specialised and is a stub resolver; (b) kernels in lenny/sid already randomise ports and (c) it reopens a port for each query, I've downgraded it to important. Still, I believe that it's very much desirable to make sure an updated version enters lenny. It is my understanding that fixes for 'important' bugs can get a freeze exception. If we have a clear fix for etch I think we should release it to be safe rather than sorry. > btw, i have another specialized dns package in the archive (adns). do > you know if it needs forgery resilience? From checking the source code I think it has the same issue as here. I'll file an important bug there too. cheers, Thijs
pgpTOb0nssZGI.pgp
Description: PGP signature
