headers
Kurt Jaeger | 1 Nov 2010 23:39
Picon

patch: src/auths/spa.c fix for cancelled AUTH NTLM

Hi!

While debugging AUTH NTLM against Outlook 2010, I found
that in http://tools.ietf.org/html/rfc2554, section 4 it says
that if the client sends "*" as the answer to a NTLM CHALLENGE,
the AUTH should be cancelled (SMTP 501), not fail (SMTP 535).

At

http://opsec.eu/src/exim-ntlm/patch-spa.c

is a small patch which hopefully does the right thing.

For those interested in AUTH NTLM ('SPA' in Microsoft lingo),
here's what I found:

if exim offers AUTH NTLM, this happens:

  o exim sends a "334 NTLM supported"
  o Outlook 2010 as a client sends some base64
    which is a NLMP NEGOTIATE blob, described in
    http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-NLMP%5D.pdf
    page 15ff
  o exim answers with a NLMP CHALLENGE blob, described in the same
    document, page 19ff.
  o and Outlook 2010 says "no thanks", probably due to some of the
    fields filled in some non-microsofty-way.

This is the reason SPA no longer works. One has to debug the contents
of the blob.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Phil Pennock | 2 Nov 2010 15:47

Re: patch: src/auths/spa.c fix for cancelled AUTH NTLM

On 2010-11-01 at 23:39 +0100, Kurt Jaeger wrote:
>   o exim sends a "334 NTLM supported"
>   o Outlook 2010 as a client sends some base64
>     which is a NLMP NEGOTIATE blob, described in
>     http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-NLMP%5D.pdf
>     page 15ff
>   o exim answers with a NLMP CHALLENGE blob, described in the same
>     document, page 19ff.

This is the point at which things have gone wrong; Exim worked to an
older specification, MS updated to have NTLM support Initial Response, a
common SASL name, which basically means "send the first part of the
authentication at the same time as asking to authenticate".

Exim head already contains a probable fix for this, but I don't have
Outlook clients to test against and I don't recall if the reporter
verified it.  Hrm, no Bugzilla entry, but it's:
  PP/06 Adjust NTLM authentication to handle SASL Initial Response.
in the ChangeLog for version 4.73 (forthcoming.

The commit is:
  http://git.exim.org/exim.git/commit/55c75993b43ac91069a5fbe9cc7a8d48cda84ee0
and the diff should apply cleanly to any relatively recent SPA.

You're probably right about Exim not cancelling properly, and thanks for
reporting that.  I can't look right now, as it's work hours and Exim dev
work has to be done on my time, but tonight I should finally have
working home Internet connectivity and be able to catch back up on some
pending Exim issues, including this.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Phil Pennock | 2 Nov 2010 15:50

Re: patch: src/auths/spa.c fix for cancelled AUTH NTLM

On 2010-11-02 at 10:47 -0400, Phil Pennock wrote:
> Exim head already contains a probable fix for this, but I don't have
> Outlook clients to test against and I don't recall if the reporter
> verified it.  Hrm, no Bugzilla entry, but it's:
>   PP/06 Adjust NTLM authentication to handle SASL Initial Response.
> in the ChangeLog for version 4.73 (forthcoming.
> 
> The commit is:
>   http://git.exim.org/exim.git/commit/55c75993b43ac91069a5fbe9cc7a8d48cda84ee0
> and the diff should apply cleanly to any relatively recent SPA.

Too many typos and "I meant to type" missing blobs there, sorry.

So, that diff should apply cleanly to any relatively recent Exim.
Because the code still hasn't been verified, if you can confirm it fixes
your problems, that would be great.  :)  If it doesn't fix your
problems, then (a) that sucks and (b) I can take a deeper look at fixing
it.

-Phil

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
Permalink | Reply | 0 comments |
headers
Yuri Arabadji | 3 Nov 2010 09:42
Favicon

potential exploitation vector

Hi, devs.

A quick question to exim developers. 

How is it possible that exim invokes something with superuser privileges and 
that something is fed with user data?

I'm talking about things like encoding translations that happen when accessing 
variables in system filter - iconv family of functions, for example. And hey, 
why are we invoking system filter with euid 0 at all?! Is there any strong 
reason of doing that or am I getting the code incorrectly?

Thank you.

-- 
Best regards,
 Yuri Arabadji -- System Engineer

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
Permalink | Reply | 1 comment |
headers
Phil Pennock | 3 Nov 2010 21:14

Re: potential exploitation vector

On 2010-11-03 at 10:42 +0200, Yuri Arabadji wrote:
> How is it possible that exim invokes something with superuser privileges and 
> that something is fed with user data?

It means you've built Exim with EXIM_USER=0, something which is strongly
discouraged in the documentation of past releases and which will not be
permitted in the next release -- the build tools and a run-time check
will abort if EXIM_USER is root.

> I'm talking about things like encoding translations that happen when accessing 
> variables in system filter - iconv family of functions, for example. And hey, 
> why are we invoking system filter with euid 0 at all?! Is there any strong 
> reason of doing that or am I getting the code incorrectly?

System filter should be being accessed as the exim user.  This is either
a hard-coded uid specified by name or number, or a hard-coded usercode,
looked up at run-time.  The value coded in was specified in
Local/Makefile when Exim was built and you can use:
  exim -bP exim_user
to find out the value.

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
Permalink | Reply | 0 comments |
headers
David Woodhouse | 4 Nov 2010 02:16
Favicon

[Bug 191] Option to use another address in callout MAIL FROM

------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://bugs.exim.org/show_bug.cgi?id=191

--- Comment #5 from David Woodhouse <dwmw2 <at> infradead.org>  2010-11-04 01:16:27 ---
> Mail gateways such as Barracuda do not permit <> senders

Such a system is *COMPLETELY* broken and has no place being mentioned in a
discussion about email.

-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
Permalink | Reply | 0 comments |
headers
Phil Pennock | 4 Nov 2010 04:35

Re: potential exploitation vector

On 2010-11-04 at 01:07 +0200, Yuri Arabadji wrote:
> Hello, Phil.
> 
> Thanks for your time spent on replying to my message. Let me take another 
> portion of it ;)
> 
> The specific exim's build I'm using is deployed on many hosting servers across 
> the internet and it would be quite bad if this turns out to be an actual bug:
> http://diff.cpanel.net/exim/4.69-23.1/src/exim-4.69-23.1_cpanel_maildir.src.rpm
> 
> EXIM_USER is mailnull. exim -bP exim_user outputs mailnull.
> 
> uid=47(mailnull) gid=47(mailnull) groups=47(mailnull) 
> 
> Please see the attached traces and especially the line 
> "Let's see what UIDs we've got" in exim.daemon.log.
> 
> This is an almost unmodified CPanel exim installation. I'm attaching everything 
> relevant. It would be wonderful if you could explain what's going on there and 
> whether that is the expected behavior.

You're quite right, I was mis-remembering the defaults of Exim.  My
apologies.

We should probably look at changing the default value of
system_filter_user.

-Phil

----------------------------8< cut here >8------------------------------
(Continue reading)

Permalink | Reply | 3 comments |
headers
Spencer Marshall | 3 Nov 2010 22:34
Favicon

[Bug 304] Use ESMTP and TLS for recipient callout verification

------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://bugs.exim.org/show_bug.cgi?id=304

Nigel Metheringham <nigel <at> exim.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|Exim 4.72                   |Exim 4.73

Spencer Marshall <spencer.marshall <at> transversal.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |spencer.marshall <at> transversal
                   |                            |.com

--- Comment #2 from Spencer Marshall <spencer.marshall <at> transversal.com>  2010-11-03 21:34:30 ---
This also applies to sender callout and header_sender callout.  Currently,
where two companies enforce TLS, sender verification fails because the call
back is not over TLS, even if a specific router and transport enforces TLS.

-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
(Continue reading)

Permalink | Reply | 0 comments |
headers
Spencer Marshall | 3 Nov 2010 22:28
Favicon

[Bug 191] Option to use another address in callout MAIL FROM

------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://bugs.exim.org/show_bug.cgi?id=191

Spencer Marshall <spencer.marshall <at> transversal.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |spencer.marshall <at> transversal
                   |                            |.com

--- Comment #4 from Spencer Marshall <spencer.marshall <at> transversal.com>  2010-11-03 21:28:02 ---
(In reply to comment #3)
> For verifying header addresses, there's the "mailfrom" parameter, see section
> 40.42.  However, it is only valid on verify=header_sender, for the reasons
> which led to David objecting.
> 
> So for the cases we've been willing to support, this was fixed a long time ago
> (revision 1.1 of acl.c in current repository).
> 
> Does anyone think there's anything more to this bug?
> 
Mail gateways such as Barracuda do not permit <> senders so verification of any
legitimate mail from such a gateway will always fail.  However not doing sender
verification is not an option becuase it cuts down on an awful lot of spam.

I would much rather do verification in the mail acl i.e. early on, rather than
doing unnecessary processing i.e. rcpt acl and then data acl.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yuri Arabadji | 4 Nov 2010 16:21
Favicon

Re: potential exploitation vector

Hi, Phil.

Wow, indeed, going to bug CPanel guys then.

Thank you so much for explaining!

On Thursday 04 November 2010, Phil Pennock wrote:
> On 2010-11-04 at 01:07 +0200, Yuri Arabadji wrote:
> > Hello, Phil.
> >
> > Thanks for your time spent on replying to my message. Let me take another
> > portion of it ;)
> >
> > The specific exim's build I'm using is deployed on many hosting servers
> > across the internet and it would be quite bad if this turns out to be an
> > actual bug:
> > http://diff.cpanel.net/exim/4.69-23.1/src/exim-4.69-23.1_cpanel_maildir.s
> >rc.rpm
> >
> > EXIM_USER is mailnull. exim -bP exim_user outputs mailnull.
> >
> > uid=47(mailnull) gid=47(mailnull) groups=47(mailnull)
> >
> > Please see the attached traces and especially the line
> > "Let's see what UIDs we've got" in exim.daemon.log.
> >
> > This is an almost unmodified CPanel exim installation. I'm attaching
> > everything relevant. It would be wonderful if you could explain what's
> > going on there and whether that is the expected behavior.
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane