Am Freitag, dem 29.12.2023 um 18:32 -0500 schrieb Paul Jarc:
> This looks like a good explanation:
> https://www.postfix.org/smtp-smuggling.html
>
thanks for the URL Paul, but right now the net is full of comments.
I didn't have time to check s/qmail in detail for the vulnerability,
but would like to reference Leah's comment from here:
https://utcc.utoronto.ca/~cks/space/blog/spam/SMTPSmugglingConsequences?showcomments
As already outlined in my last posts, the description of this
vulnerability is somewhat 'strange' because it mixes different but
unrelated 'extensions' of (E)SMTP email.
1. The problem identified has nothing to do with SPF or DKIM; neither
of those protocol extensions are relevant for this case nor are forseen
to cope or mitigate this problem. The same holds for AUTH and StartTLS.
2. The way the authors describe the attack is incomplete.
Taking from the drawing from their site
https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/
they make us believe that the message data includes
"\r\n.\r\n".
The correct way to phrase it is:
...
(message body) <== End of data (might not include a last CRLF)
\r\n.\r\n <== SMTP command to queue the message by the MTA
RFC 5321 (3.3):
"SMTP indicates the end of the mail data by sending a
line containing only a "." (period or full stop)."
It could well be meaning: 'Take the last five bytes of the received
data stream'.
RFC 5321 (2.3.8) also defines/demands:
"Lines consist of zero or more data characters terminated by the
sequence ASCII character "CR" (hex value 0D) followed immediately by
ASCII character "LF" (hex value 0A). This termination sequence is
denoted as <CRLF> in this document. Conforming implementations MUST
NOT recognize or generate any other character or character sequence
as a line terminator."
This is again at least irritating. We have to consider:
a) SMTP commands => all need to supplied with <CRLF> as final bytes.
b) RFC 822 message headers => all need to supplied with <CRLF> as final
bytes.
c) The RFC 822 message body => Line length < 998 byte; with no
requirement for <CRLF> (RFC 2822 2.3) line ends.
(s/)qmail's qmail-smtpd handles line ends correctly. About 20 years
ago, there was a discussion on Qmail's mailing list to accept bare line
feeds. Neither vanilla qmail nor my s/qmail follow this path.
3. The authors of the talk/CVE correlate the vulnerability with 'SMTP
pipelining'.
RFC 2920 introduces SMTP pipelining and provides some samples.
Pipelining (command stacking) is happening BEFORE the DATA command is
given. Once the DATA command has been finished (with a single
<CRLF>.<CRLF>) no other SMTP commands should be accepted.
Unfortunately, RFC 2920 (and also other SMTP RFCs) are not clear about
the 'state' of SMTP.
I addressed this here:
https://www.fehcom.de/qmail/smtpauth.html
4. Maybe the author of Postfix (Wietse Venema) followed Postel's law
allowing this behaviour while accepting SMTP mails and they were
trapped by incomplete/misguiding RFCs. And why Timo Longin praises
Witse Venema and Viktor Dukhovni in his talk on the 37C3 about this
issue, I really don't understand. Twilight of the Gods?
Regards and have a Happy New Year!
--eh.
> Erwin Hoffmann <feh@fehcom.de> wrote:
> > Hi Luigi,
> >
> > 'Email smuggling' was just presented as possible problem on
> > December
> > 27th at the CC Congress in Hamburg/Germany:
> >
> > https://fahrplan.events.ccc.de/congress/2023/fahrplan/events/11782.html
> >
> > I need to check about the details. The CVE does not include more
> > specific information to be useful as a guide.
> >
> > Am Freitag, dem 29.12.2023 um 18:04 +0100 schrieb Luigi Trovato:
> > >
> > > Hello and Happy Holidays,
> > > I wanted to ask: are we immune to the recently exposed "smtp
> > > smuggling" vulnerability?
> > > CVE doesn't report (s)qmail as vulnerable but it could be just
> > > because nobody tested it..
> > > https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=smtp+smuggling
> > >
> > > --
> > > Ciao,
> > > Luigi
> >
> > Currently, I'm working on s/qmail 4.3 and will investigate the CVE
> > in
> > more detail.
> >
> > Best regards.
> > --eh.
--
Dr. Erwin Hoffmann | www.fehcom.de
PGP key-id: 20FD6E671A94DC1E
PGP key-fingerprint: 8C6B 155B 0FDA 64F1 BCCE A6B9 20FD 6E67 1A94 DC1E
> This looks like a good explanation:
> https://www.postfix.org/smtp-smuggling.html
>
thanks for the URL Paul, but right now the net is full of comments.
I didn't have time to check s/qmail in detail for the vulnerability,
but would like to reference Leah's comment from here:
https://utcc.utoronto.ca/~cks/space/blog/spam/SMTPSmugglingConsequences?showcomments
As already outlined in my last posts, the description of this
vulnerability is somewhat 'strange' because it mixes different but
unrelated 'extensions' of (E)SMTP email.
1. The problem identified has nothing to do with SPF or DKIM; neither
of those protocol extensions are relevant for this case nor are forseen
to cope or mitigate this problem. The same holds for AUTH and StartTLS.
2. The way the authors describe the attack is incomplete.
Taking from the drawing from their site
https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/
they make us believe that the message data includes
"\r\n.\r\n".
The correct way to phrase it is:
...
(message body) <== End of data (might not include a last CRLF)
\r\n.\r\n <== SMTP command to queue the message by the MTA
RFC 5321 (3.3):
"SMTP indicates the end of the mail data by sending a
line containing only a "." (period or full stop)."
It could well be meaning: 'Take the last five bytes of the received
data stream'.
RFC 5321 (2.3.8) also defines/demands:
"Lines consist of zero or more data characters terminated by the
sequence ASCII character "CR" (hex value 0D) followed immediately by
ASCII character "LF" (hex value 0A). This termination sequence is
denoted as <CRLF> in this document. Conforming implementations MUST
NOT recognize or generate any other character or character sequence
as a line terminator."
This is again at least irritating. We have to consider:
a) SMTP commands => all need to supplied with <CRLF> as final bytes.
b) RFC 822 message headers => all need to supplied with <CRLF> as final
bytes.
c) The RFC 822 message body => Line length < 998 byte; with no
requirement for <CRLF> (RFC 2822 2.3) line ends.
(s/)qmail's qmail-smtpd handles line ends correctly. About 20 years
ago, there was a discussion on Qmail's mailing list to accept bare line
feeds. Neither vanilla qmail nor my s/qmail follow this path.
3. The authors of the talk/CVE correlate the vulnerability with 'SMTP
pipelining'.
RFC 2920 introduces SMTP pipelining and provides some samples.
Pipelining (command stacking) is happening BEFORE the DATA command is
given. Once the DATA command has been finished (with a single
<CRLF>.<CRLF>) no other SMTP commands should be accepted.
Unfortunately, RFC 2920 (and also other SMTP RFCs) are not clear about
the 'state' of SMTP.
I addressed this here:
https://www.fehcom.de/qmail/smtpauth.html
4. Maybe the author of Postfix (Wietse Venema) followed Postel's law
allowing this behaviour while accepting SMTP mails and they were
trapped by incomplete/misguiding RFCs. And why Timo Longin praises
Witse Venema and Viktor Dukhovni in his talk on the 37C3 about this
issue, I really don't understand. Twilight of the Gods?
Regards and have a Happy New Year!
--eh.
> Erwin Hoffmann <feh@fehcom.de> wrote:
> > Hi Luigi,
> >
> > 'Email smuggling' was just presented as possible problem on
> > December
> > 27th at the CC Congress in Hamburg/Germany:
> >
> > https://fahrplan.events.ccc.de/congress/2023/fahrplan/events/11782.html
> >
> > I need to check about the details. The CVE does not include more
> > specific information to be useful as a guide.
> >
> > Am Freitag, dem 29.12.2023 um 18:04 +0100 schrieb Luigi Trovato:
> > >
> > > Hello and Happy Holidays,
> > > I wanted to ask: are we immune to the recently exposed "smtp
> > > smuggling" vulnerability?
> > > CVE doesn't report (s)qmail as vulnerable but it could be just
> > > because nobody tested it..
> > > https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=smtp+smuggling
> > >
> > > --
> > > Ciao,
> > > Luigi
> >
> > Currently, I'm working on s/qmail 4.3 and will investigate the CVE
> > in
> > more detail.
> >
> > Best regards.
> > --eh.
--
Dr. Erwin Hoffmann | www.fehcom.de
PGP key-id: 20FD6E671A94DC1E
PGP key-fingerprint: 8C6B 155B 0FDA 64F1 BCCE A6B9 20FD 6E67 1A94 DC1E
Attached Files:
-
signature.asc (0.48 KB)