Received: by 2002:ab2:60d1:0:b0:1f7:5705:b850 with SMTP id i17csp76711lqm; Tue, 30 Apr 2024 13:18:56 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCWvO/bN48ZJ4KNcO4WCpw9d7sNR5zY0L0joPMxaZXMOaZ8cMk3WvX6stYIlyYtJA44QDL3lWwIxUUpU1sX7X5R7l8F+W/VCzkiFkCpGuQ== X-Google-Smtp-Source: AGHT+IGW5/VM63S+o4XOTml1sDplRpyeCDONl0OBsgYyHZ2RLpxMcjNuAvtTnzFn8ukbP2967vbJ X-Received: by 2002:a50:c314:0:b0:571:bcbe:8ea8 with SMTP id a20-20020a50c314000000b00571bcbe8ea8mr3360936edb.15.1714508336536; Tue, 30 Apr 2024 13:18:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1714508336; cv=none; d=google.com; s=arc-20160816; b=IN33HmbUQ8cZlG9ovRw8OCNhnr3TLMl2fXpVh3KKmb7mgHJvXUqO/rdVLdC3Uqlr1w Ma8lw1Wv5KzIt2Hnysj+vt7eaVVkCHuU7MksWW0sNIG20e6pGfC7vsoJcYmBkrxrKNlo SLx7F9CNtHUUKS8haVsdMRJh6iCRY9CofjunBe6j0lbiUHy0R21qvklRSmpouAJ06s/d gu1LrKxUXh1xgCcXhNFacMYpYinJTQw1NGv4eqXTh7Gcd7xgbaXJNN+hb8kRlVki/7N9 tp9h3F+YUS3y3OCwRWLW892yarJ8kOEo0Zmfmji8NFqRSw/CrSoemCyzyqr3f9NC1WS4 XTbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=subject:author:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:cc:to:from :date:delivered-to:delivered-to:reply-to:list-id:list-subscribe :list-unsubscribe:list-help:list-post:precedence:mailing-list; bh=HVQhTT8jm+gjVyP+0pUr88uKRm1PDrmBc1F3FaHQR0U=; fh=JpASK69+2YFzLjv3RhxI1AQXWKgap3+DiAs7oeyxN1s=; b=IAUN6/YmTsW/B3piAXUYV1qaoq2ysU5hWi02vsuIc9dtLOq6nZa5iYlIgZrlycc8be YUa8bSKkyC7EyKagRxkvR3pUUC6rvkZ2H3VptGyIhU6q+/LkFVe6P4DIpbOYBuMOPSLd lRRjxpcPCpbIVP3++K3lZgdcDWw6IEe0B9Cvr/9lgymue7scTl53xCpN4JdHk+PLlm7g HQU4i/jyLEygdfnc4Pfo3WKILTOeyZuMA1/2NDkqPBxHofPt7ODLzryd4vP7sLNzptJ5 /n2tNUTjtNWckndez6R/2MFkEYTDke+Puen6w2P+uIZpQdFIhK9234epiyB3EDU6XEjp OHsA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of oss-security-return-30104-linux.lists.archive=gmail.com@lists.openwall.com designates 193.110.157.125 as permitted sender) smtp.mailfrom="oss-security-return-30104-linux.lists.archive=gmail.com@lists.openwall.com" Return-Path: Received: from second.openwall.net (second.openwall.net. [193.110.157.125]) by mx.google.com with SMTP id g1-20020a056402114100b0056e045beb8csi16214658edw.239.2024.04.30.13.18.56 for ; Tue, 30 Apr 2024 13:18:56 -0700 (PDT) Received-SPF: pass (google.com: domain of oss-security-return-30104-linux.lists.archive=gmail.com@lists.openwall.com designates 193.110.157.125 as permitted sender) client-ip=193.110.157.125; Authentication-Results: mx.google.com; spf=pass (google.com: domain of oss-security-return-30104-linux.lists.archive=gmail.com@lists.openwall.com designates 193.110.157.125 as permitted sender) smtp.mailfrom="oss-security-return-30104-linux.lists.archive=gmail.com@lists.openwall.com" Received: (qmail 7584 invoked by uid 550); 30 Apr 2024 20:16:08 -0000 Mailing-List: contact oss-security-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: oss-security@lists.openwall.com Delivered-To: mailing list oss-security@lists.openwall.com Delivered-To: moderator for oss-security@lists.openwall.com Received: (qmail 19726 invoked from network); 30 Apr 2024 19:43:07 -0000 Date: Tue, 30 Apr 2024 21:42:43 +0200 From: Erik Auerswald To: oss-security@lists.openwall.com Cc: Mark Esler , Bastien =?iso-8859-1?Q?Roucari=E8s?= Message-ID: <20240430194243.GA28076@unix-ag.uni-kl.de> References: <20231221143630.GD14101@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Author: Erik Auerswald X-Spam-Status: No, hits=-1, tests=ALL_TRUSTED=-1 X-Spam-Score: (-1) X-Spam-Flag: NO Subject: Re: [oss-security] New SMTP smuggling attack Hi Mark, On Mon, Apr 29, 2024 at 08:19:52PM -0500, Mark Esler wrote: > > To mitigate future end-of-data sequence attacks, like SMTP Smuggling, > MTAs should comply with RFC 5321 section 4.1.1.4 [0] to strip control > characters other than , , , and in the DATA section > of SMTP messages. This is an interesting interpretation of RFC 5321, but I do not think it follows the contents of said RFC. > > 4.1.1.4. DATA (DATA) > > > > The receiver normally sends a 354 response to DATA, and then treats > > the lines (strings ending in sequences, as described in > > Section 2.3.7) following the command as mail data from the sender. > > This command causes the mail data to be appended to the mail > > data buffer. The mail data may contain any of the 128 ASCII > > character codes, although experience has indicated that use > > of control characters other than SP, HT, CR, and LF may cause > > problems and SHOULD be avoided when possible. > > e.g., `\r\n\x00.\r\n` _SHOULD_ become `\r\n.\r\n` and then (as per > RFC 5321 section 4.5.2 [1]) dot-stuff the _forbidden_ sequences. Well, my reading of the RFC does not forbid this sequence. RFC 5321 clearly does not require transforming this sequence into another sequence. > As per RFC 2119 section 3 [2], the word *SHOULD* implies *MUST* > unless you have a valid reason not to--which is never the case for > these _forbidden_ sequences in DATA. This is why RFC 5321 4.1.1.4's > _SHOULD avoid_ implies _needs to strip_. RFC 5321 section 4.1.1.4 (DATA (DATA)) states: "The mail data may contain any of the 128 ASCII character codes" RFC 5321 section 4.5.2 (Transparency) states: "The mail data may contain any of the 128 ASCII characters." One might think that there is some inconsistency with the "SHOULD" in section 4.1.1.4. One could also understand the text as allowing any ASCII character (including NUL), but advising against the use of known problematic ones (e.g., NUL) by cautious systems. To put this differently: control characters are _not_ forbidden. They are _explicitly_ allowed. > Also note that RFC 5321 section 3.6.3 [3] and section 6.4 [4] do not give > the OK to send along NUL or other control characters. These sections are > about _adding_ missing information, not preserving messages with > potentially damaging garbage. RFC 5321 section 3.6.3 does not pertain to DATA contents. RFC 5321 section 6.4 mentions the problem of inconsistent handling of "irregularities", i.e., shall malformed messages be rejected, "repaired", or delivered as-is insofar possible. You to seem to advocate for "repair". The "repair" strategy makes Cisco's ESA vulnerable. I would argue that rejecting messages is less insecure. > Cheers to Pete Resnick for this clarification and explanation of > RFC 5321. > > This particular issue was first noted in SEC Consult's analysis of > SMTP Smuggling [5]: > > During the research we've also discovered some exotic > > inbound SMTP servers that interpret end-of-data sequences like > > \x00., with "\x00" representing a null byte. With > > proprietary SMTP components and lots of different e-mail services > > intertwined it's hard to tell what is possible until an e-mail > > reaches its final destination. > > > > Even though SMTP smuggling might still be hiding in some places, > > we hopefully eliminated some big targets. > > Stripping NUL and other control characters could have unforeseen > consequences. MTAs which errantly rely on non-compliant control > characters would break. Major MTAs are therefore sensibly resistant > to enforcing RFC 5321 section 4.1.1.4. Use of control characters is compliant, even though it may be problematic. > What is the real world HAM:SPAM ratio of emails which include NUL? Would > it be safe to configure sendmail to `O RejectNUL=True` (which would > break RFC 2822 section 4 [6] by rejecting email which include NUL)? > > What are the benefits and risks of stripping ASCII NUL and other > control characters from SMTP DATA? Interesting questions. Perhaps you could perform an experiment and report on the results? Perhaps email specifications can be improved to reject known problematic content elements, e.g., NUL bytes? Rejecting email for arbitrary reasons is common practice currently. Rejecting email for containing unwanted characters or character sequences might thus be acceptable. Rewriting email contents seems to me to be more problematic, but even that is routinely done nowadays (e.g., to mark external messages). > Feedback appreciated, I would suggest to be rather careful when automatically rewriting messages in new and unsuspected ways. > Mark Esler and Bastien Roucari?s > > [0] https://datatracker.ietf.org/doc/html/rfc5321#section-4.1.1.4 > [1] https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.2 > [2] https://datatracker.ietf.org/doc/html/rfc2119#section-3 > [3] https://datatracker.ietf.org/doc/html/rfc5321#section-3.6.3 > [4] https://datatracker.ietf.org/doc/html/rfc5321#section-6.4 > [5] https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/ > [6] https://datatracker.ietf.org/doc/html/rfc2822#section-4 Best regards, Erik