Re: [exim-dev] tls_sni = $host in default configuration file

2019-01-06 Thread Richard James Salts via Exim-dev
On Friday, 4 January 2019 2:02:20 AM AEDT Florian Zumbiehl via Exim-dev wrote:
> Hi,
> 
> > For the record, if you have a sensitive security issue, please mail
> > 
> > secur...@exim.org
> 
> well, that's good to know, I guess, but may I suggest you put that on the
> website somewhere? 

It probably would be useful to include it on the website, but if you attempt 
to submit a bug it does have a disclaimer at the top: "If you have a sensitive 
security issue, please mail secur...@exim.org"  although it doesn't have 
instructions on how to encrypt with the maintainer's public keys.

> Just put a text file in
> https://www.exim.org/static/doc/security/ or something, that's linked as
> "security" from the start page, so that should be easy enough to discover.
> 
> Even knowing the address, the only thing I can find on the web containing
> that address are some files in /.github/ in the repo, hosted on github, so
> that's kinda impossible to find.
> 
> Adding a file in the root of the repo might also be a good idea ...
> 
> Regards, Florian



-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] tls_sni = $host in default configuration file

2019-01-05 Thread Florian Zumbiehl via Exim-dev
Hi,

> Once one is logged in or creates a log-in to file a report, it really is
> quite straightforward:
> 
> http://www.exim.org/ --> [bugs]
> https://bugs.exim.org/ --> [File a Bug]
> https://bugs.exim.org/enter_bug.cgi which looks as attached

Well, so, once you have done a bunch of steps that are otherwise
unnecessary for what you are trying to accomplish, including creating an
account that you don't want and don't need, you are informed what you
should have done instead. That's kinda ... let's say not exactly
straightforward? ;-) I mean, is there anything that is not straightforward
if you ignore all the steps that it takes to get to the point where the
solution becomes obvious?

> [...]
> > And in any case, what I can say is that as a matter of fact I didn't find
> > it when I needed it, even if you think that I should have.
> 
> http://www.exim.org/ --> [Security] could include a pointer.

I would think that's probably the most obvious place to put it, yeah. The
front page of the bug tracker probably should work, too, I would think.
Putting it on the wiki might work as well, if it's linked prominently
enough. The point is, it should be easy to discover for someone who has no
previous involvement with the project and comes to the website with that
goal.

Regards, Florian

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] tls_sni = $host in default configuration file

2019-01-04 Thread Andreas Metzler via Exim-dev
On 2019-01-04 Florian Zumbiehl via Exim-dev  wrote:
> On 2019-01-04 Jeremy Harris via Exim-dev wrote:
>> On 04/01/2019 01:02, Florian Zumbiehl via Exim-dev wrote:
>>>  may I suggest you put that on the
>>> website somewhere?
 
>> It was already there, at https://bugs.exim.org/enter_bug.cgi

> That page only tells me that "Bugzilla needs a legitimate login and
> password to continue.".

Fair enough.

Once one is logged in or creates a log-in to file a report, it really is
quite straightforward:

http://www.exim.org/ --> [bugs]
https://bugs.exim.org/ --> [File a Bug]
https://bugs.exim.org/enter_bug.cgi which looks as attached

[...]
> And in any case, what I can say is that as a matter of fact I didn't find
> it when I needed it, even if you think that I should have.

http://www.exim.org/ --> [Security] could include a pointer.

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'
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] tls_sni = $host in default configuration file

2019-01-04 Thread Florian Zumbiehl via Exim-dev
Hi,

> On 04/01/2019 01:02, Florian Zumbiehl via Exim-dev wrote:
> >  may I suggest you put that on the
> > website somewhere?
> 
> It was already there, at https://bugs.exim.org/enter_bug.cgi

That page only tells me that "Bugzilla needs a legitimate login and
password to continue.". Clicking around on that page, I now found that the
security report address is mentioned on
https://bugs.exim.org/describecomponents.cgi, which is linked as "Browse"
in the header and footer of the bug tracker page. Which is pretty
counterintuitive: When looking for a way to report a vulnerability that
maybe shouldn't be published for the time being, I probably won't be
browsing the public bugs.

And in any case, what I can say is that as a matter of fact I didn't find
it when I needed it, even if you think that I should have.

Regards, Florian

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] tls_sni = $host in default configuration file

2019-01-04 Thread Jeremy Harris via Exim-dev
On 04/01/2019 01:02, Florian Zumbiehl via Exim-dev wrote:
>  may I suggest you put that on the
> website somewhere?

It was already there, at https://bugs.exim.org/enter_bug.cgi
-- 
Jeremy

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] tls_sni = $host in default configuration file

2019-01-03 Thread Florian Zumbiehl via Exim-dev
Hi,

> For the record, if you have a sensitive security issue, please mail
> secur...@exim.org

well, that's good to know, I guess, but may I suggest you put that on the
website somewhere? Just put a text file in
https://www.exim.org/static/doc/security/ or something, that's linked as
"security" from the start page, so that should be easy enough to discover.

Even knowing the address, the only thing I can find on the web containing
that address are some files in /.github/ in the repo, hosted on github, so
that's kinda impossible to find.

Adding a file in the root of the repo might also be a good idea ...

Regards, Florian

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] tls_sni = $host in default configuration file

2019-01-02 Thread Jeremy Harris via Exim-dev
For the record, if you have a sensitive security issue, please mail
secur...@exim.org

-- 
Cheers,
  Jeremy

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] tls_sni = $host in default configuration file

2019-01-02 Thread Florian Zumbiehl via Exim-dev
Hi,

> If we're changing `$host` based upon CNAMEs in DNS, then yes this will
> do The Wrong Thing.  It might be a security problem then, because the
> normally-insecure DNS changes the name we validate the certificate
> against.  We can't rely upon DNSSEC for this default example config.

Yes, that is indeed a security problem that I reported more than a year ago
via direct email to Jeremy Harris (unfortunately, I couldn't find any
guidelines as to how to report vulnerabilities on the website, and I didn't
want to post it publicly), but I unfortunately never heard back from him.
When investigating now whether it had been fixed or what to do about it, I
stumbled upon this thread, so I guess this is the right place to post this
...

So, yes, Exim does check certificates against DNS CNAME targets and is thus
vulnerable to MitM attackers retargeting supposedly TLS-protected
connections to hostnames that they control and thus can obtain certificates
for via spoofed DNS responses when the lookup is not protected by DNSSEC.

I successfully tested the attack against the Debian stretch Exim (4.89),
and based on the code it does not look like the current git master is any
less vulnerable. It only seems that the behaviour is kinda documented now
if you look really closely (section "Configuring an Exim client to use TLS"
mentions that the name "in the DNS A record" is checked), but that's both
incorrect (works with  as well) and easily overlooked. And in any case
documenting a vulnerability doesn't make it any less of a vulnerability, as
there doesn't seem to be any alternative way to configure things that would
be secure.

Apart from the fact that this is a vulnerability, it's also functionally
broken as it breaks certificate verification when delivering to a smarthost
that happens to be a legitimate CNAME, as the correct server certificate,
of course, is for the user-specified name (something slightly different
might apply when DANE is used). As mentioned elsewhere in this thread,
CNAMEs for outbound relays are common with the big providers, so you cannot
even enable certificate validation when talking to them unless you hard
code the IP addresses in your local hosts file to prevent Exim from seeing
the CNAME.

When looking at the code now, I noticed another bug and potential
vulnerability: verify_callback() in tls-openssl.c treats the hostname as a
list. Currently, you can, of course, inject a list via a CNAME response--I
have no clue what other ways there might be to exploit this, but it doesn't
seem like a good idea anyway.

Also, overwriting an admin-supplied value with potentially untrusted
information seems to me like a bad idea in general, not just for TLS
certificate checking, as that can lead to all sorts of confused deputy
style problems if you aren't extremely careful, where policies suddenly are
applied based on an identity selected by the attacker rather than what was
specified by the admin.

Regards, Florian

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] tls_sni = $host in default configuration file

2018-12-21 Thread Phil Pennock via Exim-dev
On 2018-12-20 at 20:50 +, Jeremy Harris via Exim-dev wrote:
> The wording "should be" could be relaxed slightly, maybe, since it isn't
> required by Exim's parsing.  "It is simplest to", perhaps?

Didn't we used to require it?  I forget.  Feel free to update it.

> I see you quietly removed prdr.  Has it been seen to cause problems?

No: I removed a documentation claim which was false.

The spec.xfpt doc claimed that the configure.default file included
"hosts_try_prdr = *" on the remote_smtp Transport.  That was not
present.  I can find no evidence that it has ever been present.
(`git log --patch src/src/configure.default` and search for
`hosts_try_prdr`)

So I made the documentation consistent with reality.

If you want PRDR in the default config, talk with Heiko then go ahead
and add it, to the config and the docs both?

> On multi_domain - some really stupid hosts (hi, Google!) can't handle
> it, and will _always_ temp-reject any RCPT after the first domain
> (G gives an explicit text error saying it can't hack it).

Might be worth calling out in a comment?  Or comment-out the directive
and include it as a suggestion for "If your smarthost is able to do so."

I thought, but could well be wrong, that Google did as you say for their
listening MX services, but not for Submission services.  For MX, it
makes some sense when you have per-domain policies on spam-handling and
no good way to handle (without PRDR) what should be done there.  For
Submission, enforcing a single domain per message strikes me as ...
Quirky.  At best.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] tls_sni = $host in default configuration file

2018-12-20 Thread Jeremy Harris via Exim-dev
On 19/12/2018 00:51, Phil Pennock via Exim-dev wrote:
> I think this change is generally useful, in having a cleaner setup for a
> very common use-case, and showing exactly where new macros should be
> defined, which can reduce some of the pain encountered by newcomers to
> Exim.

The wording "should be" could be relaxed slightly, maybe, since it isn't
required by Exim's parsing.  "It is simplest to", perhaps?


I see you quietly removed prdr.  Has it been seen to cause problems?


On multi_domain - some really stupid hosts (hi, Google!) can't handle
it, and will _always_ temp-reject any RCPT after the first domain
(G gives an explicit text error saying it can't hack it).

-- 
Cheers,
  Jeremy

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] tls_sni = $host in default configuration file

2018-12-18 Thread Phil Pennock via Exim-dev
On 2018-12-17 at 18:44 -, Jasen Betts via Exim-dev wrote:
> What does DANE say we shoud ask for? I remember it being non-obvious but
> easily explained. However I don't however remember the detail.

RFC 7672 section 2.2.2.

If DNSSEC is available for every step along the way, for all CNAMEs in
the chain, then the final target.  Otherwise, only the original name.

On 2018-12-17 at 19:57 +0100, Andreas Metzler via Exim-dev wrote:
> I only recognized the problem because we have had to workaound/document
> around it in Debian for ages. - We have been using ${lookup{$host} in
> smtp authentication.
> 
> CNAME for smarthost is very common, the biggest players (office365,
> gmail and yahoo) use it.

Heiko: I've pushed a new branch to the main repo: "ifdef_smarthost".

As well as making the recommended change, it adds a few more comments
and brings the documentation up-to-date.  I recommend merging this in
the RC series, rather than trying to add new code features after RC
start.

I think this change is generally useful, in having a cleaner setup for a
very common use-case, and showing exactly where new macros should be
defined, which can reduce some of the pain encountered by newcomers to
Exim.

I've built spec.pdf locally, it seems sane when I look at the areas
I just changed.  Hrm, perhaps some different wording now makes sense for
the start of the main configuration docs after the new macros text?

We'd probably want to explicitly warn packagers, because of default
config rewrites done by some packaging systems (FreeBSD comes to mind).

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] tls_sni = $host in default configuration file

2018-12-17 Thread Andreas Metzler via Exim-dev
On 2018-12-17 Phil Pennock via Exim-dev  wrote:
> On 2018-12-16 at 10:42 +, Jeremy Harris via Exim-dev wrote:
> > On 16/12/2018 10:20, Andreas Metzler via Exim-dev wrote:
> > > 4.92rc1 adds this to the smarthost_smtp transport:
> > > 
> > > tls_sni = $host
> > > 
> > > I do not think that always works as expected. Depending on the DNS setup
> > > (CNAME, round robin) $host will not contain the name of the selected
> > > smarthost anymore but a different value.
[...]
> I think that I just missed that we might adapt `$host` during the life
> of the Transport.

> 
> 30.2

> Absent `hosts_override` or `hosts` directly on the Transport, Round
> Robin A records have no cause to change the host _name_.  So the only
> issue should be CNAME records?
[...]

Hello Phil,

I only recognized the problem because we have had to workaound/document
around it in Debian for ages. - We have been using ${lookup{$host} in
smtp authentication.

CNAME for smarthost is very common, the biggest players (office365,
gmail and yahoo) use it.

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'

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] tls_sni = $host in default configuration file

2018-12-17 Thread Jasen Betts via Exim-dev
On 2018-12-16, Phil Pennock via Exim-dev  wrote:
> On 2018-12-16 at 10:42 +, Jeremy Harris via Exim-dev wrote:
>> On 16/12/2018 10:20, Andreas Metzler via Exim-dev wrote:
>> > 4.92rc1 adds this to the smarthost_smtp transport:
>> > 
>> > tls_sni = $host

What does DANE say we shoud ask for? I remember it being non-obvious but
easily explained. However I don't however remember the detail.


-- 
  When I tried casting out nines I made a hash of it.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] tls_sni = $host in default configuration file

2018-12-16 Thread Phil Pennock via Exim-dev
On 2018-12-16 at 10:42 +, Jeremy Harris via Exim-dev wrote:
> On 16/12/2018 10:20, Andreas Metzler via Exim-dev wrote:
> > 4.92rc1 adds this to the smarthost_smtp transport:
> > 
> > tls_sni = $host
> > 
> > I do not think that always works as expected. Depending on the DNS setup
> > (CNAME, round robin) $host will not contain the name of the selected
> > smarthost anymore but a different value.
> 
> Phil - that went in at 26739076ae in the example config; could you
> comment?

I think that I just missed that we might adapt `$host` during the life
of the Transport.


30.2

Absent `hosts_override` or `hosts` directly on the Transport, Round
Robin A records have no cause to change the host _name_.  So the only
issue should be CNAME records?

If we're changing `$host` based upon CNAMEs in DNS, then yes this will
do The Wrong Thing.  It might be a security problem then, because the
normally-insecure DNS changes the name we validate the certificate
against.  We can't rely upon DNSSEC for this default example config.

It's an example, which can be fixed, so it's not major.  This isn't the
built-in default for the option, but the default example configuration.

Short of messing with `$address_data`, the only fix I can immediately
think of would be to record `$router_host` or `$original_host` as the
value of `$host` when the Transport is entered, and then make that the
configured example.  That's some more coding changes.

Is this enough of a problem in real world scenarios to be worth the
coding work?  More code for hypothetical problems is complexity to debug
and maintain.  I'm inclined to have our example configuration gently
push back against that and encourage people to reduce CNAMEs, or accept
that this will require explicit configuration.

But this is a taste issue; if it's a big problem then I strongly suspect
we'll accept a codebase patch upstream to add `$router_host` and use
that as the example config default, or some other appropriate solution
if someone spots something good which I've missed.  Which is possible,
because I missed the CNAME issue at the time.

The cop-out would be to change to using a macro at the top of the file,
`SMARTHOST_NAME`, and .ifdef guards to define the Router only if that
macro is defined, and then reuse `SMARTHOST_NAME` as the default for
`tls_sni`.  That would be more secure, but perhaps a little harder to
talk people through changing.  But hey, we can uncomment the Router by
default, in that case.  Just leave the macro commented-out by default.
So a small win?

Hrm.  Perhaps the macro approach for the imminent release, and consider
a new variable for the next release?  Heiko's discretion at this point.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##


Re: [exim-dev] tls_sni = $host in default configuration file

2018-12-16 Thread Jeremy Harris via Exim-dev
On 16/12/2018 10:20, Andreas Metzler via Exim-dev wrote:
> 4.92rc1 adds this to the smarthost_smtp transport:
> 
> tls_sni = $host
> 
> I do not think that always works as expected. Depending on the DNS setup
> (CNAME, round robin) $host will not contain the name of the selected
> smarthost anymore but a different value.

Phil - that went in at 26739076ae in the example config; could you
comment?
-- 
Thanks,
  Jeremy

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##