[ i am CC'ing the upstream author, Bob Halley.  Bob, are you planning a
fix to bring dnspython in line with forgery-resilience? ]

Thijs Kinkhorst wrote:
> 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.

right.

> For reference, DSA 1605 is about the (unfixed) glibc stub resolver:
> http://www.debian.org/security/2008/dsa-1605

i saw that, and the same mitigation technique will work.

> > > 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.

do you know when the linux kernel added ephemeral port randomization?
i looked, but could not find it.  does the 'etchnhalf' kernel support
it?

> > 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

-- 
Robert Edmonds
[EMAIL PROTECTED]

Attachment: signature.asc
Description: Digital signature

Reply via email to