Re: [exim] Re: sensitive data appearing in delay warning mes…

Top Page
Delete this message
Reply to this message
Author: Philip Hazel
Date:  
To: Brian Candler
CC: exim-users, Alexander V Alekseev
Subject: Re: [exim] Re: sensitive data appearing in delay warning messages [was: Please help!]
On Fri, 15 Apr 2005, Brian Candler wrote:

> > if quota lookup fails.
>
> Hmm. Yes, that looks like a real problem.


The next release of Exim will contain this change, that I did a couple
of weeks ago:

PH/10 Added a nasty fudge to try to recognize and flatten LDAP passwords in
      an address' error message when a string expansion fails (syntax or
      whatever). Otherwise not only does the password appear in the log, it may
      also be put in a bounce message.


The patch is below. Note the comment. It is a band-aid. Brian's idea of
noting whether an expansion contains a "hide" variable and using that
as a criterion for not giving details is also worth exploring WIGAM
(when I get a moment).

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book:    http://www.uit.co.uk/exim-book



*** exim-4.50/src/deliver.c Thu Feb 17 14:49:11 2005
--- deliver.c    Thu Apr  7 16:40:50 2005
***************
*** 729,737 ****


/* If there's an error message set, ensure that it contains only printing
characters - it should, but occasionally things slip in and this at least
! stops the log format from getting wrecked. */
!
! if (addr->message != NULL) addr->message = string_printing(addr->message);

/* If we used a transport that has one of the "return_output" options set, and
if it did in fact generate some output, then for return_output we treat the
--- 729,755 ----

  /* If there's an error message set, ensure that it contains only printing
  characters - it should, but occasionally things slip in and this at least
! stops the log format from getting wrecked. We also scan the message for an LDAP
! expansion item that has a password setting, and flatten the password. This is a
! fudge, but I don't know a cleaner way of doing this. (If the item is badly
! malformed, it won't ever have gone near LDAP.) */
! 
! if (addr->message != NULL)
!   {
!   addr->message = string_printing(addr->message);
!   if (Ustrstr(addr->message, "failed to expand") != NULL &&
!       (Ustrstr(addr->message, "ldap:") != NULL ||
!        Ustrstr(addr->message, "ldapdn:") != NULL ||
!        Ustrstr(addr->message, "ldapm:") != NULL))
!     {
!     uschar *p = Ustrstr(addr->message, "pass=");
!     if (p != NULL)
!       {
!       p += 5;
!       while (*p != 0 && !isspace(*p)) *p++ = 'x';
!       }
!     }
!   }


/* If we used a transport that has one of the "return_output" options set, and
if it did in fact generate some output, then for return_output we treat the