Hi, Jeremy and Nigel -
On 9 August 2017 at 13:39, Jeremy Harris <jgh@???> wrote:
> On 09/08/17 12:58, Mike Brudenell via Exim-users wrote:
> > 12:36:39 23140 LDAP parameters: user=uid=baduser,ou=blah,dc=uk
> > pass=badpassword size=0 time=0 connect=0 dereference=0 referrals=on
>
> Does the ou=blah exist? This might be a factor, presenting an invalid
> query not just an invalid user.
>
Yes, the ou does; I've just double-checked by authenticating with a valid
username/password. (I wasn't sure how sensitive it was revealing the full
ou/dc string as I'm not an LDAP guru so redacted it from the log extracts.)
I've made an interesting discovery which might help identify the problem:
- Supply a valid username and valid password: Authentication succeeds
- Supply a valid username and invalid password: Authentication fails
with "535 Incorrect authentication data"
- Supply an invalid username and a password: Authentication fails with
"435 Unable to authenticate at present"
With the second the log shows
Invalid credentials: ldapauth returns FAIL
This doesn't cause an expansion error, so the server_condition ends up
correctly generating the 535 SMTP response. For this the LDAP error is
"LDAP error 49: Invalid credentials"
But with the third the log shows
failed to bind the LDAP connection to server ldap.york.ac.uk:389 - LDAP
error 32: No such object
This does cause an expansion error which then, as documented, causes
server_condition to instead defer with the 435 SMTP response. For this the
LDAP error is "LDAP error 32: No such object"
Maybe the latter isn't being handled properly and so causing the expansion
failure rather than returning a false failure?
>From a security point of view, surely it's not good to return different
responses if the username exists/doesn't exist? It gives an attacker a way
of discovering what usernames actually exist so can then focus on their
password. (cf. The "Invalid username or password" generic login failure
messages.)
(Yeah, I think the book is out-of-date, too)
>
I wasn't accusing the book of being out of date, merely that it explicitly
stated the ldapauth condition should return either true or, for failure
modes, false: something the *Specification* doesn't state explicitly for
false.
On 9 August 2017 at 13:48, Nigel Metheringham <nigel@???> wrote:
> I've not been following this in detail, but are you not asking for
> something analogous to the configuration described in this:-
> https://github.com/Exim/exim/wiki/AuthenticatedSmtpUsingPamAndPa
> sswords
>
> Also, if there are multiple auth possibilities I think this can also be
> expressed within PAM.
>
Thanks, Nigel, but I'm effectively doing the multiple check described there
within my authenticator. My problem is that when ldapauth is presented with
an invalid username it generates an expansion error that causes
server_condition to generate a 435 SMTP response, but if the username is
valid (and password invalid) it generates a 535 SMTP response.
To me this seems to be a problem with ldapauth incorrectly causing the
expansion error when presented with an invalid username rather than
returning false. This generates the wrong SMTP response, and potentially
gives an attacker a means of identifying whether a username is valid or not.
Cheers,
Mike B-)
--
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811
Web:
www.york.ac.uk/it-services
Disclaimer:
www.york.ac.uk/docs/disclaimer/email.htm
