Bug 683797

Summary: saslauthd using pam does not log rhost (remote host) IP/hostname or requested login in /var/log/secure
Product: Red Hat Enterprise Linux 5 Reporter: Amir Caspi <cepheid>
Component: cyrus-saslAssignee: Petr Lautrbach <plautrba>
Status: CLOSED WONTFIX QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.6CC: andy, fche, igeorgex, jskarvad, mhlavink, sgadekar
Target Milestone: rcKeywords: Improvement, Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-12 12:56:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 836232    
Attachments:
Description Flags
remote-host logging patch for saslauthd none

Description Amir Caspi 2011-03-10 11:45:50 UTC 
Description of problem:
By default, sendmail uses saslauthd for SMTP AUTH; saslauthd uses PAM for authentication. However, log entries do not contain the remote host IP/hostname or requested login, even though this capability is built into PAM and other daemons who use PAM (e.g. sshd, imapd, etc.) do properly record both the rhost and requested login.

For example, when saslauthd experiences an auth failure, it logs to /var/log/secure:
Mar 9 06:56:41 hostname saslauthd[25858]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=

When sshd logs a similar failure, it logs:
Mar 8 14:02:26 hostname sshd[29059]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1 user=someuser

Note that sshd's log entry includes both the remote host (rhost) and the requested login (user); saslauthd does not include either one (the requested login is neither in "logname" nor "ruser").

As such, saslauthd's PAM log entries are of very limited utility, and are useless for brute force detection utilities (e.g. BFD or fail2ban).

Version-Release number of selected component (if applicable):
cyrus-sasl 2.1.22-5

How reproducible:
Always

Steps to Reproduce:
1. Fail an SMTP AUTH
2. Check and view the corresponding entry in /var/log/secure
3. Compare with a failed ssh login - note the missing rhost and user fields.
  
Actual results:
saslauthd-generated PAM log entry is missing rhost= and user= fields.

Expected results:
Entry should have proper values for rhost= and user=, just like sshd- and imapd-generated PAM logs do.

Additional info:
The underlying problem is that in saslauthd/auth_pam.c, the auth_pam() function does not include an argument for the remote host, nor a means of determining it within the code. The requested login name _is_ passed but is not recorded in the log. Thus, saslauthd throws away the remote host information before even checking PAM, and also fails to set the appropriate PAM property to record the requested login name.

It should be quite possible to modify auth_pam to determine the remote host (using sasl_getprop, perhaps) and then to set the appropriate PAM parameters (via pam_set_item, perhaps). See last year's discussion on the Cyrus SASL mailing list:
http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2010-July/002108.html

A patch to do this in a _very_ old version of Cyrus SASL is available (http://www.uklinux.net/software/cyrus-sasl-1.5.24-pam-rhost.patch), from when this code used to be in lib/checkpw.c... I am not entirely sure if this patch can be forward-ported to the v2.x (with the code now in saslauthd/auth_pam.c), but hopefully it can be.

(Additionally, the code should also be patched to pass the requested login (variable "login" within auth_pam()) to the _correct_ user= field of the pam data variable, so that it will be properly converted by pam_strerror() and thus properly logged, as well.)

I don't believe there is upstream intent to implement this, so it would be great if it could be implemented as an RHEL-specific patch, or perhaps RHEL devs could provide additional impetus to upstream devs to implement this.  (In principle, this is a security issue - the lack of information makes these log entries useless for preventing brute force SMTP AUTH attacks.)
Comment 1 Amir Caspi 2011-05-22 19:12:00 UTC 
A patch for 2.1.23 and 2.1.24 has been proposed upstream; RHEL uses 2.1.22, so I am unsure if either of these patches can be backported, but if so, I recommend inclusion of such a patch.  This can definitely help to increase security.

http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3468

(I couldn't add this to the external links, above, since Cyrus IMAP isn't in the list of external bug trackers!)
Comment 3 Amir Caspi 2011-05-24 16:53:57 UTC 
The patch author indicates that the 2.1.23 patch applies cleanly to 2.1.22, and the patched version works well.  It should be suitable for backporting into the RHEL distribution.

I would be grateful if it could be considered for inclusion.  This would enhance security by allowing firewalling of dictionary attacks against sendmail.
Comment 4 Amir Caspi 2011-05-24 16:55:20 UTC 
Created attachment 500652 [details]
remote-host logging patch for saslauthd

Patch for v2.1.23 of cyrus-sasl; applies cleanly to 2.1.22.
Comment 5 Jan F. Chadima 2011-05-24 18:05:44 UTC 
to add this functionality to RHEL, please contact RH support
Comment 6 Amir Caspi 2011-05-24 19:16:32 UTC 
Jan,

I thought enhancement/feature requests came through here, as well.  Oops.  I guess you wouldn't consider this a bug or security concern, technically?  (It is the latter, though not an actual exploit.)

Is there a way to forward this thread easily to RH support?

Thanks.
Comment 7 Jan F. Chadima 2011-07-11 08:45:06 UTC 
http://www.redhat.com/support/

The upstream bug report at andrew.cmu.edu is also welcomed.
Comment 8 Amir Caspi 2011-09-08 21:21:10 UTC 
Jan, I am not a RedHat customer... my employer purchases RedHat, and I generally use CentOS.  CentOS won't implement this change since it's downstream.  Not sure if/when CyrusSASL will implement it.

Unless I'm mistaken, it appears I can't submit a support ticket (to request this functionality) without being a paid customer.  Any other way to get this patch incorporated into RHEL 5?  I think it could fall under a security concern, since it's an enhancement that brings SASL's PAM logging into compliance with other PAM clients (like ssh, etc.).

Thanks!
Comment 9 Amir Caspi 2011-10-29 07:43:13 UTC 
Hi Jan,

Just wondering if there's any way to get this incorporated as a backport, as I can't open a support ticket without being a paid customer...

Thanks!
Comment 10 Petr Lautrbach 2011-12-09 14:27:29 UTC 
Mentioned patch breaks testsaslauthd utility [1] and it's possible that also something else so it needs more testing and probably should be reworked.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=759334
Comment 11 Amir Caspi 2011-12-30 00:47:32 UTC 
Petr, the linked bug 759334 says that a new version in FC16 fixes this issue.  Will this new version be pushed to RHEL5 (and hopefully be picked up downstream by CentOS 5) at any point?
Comment 12 Petr Lautrbach 2011-12-30 10:34:30 UTC 
The patch brakes compatibility with several clients not only testsaslauthd so it was removed from Fedora and can't be included in RHEL-5 until it's changed in order not to change api or brake compatibility.
Comment 13 Andrew Haveland-Robinson 2012-03-12 06:29:53 UTC 
I use syslog and some custom daemons to identify and ban ip addresses with iptables that fail to authenticate more than x times in y minutes.

Banning based on failed smtp auth attempts is a valid reason, but if rhost isn't supplied, then it is as useful as a chocolate fireguard.

This is a failed authentication example:
/var/log/secure
Mar 12 05:43:56 zeus saslauthd[27292]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  user=exampleuser

/var/log/maillog
Mar 12 05:43:54 zeus sendmail[8887]: STARTTLS=server, relay=201-68-4-113.dsl.telesp.net.br [201.68.4.113], version=TLSv1/SSLv3, verify=NO, cipher=RC4-MD5, bits=128/128
Mar 12 05:43:58 zeus sendmail[8887]: q2C4hmmH008887: 201-68-4-113.dsl.telesp.net.br [201.68.4.113] did not issue MAIL/EXPN/VRFY/ETRN during connection to MSA

The maillog doesn't show failed auth attempts, just a dropped connection.
There are valid reasons for not banning addresses based on "did not issue", unless excessive.
Fuzzy cross-referencing the secure and mail logs for the ip address would be a really painful option.

How could a log entry in the secure log break compatibility with other clients?
What are the specifics?

Could this be fixed in such a way that it can be customizable with an option in /etc/sasl2/Sendmail.conf?

This is an information hole that still needs to be filled and standardized for other services too - (eg. vsftp logs resolved addresses)
Comment 16 Petr Lautrbach 2012-10-03 15:52:30 UTC 
(In reply to comment #13)
> How could a log entry in the secure log break compatibility with other
> clients?
> What are the specifics?

THe problem is not log entry but the protocol change provided by this patch. saslauthd listens on an unix socket and reads 4 items - user_id, password, service and realm. If you add another item host then saslauthd will block reading until client sends it. It might be ok for clients using cyrus-sasl library but there are several clients like exim which communicates directly to saslauthd socket and they are not aware of fifth item. I can't change the default protocol.
Comment 17 Frank Ch. Eigler 2012-10-03 15:58:55 UTC 
Might it be possible to encode the host name as a transparent extension of the service or realm strings (maybe suffix them with @IP.ADD.RE.SS)?
Comment 18 Jaroslav Škarvada 2012-10-04 09:17:26 UTC 
(In reply to comment #13)
> /var/log/maillog
> Mar 12 05:43:54 zeus sendmail[8887]: STARTTLS=server,
> relay=201-68-4-113.dsl.telesp.net.br [201.68.4.113], version=TLSv1/SSLv3,
> verify=NO, cipher=RC4-MD5, bits=128/128
> Mar 12 05:43:58 zeus sendmail[8887]: q2C4hmmH008887:
> 201-68-4-113.dsl.telesp.net.br [201.68.4.113] did not issue
> MAIL/EXPN/VRFY/ETRN during connection to MSA
> 
> The maillog doesn't show failed auth attempts, just a dropped connection.
> There are valid reasons for not banning addresses based on "did not issue",
> unless excessive.
> Fuzzy cross-referencing the secure and mail logs for the ip address would be
> a really painful option.
> 
Try to increase sendmail loglevel to e.g. 10 or more:
# grep LogLevel /etc/mail/sendmail.cf
O LogLevel=10

# tail -2 /var/log/maillog
Oct  4 10:30:02 dhcp-lab-249 sendmail[28306]: q948Tobf028306: AUTH failure (plain): authentication failure (-13) SASL(-13): authentication failure: Password verification failed, relay=localhost.localdomain [127.0.0.1]
Oct  4 10:30:04 dhcp-lab-249 sendmail[28306]: q948Tobf028306: localhost.localdomain [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

It may resolve your problem, but it doesn't resolve the $SUBJ of this BZ.
Comment 20 Petr Lautrbach 2012-10-08 14:52:25 UTC 
I believe that this has to be fixed/changed on a cyrus-sasl client side.
The client linked to cyrus-sasl library can use 
int sasl_getprop(sasl_conn_t *conn, SASL_IPREMOTEPORT, const void ** pvalue);

to get its client's address and then log attempts itself.

Even the patch attached to this bug doesn't solve the log issue with the 
auth_krb5. It adjusts only the auth_pam method.

Let's say I use cyrus-imapd. There is a line of code in imapd.c:
	syslog(LOG_NOTICE, "badlogin: %s plaintext %s %s",
	       imapd_clienthost, canon_user, sasl_errdetail(imapd_saslconn));

so I need to catch notice messages in syslog:
# echo '*.=notice        /var/log/cyrus.log' >> /etc/rsyslog.conf

and after restart rsyslog I can see following messages in the /var/log/cyrus.log:
Oct  8 16:47:32 rhel-6-openssh imap[3000]: starttls: TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits new) no authentication
Oct  8 16:47:40 rhel-6-openssh imap[3000]: badlogin: master.virt [192.168.122.1] LOGIN [SASL(-4): no mechanism available: Couldn't find mech LOGIN]
Oct  8 16:47:49 rhel-6-openssh imap[3000]: badlogin: master.virt [192.168.122.1] plaintext root SASL(-1): generic failure: checkpass failed

note: this is log from rhel-6 but I believe that this would work same on a rhel-5 box