Bug#1053310: Fixes for stable/oldstable?

[Andreas Metzler]

On 2023-10-31 Tomas Pospisek <tpo_deb at sourcepole.ch> wrote:
> On Tue, 31 Oct 2023, Salvatore Bonaccorso wrote:
[...]
>> Fixes for CVE-2023-42117 and CVE-2023-42119 are right now considered
>> no-dsa (see comment on the security-tracker about it), and are going
>> to be fixed in the next point releases.

> The notes say:

> ***
> [bookworm] - exim4 <no-dsa> (Only an issue if Exim4 run behind an
>              untrusted proxy-protocol proxy)
[...]
> So I think I can parse from those that CVE-2023-42117 is only critical when
> exim is run behind a "untrusted proxy-protocol proxy".

> Questions if you will:

> * what does "no-dsa" mean? DSA seems to mean Debian Security Announce.
>   Does it mean there is no DSA for that problem yet? What does it mean
>   when a CVE is considered "no-dsa" then? That no DSA will be released for
>   it?

Hello Thomas,

Exactly. The severity was judged to be very low, not "worth" the effort
of a DSA.

> * what is a "untrusted proxy-protocol proxy" in the context of a mail
>   transport agent? So exim shouldn't be used behind an untrusted socks
>   proxy? Well I have no real control who connects how to a public MTA...
>   anybody can connect to it to try his luck sending me email. That
>   includes untrusted socks proxies...

This
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-proxies.html
or more precisely part "1. Inbound proxies".

You need to explicitely configure exim to tell it that specific hosts
are acting as load-balancing proxy sitting in front of exim. I cannot
think of a szenario where these load-balancing proxies would not be
trusted machines. The issue is about weakening the chain a little bit -
take over the proxy first and then do something to the exim machines
behind.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'