Information leakage via update prereqs (was: Consistent error message in named.log )
Paul Vixie
Paul_Vixie at isc.org
Mon Jul 2 17:02:28 UTC 2007
Chris Thompson <cet1 at hermes.cam.ac.uk> writes:
> > Also prerequisites are processed before any acls according to RFC 2136
> > which is why you see these even when updates are denied for everyone.
>
> That is, section 3.3 comes after section 3.2. But the RFC seems not to
> provide justifcation as to why the authorisation check must not be done
> earlier.
the editor slipped up. there had been a request to move authorization to
be earlier in the flow, but it didn't get changed and the lack of a fix
wasn't noticed during WGLC.
> The result is that update attempts can be used to find out some details of
> zones to which the requestor does not have query access. (I experimented
> with a zone with "allow-query{none;};".) By seeing whether the return code
> is {Y,N}X{DOMAIN,RRSET} rather than REFUSED, a client can see whether a
> domain name exists, if so whether it has RRs of a particular type, if so
> whether they (collectively) do or do not match some guessed values.
>
> This doesn't seem a very serious security issue, but it gives me an uneasy
> feeling.
yes.
--
Paul Vixie
More information about the bind-users
mailing list