// reported via PSRT email (see timeline; last contact: Alex/PSRT)
// external reference: http://consensys.net/diligence/vulnerabilities/private/z5kxjgfmja4offxbrw1miuxwezggajjfswlz9g2hfuh77we5dy727hqy5x9ii43e/

cve:
vendor: python
vendorUrl: https://www.python.org/
authors: tintinweb
affectedVersions: [at least 3.8.3, <=3.7.8, <=3.6.11, <=3.5.9, <=2.7.18]
vulnClass: CWE-93

# Vulnerability Note

## Summary

Python is a programming language that lets you work more quickly and integrate your systems more effectively.

Two CR-LF injection points have been discovered in the Python standard library for SMTP interaction (client perspective) named smtplib that may allow a malicious user with direct access to smtplib.SMTP(..., local_hostname, ..) or smtplib.SMTP(...).mail(..., options) to inject a CR-LF control sequence to inject arbitrary SMTP commands into the protocol stream.

The root cause of this is likely to be found in the design of the putcmd(cmd, args) method, that fails to validate that cmd nor args contains any protocol control sequences (i.e. CR-LF).

It is recommended to reject or encode \r\n in putcmd() and enforce that potential multi-line commands call putcmd() multiple times to avoid that malicious input breaks the expected context of the method and hence cause unexpected behavior. For reference, the DATA command (multi-line) would not be affected by this change as it calls putcmd() only once and continues with directly interacting with the socket to submit the body.

## Details

### Description

The root cause of this (and probably also some earlier reported CR-LF injections) is the method putcmd() in lib/smtplib.py[3]. The method is called by multiple commands and does not validate that neither cmd nor args contains any CRLF sequences.

def putcmd(self, cmd, args=""):
    """Send a command to the server."""
    if args == "":
        str = '%s%s' % (cmd, CRLF)
    else:
        str = '%s %s%s' % (cmd, args, CRLF)
    self.send(str)

However, the issue was initially found in mail(..., options) [4] which fails to ensure that none of the provided options contains CRLF characters. The method only ensures that provides mail addresses are quoted, optionslist is untouched:

self.putcmd("mail", "FROM:%s%s" % (quoteaddr(sender), optionlist))

A similar issue was found with smtplib.SMTP(...,local_hostname) (and helo(name), ehlo(name)) which may potentially contain CRLF sequences and, therefore, can be used to inject SMTP commands.

Here's a snipped of helo [5]

def helo(self, name=''):
    """SMTP 'helo' command.
    Hostname to send for this command defaults to the FQDN of the local
    host.
    """
    self.putcmd("helo", name or self.local_hostname)
    (code, msg) = self.getreply()
    self.helo_resp = msg
    return (code, msg)

We highly recommend, fixing this issue once and for all directly in putcmd() and enforce that the interface can only send one command at a time, rejecting arguments that contain CRLF sequences or properly encoding them to avoid injection.

## Proof of Concept

1. set-up a local tcp listener ⇒ nc -l 10001

2. run the following PoC and replay the server part as outline in 3.

import smtplib

server = smtplib.SMTP('localhost', 10001, "hi\nX-INJECTED") # localhostname CRLF injection
server.set_debuglevel(1)
server.sendmail("hi@me.com", "you@me.com", "wazzuuup\nlinetwo")
server.mail("hi@me.com",["X-OPTION\nX-INJECTED-1","X-OPTION2\nX-INJECTED-2"]) # options CRLF injection

3. interact with smtplib, check for X-INJECTED

⇒  nc -l 10001                       
nc -l 10001
220 yo
ehlo hi
X-INJECTED
250-AUTH PLAIN
250
mail FROM:<hi@me.com>
250 ok
rcpt TO:<you@me.com>
250 ok
data
354 End data with <CR><LF>.<CR><LF> 
wazzuuup
linetwo
.
250 ok
mail FROM:<hi@me.com> X-OPTION
X-INJECTED-1 X-OPTION2
X-INJECTED-2
250 ok
quit
250 ok

### Proposed Fix

• enforce that putcmd emits exactly one command at a time and encode \n -> \\n.

diff --git a/Lib/smtplib.py b/Lib/smtplib.py
index e2dbbbc..9c16e7d 100755
--- a/Lib/smtplib.py
+++ b/Lib/smtplib.py
@@ -365,10 +365,10 @@ class SMTP:
     def putcmd(self, cmd, args=""):
         """Send a command to the server."""
         if args == "":
-            str = '%s%s' % (cmd, CRLF)
+            str = cmd
         else:
-            str = '%s %s%s' % (cmd, args, CRLF)
-        self.send(str)
+            str = '%s %s' % (cmd, args)
+        self.send('%s%s' % (str.replace('\n','\\n'), CRLF))

## Vendor Response

Vendor response: gone silent

### Timeline

JUL/02/2020 - contact psrt; provided details, PoC, proposed patch
JUL/04/2020 - confirmed that vulnerability note was received
SEP/10/2020 - requested status update.

## References

• [1] https://www.python.org/
• [2] https://www.python.org/downloads/
• [3]

  cpython/Lib/smtplib.py

  Lines 365 to 371 in 1da648a

  	def putcmd(self, cmd, args=""):
  	"""Send a command to the server."""
  	if args == "":
  	str = '%s%s' % (cmd, CRLF)
  	else:
  	str = '%s %s%s' % (cmd, args, CRLF)
  	self.send(str)

• [4]

  cpython/Lib/smtplib.py

  Line 520 in 1da648a

  def mail(self, sender, options=()):

• [5]

  cpython/Lib/smtplib.py

  Lines 428 to 445 in 1da648a

  	def helo(self, name=''):
  	"""SMTP 'helo' command.
  	Hostname to send for this command defaults to the FQDN of the local
  	host.
  	"""
  	self.putcmd("helo", name or self.local_hostname)
  	(code, msg) = self.getreply()
  	self.helo_resp = msg
  	return (code, msg)
  	def ehlo(self, name=''):
  	""" SMTP 'ehlo' command.
  	Hostname to send for this command defaults to the FQDN of the local
  	host.
  	"""
  	self.esmtp_features = {}
  	self.putcmd(self.ehlo_msg, name or self.local_hostname)
  	(code, msg) = self.getreply()

Deferred the blocker to a regular release due to lack of activity in time for the current expedited releases.

Still in "deferred blocker" status awaiting a PR from someone

If there's no one working on it I'd be happy to prepare a fix.

There is no sign of anyone currently working on it, so please feel free to dig in!

Thanks for the PR! Can someone from the email team take a look at it, please?

This bug report starts with "a malicious user with direct access to `smtplib.SMTP(..., local_hostname, ..)", which is a senseless supposition. Anyone with "access to" the SMTP object could just as well be talking directly to the SMTP server and do anything they want that SMTP itself allows.

The concern here is that data a program might obtain *from unsanitized user input* could be used to do header injection. The "proof of concept" does not address this at all. We'd need to see a scenario under which data that could reasonably be derived from user input ends up being passed as arguments to an smtplib method that calls putcmd with arguments.

So, I would rate this as *very* low impact issue, unless someone has an *actual example* of code using smtplib that passes user input through to smtplib commands in an exploitable way.

That said, it is perfectly reasonable to be proactive here and prevent scenarios we haven't yet thought of, by doing as recommended (and a bit more) by raising a ValueError if 'args' in the putcmd call contain either \n or \r characters. I don't think we need to check 'cmd', because I can't see any scenario in which the SMTP command would be derived from user input. If you want to be *really* paranoid you could check cmd too, and since it will always be a short string the additional performance impact will be minor.

s/header injection/command injection/

This bug report starts with "a malicious user with direct access to `smtplib.SMTP(..., local_hostname, ..)", which is a senseless supposition. Anyone with "access to" the SMTP object could just as well be talking directly to the SMTP server and do anything they want that SMTP itself allows.

Let's not argue about the phrasing and settle on the fact that I am not a native English speaker which might be the root cause of the confusion. The core of the issue is that this *unexpected side-effect* may be security-relevant. Fixing it probably takes less time than arguing about phrasing, severity, or spending time describing exploitation scenarios for a general-purpose library that should protect the underlying protocol from injections.

Be kind, I come in peace.

My apologies, I did not think about the possibility of an English issue. I was reacting to the "security report speak", which I find often makes a security issue sound worse than it is :) Thank you for reporting this problem, and I do think we should fix it.

My posting was directed at the severity of the issue, since it was potentially holding up a release. My point about the example is that without an example of code that could reasonably be expected to use user input in a call that could inject newlines, we can treat this as a low priority issue. If we had a proposed example of such code, then the priority would be higher. If it was an example of such code "in the wild", then it would be quite high :)

The reason I'm saying we should have an example in order to consider it higher priority is that I cannot see *any* likelihood that this would be a problem in practice. Let me explain.

putcmd is an *internal* interface. If we look at the commands that call putcmd or docmd, the only ones that pass extra data that aren't pretty obviously safe (ie: not clearly sanitized data) are rcpt and mail[]. In both cases the item of concern is optionslist. optionslist is a list of *SMTP server options. This is not data that is reasonably taken from user input, it is data provided *by the programmer*.

[*] I did double check to make sure that email.utils.parseaddr sanitizes both \r and \r, just to be sure :)

Therefore this is *not* a significant security issue. But as I said, we should take the "defense in depth" approach and apply the check in putcmd as you recommend. I just don't think it needs to hold up a release.

New changeset 0897253 by Miguel Brito in branch 'main':
bpo-43124: Fix smtplib multiple CRLF injection (GH-25987)
0897253

New changeset 9e6c317 by Miss Islington (bot) in branch '3.10':
bpo-43124: Fix smtplib multiple CRLF injection (GH-25987)
9e6c317

New changeset 24416e4 by Miss Islington (bot) in branch '3.9':
bpo-43124: Fix smtplib multiple CRLF injection (GH-25987) (GH-28035)
24416e4

New changeset b93aea4 by Miss Islington (bot) in branch '3.8':
[3.8] bpo-43124: Fix smtplib multiple CRLF injection (GH-25987) (GH-28036)
b93aea4

Thanks, Martin! ✨ 🍰 ✨

New changeset d2cc04c by Miss Islington (bot) in branch '3.7':
[3.7] bpo-43124: Fix smtplib multiple CRLF injection (GH-25987) (GH-28037)
d2cc04c

New changeset 29d97d1 by Miss Islington (bot) in branch '3.6':
[3.6] bpo-43124: Fix smtplib multiple CRLF injection (GH-25987) (GH-28038)
29d97d1