BIND ignores queries from specific privileged source ports

[Grant Taylor]

On 6/10/19 4:56 PM, Mark Andrews wrote:
> Named is already selective about what it doesn’t reply to.
> 
> * Packets < 12 octets (DNS header size) don’t get a reply.
> * QR=1 doesn’t get a reply.
> * Source port 0 doesn’t get a reply (source port 0 is “discard me”).
> * Kpasswd doesn’t get FORMERR.
> * echo, chargen, time and daygen don’t get a reply.
> 
> The last 2 sets have been used in reflection attacks in the past.

Would those reflection attacks work today with BIND's current filtering 
(save for filtering source port)?

I don't understand how an incoming packet from chargen, time, or daygen 
could be interpreted as valid DNS queriy.  I guess a specially crafted 
packet from echo /might/ conceptually be able to be interpreted as a DNS 
query.  I would be shocked if anything from kpasswd could be interpreted 
as a DNS query.

I can see how any of these might elicit format error reply from BIND. 
But I feel like filtering a format error reply based on the handful of 
ports would allow legitimate queries from said ports.

> Traffic loops don’t spontaneously come into existence.

ACK

I was more thinking more along the lines of:

1)  Attacker spoofs the source of something that will elicit a format error.
2)  BIND receives the packet and sends a format error to echo.
3)  Echo receives the format error and echo it back BIND.
4)  GOTO 2

> There are also very few UDP services.
> 
> As for the replies named process.  There has to be a outstanding
> request from the source port to the destination port.  QR must be
> 1 for it to be processed.  The qid must also be outstanding for
> that source and destination port tuple.  The packet must also be
> well formed.  The question section must also match the query for
> none error responses.

I don't see how BIND would even get into a situation where it might have 
something to send without all of that being true.

I would also think that anything that wasn't a legitimate DNS request 
would have never made it to the point that there was a reply to 
potentially be sent out.

I'm guessing there is history that I'm completely ignorant of.  I hope 
that a lot of things have changed since then that I'm ignorant of.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190610/27280509/attachment.bin>