Hi, Jeremy and Nigel - On 9 August 2017 at 13:39, Jeremy Harris <[email protected]> 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 <[email protected]> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
