jamesv
Premium
join:2003-03-08
Austin, TX
| reply to dslpartner
Re: [z70] DoxPara port de-randomization / DNS cache poisoning?
The full report on this particular problem isn't public yet as we're still in the window to get it fixed. But enough credible people believe it's real (ISC, etc) I'm buying it until the full disclosure in a couple of weeks.
In the SPI case getting past it with UDP just means you need to correctly predict the port number a DNS query will come from next and blindly send a packet there. DNS queries have a 16-bit tag so that the query source can reject bogus replies but apparently that's not enough. And since the NAT makes the source port extremely predictable there's a problem...
The traffic is "valid" or it would be easy for the DNS query source to reject bogus replies. The traffic is forged and until DNSSEC is deployed all that can be done is to make this attack much harder by increasing the number of bits of randomness from 16-bits (the DNS packet tag) to, say, 31 bits (16 bits from the tag and 15 from the source port number).
ZyXel probably need not randomize the port: just add a short-circuit to the existing WAN port allocation code that says "if the LAN source port number is not allocated as a WAN source port, allocate it instead of using the clock-hand to find a new WAN port number" (in other words, don't remap port numbers unless there is actually a need to do so).
This approach is also unlikely to introduce new problems since one assumes the source ports numbers used by LAN hosts are reasonable to use on the WAN.
ZyXel needs to roll out firmware updates anyway to fix the internal DNS server since many people use that. Might as well fix port remapping at the same time. |
