Bug#492698: appears to be vulnerable to cache poisoning attack CVE-2008-1447

2008-08-05 Thread Thijs Kinkhorst
There's now a published exploit explicitly targeting things running adns:
http://milw0rm.com/exploits/6197
I believe it would be good to make an upload soon that makes it clear to users 
that adns should not be used outside trusted environments.


Thijs


pgpCutWCumCHb.pgp
Description: PGP signature


Bug#492698: appears to be vulnerable to cache poisoning attack CVE-2008-1447

2008-07-30 Thread Thijs Kinkhorst
On Tuesday 29 July 2008 23:50, Ian Jackson wrote:
   For secure and reasonable operation you MUST run a full-service
   nameserver on the same system as your adns applications, or on the
   same local, fully trusted network.  You MUST only list such
   nameservers in the adns configuration (eg resolv.conf).

Thanks, Ian.

Robert - I think the best course of action now is to document this property in 
the package; the referenced INSTALL file is not currently in the binary 
packages. I suggest adding a shorter note to the package description and 
perhaps this longer explanation from the INSTALL to a file under /u/s/d/, 
e.g. README.security.


cheers,
Thijs


pgpaGsFJhHYDP.pgp
Description: PGP signature


Bug#492698: appears to be vulnerable to cache poisoning attack CVE-2008-1447

2008-07-30 Thread Thijs Kinkhorst
I wrote:
 perhaps this longer explanation from the INSTALL to a file under /u/s/d/,
 e.g. README.security.

That should be README.Debian.


Thijs




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#492698: appears to be vulnerable to cache poisoning attack CVE-2008-1447

2008-07-29 Thread Ian Jackson
Robert Edmonds writes (Re: Bug#492698: appears to be vulnerable to cache 
poisoning attack CVE-2008-1447):
 [ CC'ing Ian. ]
 Ian, are you planning a fix for this?

The short answer is no, not in any reasonable timescale.  It's not
even clear whether a fix is possible for a stub resolver, which
typically doesn't have the luxury of a whole IP address to itself and
which can't reasonably allocate thousands of ports.

adns has always used entirely predictable sequence numbers and expects
that the path between it and the nameserver does not permit an
attacker to inject spoofed packets that appear to come from the
nameserver.  Quoting the source:

  setup.c:  ads-nextid= 0x311f;

This is documented in INSTALL:

  SECURITY AND PERFORMANCE - AN IMPORTANT NOTE

  adns is not a `full-service resolver': it does no caching of responses
  at all, and has no defence against bad nameservers or fake packets
  which appear to come from your real nameservers.  It relies on the
  full-service resolvers listed in resolv.conf to handle these tasks.

  For secure and reasonable operation you MUST run a full-service
  nameserver on the same system as your adns applications, or on the
  same local, fully trusted network.  You MUST only list such
  nameservers in the adns configuration (eg resolv.conf).

  You MUST use a firewall or other means to block packets which appear
  to come from these nameservers, but which were actually sent by other,
  untrusted, entities.

  Furthermore, adns is not DNSSEC-aware in this version; it doesn't
  understand even how to ask a DNSSEC-aware nameserver to perform the
  DNSSEC cryptographic signature checking.


Ian.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#492698: appears to be vulnerable to cache poisoning attack CVE-2008-1447

2008-07-29 Thread Robert Edmonds
Ian Jackson wrote:
 [snip]

this seems mostly reasonable to me and this mirrors the recommendation
in DSA-1605-1.

-- 
Robert Edmonds
[EMAIL PROTECTED]


signature.asc
Description: Digital signature


Bug#492698: appears to be vulnerable to cache poisoning attack CVE-2008-1447

2008-07-28 Thread Thijs Kinkhorst
Package: adns
Version: 1.4-0.1
Severity: important
Tags: security

Hi,

From inspecting the code of ands, it seems that it is not using the
recommended source port randomisation for countering the cache poisoning
attack as discovered by Dan Kaminski and referenced as CVE-2008-1447.

Since this is a stub resolver the risk is lesser than for caching nameservers, 
but nonetheless this is an issue which we really should be fixing in lenny. 
Can you please look into that? As it seems a fix for important bugs can still 
be granted a freeze exception.

If a straghtforward fix is available for etch, it would be released by the 
security team.

thanks,
Thijs


pgpZA6EejRLE9.pgp
Description: PGP signature


Bug#492698: appears to be vulnerable to cache poisoning attack CVE-2008-1447

2008-07-28 Thread Robert Edmonds
[ CC'ing Ian. ]

Ian, are you planning a fix for this?

the relevant recommendations, btw, are available in an ietf draft rfc:

http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience

Thijs Kinkhorst wrote:
 Package: adns
 Version: 1.4-0.1
 Severity: important
 Tags: security
 
 Hi,
 
 From inspecting the code of ands, it seems that it is not using the
 recommended source port randomisation for countering the cache poisoning
 attack as discovered by Dan Kaminski and referenced as CVE-2008-1447.
 
 Since this is a stub resolver the risk is lesser than for caching 
 nameservers, 
 but nonetheless this is an issue which we really should be fixing in lenny. 
 Can you please look into that? As it seems a fix for important bugs can still 
 be granted a freeze exception.
 
 If a straghtforward fix is available for etch, it would be released by the 
 security team.
 
 thanks,
 Thijs

-- 
Robert Edmonds
[EMAIL PROTECTED]


signature.asc
Description: Digital signature