Hi
I'm forwarding this from the (DJB-) DNS mailing list, since one of the more
knowledgeable guys there disagrees with CERT, saying that the problem
doesn't lie in the DNS packets, but in the resolver library alone and that
inserting a DNS cache won't necessarily help. But read itfor yourself (and
sorry about Lookout's crappy quoting):
> -----Original Message-----
> From: Jonathan de Boyne Pollard [mailto:J.deBoynePollard@tesco.net]
> Sent: Thursday, June 27, 2002 23:39
> To: DJBDNS Mailing List
> Subject: Re: Packet reconstructioni
>
>
> DP> The point is, of course, that if the packet is reconstructed
> DP> the padding bytes will be different from the original reply,
> DP> and this may help to spoil attacks; [...]
>
> DNS datagrams do not contain "padding bytes", nor do they
> have alignment
> requirements. The only padding and alignment that is
> involved here is that in
> the in-memory data structures passed between the BIND DNS
> Client library, that
> is shipped with the C library, and applications.
>
> The idea of interposition of a proxy DNS server as a local
> fix is, if my
> understanding of the problem is correct, somewhat a red
> herring, by the way.
> From what scant detail is available, the problem _appears_ to
> be an error in
> how the BIND DNS Client library uncompresses into in-memory
> data structures
> the compressed DNS datagrams that it has received. Assuming
> this to be the
> case:
>
> Even if the proxy DNS server has constructed the DNS datagram
> that it sends to
> the DNS client from scratch, as long as that datagram
> contains the same
> sequence of resource record sets in the same order as the
> original "malicious"
> DNS datagram received from the "attacking" content DNS server did, the
> uncompression bug in the BIND DNS Client library will be
> triggered. The
> notion of "reconstructed datagrams" somehow saving the day is
> therefore an
> entirely misleading one. One can reconstruct the datagrams
> as much as one
> likes. As long as the reconstructed datagrams still contain
> the exact same
> data, they will be exactly the same, and they will still
> trigger the BIND
> uncompression bug in the same way. The thing that _actually_
> saves the day
> (inasmuch as it does at all) in practical terms is that
> "dnscache" does _not_
> send the same sequence of resource record sets in the same
> order to DNS
> clients as it received from content DNS servers in answers to
> its back end
> queries. "dnscache" does not send along "NS" records in the
> "authority"
> section and "A" records in the "additional" section (because
> as far as DNS
> clients are concerned, they are so much extraneous chaff).
> "dnscache" sends
> just the resource record sets that answer the question that
> was asked by the
> client. This saves the day to the extent that the DNS data
> produced by an
> "attacking" content DNS server, in order to exploit the BIND
> DNS Client
> library uncompression bug, must contain the exploit trigger
> entirely within
> the resource records that form the actual answer to a query,
> which might turn
> out to be quite difficult for an attacker to achieve.
Cheers
Tobias
