Bug 504186

Summary: sendmail may use sasl_encode64() improperly
Product: [Other] Security Response Reporter: Vincent Danen <vdanen>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED NOTABUG QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: jchadima, mlichvar, security-response-team, tmraz
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-06-18 07:14:44 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: 487251    

Description Vincent Danen 2009-06-04 16:37:09 UTC
An issue was reported in how cyrus-sasl did not reliably terminate its output from the sasl_encode64() function.  During an audit of programs that use sasl_encode64(), it was found that sendmail has some questionable uses in sendmail/usersmtp.c, where it just allocates a large output buffer without any appropriate checks against the size of the input buffer.  The strings in question are not used for anything odd; they are simply copied elsewhere.  This means that we are going to see a crash, leaking some memory to the server, or auth failures.

More information on the issue as originally reported against cyrus-sasl (CVE-2009-0688) is available in bug #487251.

Comment 17 Tomas Hoger 2009-06-17 15:41:38 UTC
For the sake of completeness - in sendmail, sasl_encode64() is also used in sendmail/srvrsmtp.c.  Buffer to store base64 encoded representation of the authentication string is allocated dynamically.  Size if computed using the ENC64LEN macro, which does not return value that is multiple of 4, and hence sasl_encode64 will always null-terminate or return error.

Comment 21 Tomas Hoger 2009-06-18 07:14:44 UTC
Uses of sasl_encode64 in sendmail/usersmtp.c are harmless too.  Output buffer to store base64-encoded string - in64 - is only used as an argument to smtpmessage().  in64 can only be missing proper null termination when is got fully filled by sasl_encode64(), i.e. MAXOUTLEN (8192) bytes were written to it.

smtpmessage() accepts printf-like arguments (format string + arguments) and uses sendmail-specific vsnprintf-like function sm_vsnprintf to prepare the output string in the intermediate buffer SmtpMsgBuffer.  Size of the buffer is MAXLINE (2048), hence memory locate after in64 will not be copied it, so memory disclosure is not possible.

Only remaining risk is that in64 is printed to the output buffer using '%s' format, which internally calls strlen on the argument.  This strlen call can over-read in64 buffer, but can not reach far enough to trigger SEGV, as it stops at the first '\0' byte anywhere on the stack above in64 (e.g. main's argc / argv, or area storing args and environment variables located above the stack).

No security implications.