[dns-operations] .fr has 5 DNSKEYs

[Warren Kumari]

On Jun 4, 2011, at 1:47 PM, Brett Frankenberger wrote:

> On Sat, Jun 04, 2011 at 06:34:03PM +0200, Stephane Bortzmeyer wrote:
>> On Wed, Jun 01, 2011 at 05:18:03PM +0100,
>> George Barwood <george.barwood at blueyonder.co.uk> wrote 
>> a message of 20 lines which said:
>> 
>>> Fragmented UDP responses are especially vulnerable to spoofing,
>>> because of the way IP fragmentation works. The DNS ID field (and UDP
>>> source port) is only present in the first fragment, so by sending a
>>> spoof non-first fragments an attacker that can predict the IP ID (
>>> which might be possible depending on the underlying IP
>>> implementation ) may be able to spoof a response
>> 
>> I do not see how the attack works: spoofing the non-first fragments is
>> useless since, if you cannot spoof the first one, the packet won't be
>> reassembled and the DNS data won't be accepted by the name server.
>> 
>> Do you have a pointer to a detailed description of this attack?
> 
> I don't have a pointer, and haven't really thought about it before this
> thread.  But the potential attack would seem to be:
> 
> Without fragmentation:
>  (a) Get server to send query for X
>  (b) Send forged response ahead of the actual response.
>  (c) Fail because you didn't guess the DNS ID field and UDP Source Port
> 
> With fragmentation:
>  (a) Get server to send query for X
>  (b) Send forged second fragment ahead of the actual response
>  (c) Client receives first fragment from the actual response
>  (d) Client reassembles the real first fragment and the forged second
>      fragment.  

Nope.

You would need to make the server reply with a response that:
a: is fragmented after the DNS ID field and before the actual data
b: know exactly where the fragmentation would occur (so you could craft your forged response to still reassemble correctly)
and
c: correctly predict the IP Identification field
and (possibly):
d: know the total size and original checksum of the correct response so that you can pad and reverse fudge your packet to make the checksum still be correct…

For a: you would need to make the server fragment after 0x2A and before 0x57 (39 bytes).
If somehow you could make that happen you could probably predict b:
c: is a random 16 bit integer.
d: depending if the receiver does UDP checksums you would need to know the DNS ID anyway to be able to fudge your response to satisfy the checksum…

W


> Note that there's no need for the attacker to
>      successfully predict the DNS ID or UDP Source Port because those
>      are in the legitimate first fragment.  (UDP Checksum could be an
>      issue, but that's not hard to work around if know know what the
>      contents of the real second fragment will be -- you can construct
>      your second fragment to have the same contribution to checksum as
>      the real second fragment would have.)
> 
>     -- Brett
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>