Mailing List Archive

Hi!

> What I take from this mitigation statement--Use a trustworthy DNS
> resolver which is able to validate the data according to the DNS record
> types--is that if our DNS service is solid, we are not vulnerable. Is this
> accurate, or am I oversimplifying things? The mitigation statement from ZDI
> was much more ominous, but I'm still parsing "network-adjacent attackers".

As far as I know, there was not enough info in the ZDI report to
really have a reproducible test case. So we're all a little bit
in the dark.

See

https://lists.isc.org/pipermail/bind-users/2023-October/107997.html

and follow-ups for a few comments on the topic for bind.

--
pi@opsec.eu +49 171 3101372 Now what ?

--
## 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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 03/10/2023 16:48, Johnnie W Adams via Exim-users wrote:
> What I take from this mitigation statement--Use a trustworthy DNS
> resolver which is able to validate the data according to the DNS record
> types--is that if our DNS service is solid, we are not vulnerable. Is this
> accurate, or am I oversimplifying things?

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)

> The mitigation statement from ZDI
> was much more ominous, but I'm still parsing "network-adjacent attackers".

I wasn't sure about that, either.
--
Cheers,
Jeremy


--
## 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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

D?a 3. októbra 2023 15:48:01 UTC používate? Johnnie W Adams via Exim-users <exim-users@lists.exim.org> napísal:
>Hi, folks,
>
> What I take from this mitigation statement--Use a trustworthy DNS
>resolver which is able to validate the data according to the DNS record
>types--is that if our DNS service is solid, we are not vulnerable. Is this
>accurate, or am I oversimplifying things? The mitigation statement from ZDI
>was much more ominous, but I'm still parsing "network-adjacent attackers".

You may be interested to read independent review of highest issue:

https://labs.watchtowr.com/exim-0days-90s-vulns-in-90s-software/

As confirmed by Jeremy, it is realistic... And now one can do own
conclusion about ZDI marking it 0day and assign it score 9,8.

The questions which comes into my mind: How reliable is ZDI then in
other issues categorization/scoring? What is ZDI trying to achieve?
I will not answe them, as i can only guess, but i will not consider ZDI
as trustworthy source of security issues.

regards


--
Slavko
https://www.slavino.sk/

--
## 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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

D?a 4. 10. o 8:45 Florian Zumbiehl via Exim-users napísal(a):

> 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.

Please, do you want to tell, that having resolver on localhost prevents
to exploit this?

--
Slavko


--
## 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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Wed, Oct 04, 2023 at 10:45:25AM +0200, Slavko via Exim-users wrote:

> > 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.

> Please, do you want to tell, that having resolver on localhost
> prevents to exploit this?

Presumably not only localhost, but also different addresses of
interfaces on the same host.

--
Ian

--
## 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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2023-10-04, Slavko via Exim-users <exim-users@lists.exim.org> wrote:
> D?a 4. 10. o 8:45 Florian Zumbiehl via Exim-users napísal(a):
>
>> 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.
>
> Please, do you want to tell, that having resolver on localhost prevents
> to exploit this?

It does not prevent the exploit, but to execute the exploit you'd need
root permissions, which kind of makes it moot,

--
Jasen.
???????? ????? ???????

--
## 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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

D?a 6. októbra 2023 2:22:10 UTC používate? Jasen Betts via Exim-users <exim-users@lists.exim.org> napísal:

>> Please, do you want to tell, that having resolver on localhost prevents
>> to exploit this?
>
>It does not prevent the exploit, but to execute the exploit you'd need
>root permissions, which kind of makes it moot,

hmm, i still cannot get how "network adjacent" is related to root
privileges. But my head never was good for attacks...

Another thing, which is out of my head, is that discussion about
validating of DNS responses in resolvers ended at "unknown" query
types. But exim's dnsdb allows only limited, well known, types, thus
"unknown" types are unrelated.

BTW, Heiko, i see that discussion with ZDI "continue" on oss-security.
Please, can you from time to time post summary here?

regards


--
Slavko
https://www.slavino.sk/

--
## 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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2023-10-06 Slavko via Exim-users <exim-users@lists.exim.org> wrote:
[...]
> hmm, i still cannot get how "network adjacent" is related to root
> privileges. But my head never was good for attacks...

Hello,
Afaiui the attack will require special DNS packets that would not be
sent out by a real recursive resolver. i.e. the attacker needs to change
these packets directly by being in between the resolver and the machine
hosting exim.

[...]
> BTW, Heiko, i see that discussion with ZDI "continue" on oss-security.
> Please, can you from time to time post summary here?

Until now the discussion there sadly only explains why 3 out of 6
possible issues are still unresolved or not really understood. The
person (?) sending mails from ZDI does not answer any questions but
sends out unrelated canned responses. :-(

cu Andreas

--
## 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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

D?a 6. októbra 2023 16:24:27 UTC používate? Andreas Metzler via Exim-users <exim-users@lists.exim.org> napísal:
>On 2023-10-06 Slavko via Exim-users <exim-users@lists.exim.org> wrote:
>[...]
>> hmm, i still cannot get how "network adjacent" is related to root
>> privileges. But my head never was good for attacks...
>
>Hello,
>Afaiui the attack will require special DNS packets that would not be
>sent out by a real recursive resolver. i.e. the attacker needs to change
>these packets directly by being in between the resolver and the machine
>hosting exim.

Thanks, just to confirm (or summarize):

+ if resolver is in public net (eg. 1.1.1.1) the attacker can be relative anyone
+ if resolver is in LAN (remote host) attacker have to be somewhere inside LAN
+ if resolver is on the same host, attacker have to be root

As addition, the resolver must validate received RR (which is not the
case eg. of dnsmasq). If it doesn't do that, attacker can exploit it by
sending crafted response from its (real) DNS server and again can be
relative anyone.

Right?

(by "relative anyone" i mean mostly, that he must know how)

IMO, if attacker already has root access, he can do many more than
intercept DNS response. Or more precise, it doesn't need to do that,
as he usually can do (near) anything on that host...

BTW, when we cannot be sure, which resolvers are trusted, we have
to start to list the resolvers, which are know as not trusted (in mean
of this issue).

>Until now the discussion there sadly only explains why 3 out of 6
>possible issues are still unresolved or not really understood. The
>person (?) sending mails from ZDI does not answer any questions but
>sends out unrelated canned responses. :-(

Yes, i read that. It is really suspicious, as it seems as they cannot
provide exploit. And if that is true, we have repeat that anywhere,
until they revert particular 0day issue(s).

I asked that summary, just to we (exim users) will be informed
about progress, as not all are subscribed to both. IMO, that
thread should be CC here...

regards


--
Slavko
https://www.slavino.sk/

--
## 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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Fri, Oct 06, 2023 at 06:24:27PM +0200, Andreas Metzler via Exim-users wrote:

> The person (?) sending mails from ZDI does not answer any questions but
> sends out unrelated canned responses. :-(

That's how it seems to me too -- thanks for helping me regain some
self-confidence :-P

Does anyone know who ZDI *is* ? What does the abbreviation stand for?
May they have a conflict of interest in this matter?

--
Ian

--
## 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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Hi!

> Does anyone know who ZDI *is* ? What does the abbreviation stand for?

ZDI stands for zero-day-initiative.

https://www.zerodayinitiative.com/about/
https://nitter.net/thezdi

--
pi@opsec.eu +49 171 3101372 Now what ?

--
## 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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Hi,


Andreas Metzler via Exim-users <exim-users@lists.exim.org> (Fr 06 Okt 2023 18:24:27 CEST):
> Hello,
> Afaiui the attack will require special DNS packets that would not be
> sent out by a real recursive resolver. i.e. the attacker needs to change
> these packets directly by being in between the resolver and the machine
> hosting exim.

Please understand if we do not want to share more details than are known
already to the public.

As far as we understand it currently, if the resolver doesn't check the
responses it gets, we have a problem.

> > BTW, Heiko, i see that discussion with ZDI "continue" on oss-security.
> > Please, can you from time to time post summary here?
>
> Until now the discussion there sadly only explains why 3 out of 6
> possible issues are still unresolved or not really understood. The
> person (?) sending mails from ZDI does not answer any questions but
> sends out unrelated canned responses. :-(

From Exim's side I can assure that we're working on solving the issues
that are related to Exim. (dnsdb, proxy-protocol).

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -