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): ## [email protected] ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
