Hi,
> It's in that vein, but not quite. The issue pointed to by ZDI was the trusting
> of the "chunk sizes" for the possibly multiple chunks of an RR, versus the whole
> RR size.
>
> An opinion from another (non-Exim, but a name I recognize) dev was
> - yes there's at least one resolver out there that doesn't check these
> - this would pass straight though glibc (ie, my inference: libc does not check this)
It kinda can't because it can't know the syntax of all future RR types. Of
course, it could for already specified types, but then, it would be a weird
interface to specify that the syntax of some RR types will be checked, and
for others it won't, and which ones will be checked depends on the
version ... it makes way more sense to just pass it through and let the
application deal with it, as the application obviously has to know the
syntax of the types that it is requesting.
After all, that's the whole point why the encoding of RRs in DNS messages
has a size field at all--it's to enable forward compatibility in the
resolver infrastructure. The RR data encoding is usually self-terminating,
so the size field wouldn't really be needed for known RR types.
> > The mitigation statement from ZDI
> > was much more ominous, but I'm still parsing "network-adjacent attackers".
>
> I wasn't sure about that, either.
I am not sure whether I am understanding you correctly here, but if you are
wondering what a "network-adjacent attacker" is, that's an attacker that
has access to the network that the victim machine is on. I.e., presumably,
their thinking in this case was that this probably usually isn't
exploitable remotely because exim will usually be talking to a recursive
resolver that'll usually validate the syntax of RRs and will usually not
send otherwise invalid or in any other way attacker-controlled DNS
responses--however, if that recursive resolver is on a different machine
than exim itself, which probably is a common setup, then an attacker with
access to the same local network can just send exim faked DNS responses
ahead of the recursive resolver to exploit the vulnerability.
Regards, Florian
--
## subscription configuration (requires account):
##
https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
