Re: [mailop] SMTP smuggling

[Thomas Walter via mailop]

Hello everyone,

On 19.12.23 13:31, Mark Alley via mailop wrote:
Hey all, recently saw this mail server SMTP vulnerability that popped up 
on a blog yesterday. Sharing here for those interested.


https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/ 



just for reference, here is the talk Timo gave at 37C3:

https://youtu.be/V8KPV96g1To

Regards,
Thomas Walter

--
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP smuggling

[Gellner, Oliver via mailop]

On 03.01.2024 at 23:15 Brandon Long wrote:


Hmm, doesn't this also depend on improper handling of pipelining?

You can't pipeline past DATA, 
https://datatracker.ietf.org/doc/html/rfc2920#section-3.1

I guess if the sender is sending line by line, maybe the server would only have 
up to the DATA in the tcp buffer and process the DATA before reading more.
Otherwise, having extra data available after the DATA command would be 
indicative of a misbehaving client.

Yes, you shouldn’t be able to pipeline past DATA, but apparently some MTAs 
accept this nonetheless. Probably for the very same reason as they accept LF or 
CR as line terminators: Misbehaving clients.

Even without being able to pipeline the whole SMTP conversation at once, it 
would be possible that a packet ends just after DATA. Also there is chunking 
mode with which DATA might not be used at all.

—
BR Oliver

dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.


smime.p7s
Description: S/MIME cryptographic signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP smuggling

[John Levine via mailop]

It appears that Brandon Long via mailop  said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>Hmm, doesn't this also depend on improper handling of pipelining?

Yes.  The postfix patch to fix this checks for early talking past data.

R's,
John

>You can't pipeline past DATA,
>https://datatracker.ietf.org/doc/html/rfc2920#section-3.1
>
>I guess if the sender is sending line by line, maybe the server would only
>have up to the DATA in the tcp buffer and process the DATA before reading
>more.
>Otherwise, having extra data available after the DATA command would be
>indicative of a misbehaving client.  Even before I implemented pipelining,
>we
>enforced that clients weren't misbehaving that way to ensure we were
>connected to an smtp client and not just a dumb pipe.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP smuggling

[Brandon Long via mailop]

Hmm, doesn't this also depend on improper handling of pipelining?

You can't pipeline past DATA,
https://datatracker.ietf.org/doc/html/rfc2920#section-3.1

I guess if the sender is sending line by line, maybe the server would only
have up to the DATA in the tcp buffer and process the DATA before reading
more.
Otherwise, having extra data available after the DATA command would be
indicative of a misbehaving client.  Even before I implemented pipelining,
we
enforced that clients weren't misbehaving that way to ensure we were
connected to an smtp client and not just a dumb pipe.

Maybe a different reading is possible, that the requirements are that the
client should wait on data response, not that the server should enforce
that.

Alternatively, using this as the only defense here would be insufficient
since it may depend on timing and how the clients sending happened to fit
into outbound
buffers or what the server happens to read.

Brandon

On Wed, Dec 20, 2023 at 1:22 PM Geert Hendrickx via mailop <
mailop@mailop.org> wrote:

> On Wed, Dec 20, 2023 at 14:49:20 +, Gellner, Oliver via mailop wrote:
> > Postfix is potentially vulnerable as for compatibility with broken
> > clients it accepts . as an end-of-data command. Well, at least
> > it did, Wietse has introduced a flag which fixes this kind of message
> > smuggling:
> >
> > > Protocol enforcement: with "smtpd_forbid_bare_newline =
> > > yes" (the default for Postfix 3.9), reply with "Error: bare
> > >  received" and disconnect when an SMTP client sends a
> > > line ending in , violating the RFC 5321 requirement
> > > that lines must end in . Files: mantools/postlink,
> > > proto/postconf.proto, global/mail_params.h, global/smtp_stream.c,
> > > global/smtp_stream.h, smtpd/smtpd.c.
> >
> > It will be available in the next releases for the 3.5 to 3.9 versions,
> > although the new flag will be disabled on all versions except 3.9 by
> > default.
>
>
> For more info on Postfix fixes and timeline, see:
>
> https://www.mail-archive.com/postfix-users@postfix.org/msg100901.html
>
>
> Geert
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] SMTP Smuggling, a short-term workaround for Postfix smtpd

[Randolf Richardson, Postmaster via mailop]

If you're not using the newest (patched) version of Postfix smtpd, a 
short-term workaround for the SMTP Smuggling problem was announced 
today (2023-Dec-26) that "will stop many forms of the published 
attack" from succeeding:

Postfix :: SMTP Smuggling :: Short-term workarounds
https://www.postfix.org/smtp-smuggling.html#short

The long-term fix is also covered in the same document.  At least 
this short-term fix can be helpful for those who are still using 
older versions of Postfix, and/or haven't applied the 
anti-SMTP-Smuggling security patches.

Hopefully this will be helpful to mail systems administrators who 
need it and provide at least some relief over the holiday season.

*** A special note of appreciation goes to the Postfix developers, 
and the entire team of people who work on Postfix and contribute to 
the project, for working on this over the holiday season -- your 
efforts are important and tremendously helpful.  Thank you. ***

-- 
Postmaster - postmas...@inter-corporate.com
Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.com/


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP smuggling

[Geert Hendrickx via mailop]

On Wed, Dec 20, 2023 at 14:49:20 +, Gellner, Oliver via mailop wrote:
> Postfix is potentially vulnerable as for compatibility with broken
> clients it accepts . as an end-of-data command. Well, at least
> it did, Wietse has introduced a flag which fixes this kind of message
> smuggling:
> 
> > Protocol enforcement: with "smtpd_forbid_bare_newline =
> > yes" (the default for Postfix 3.9), reply with "Error: bare
> >  received" and disconnect when an SMTP client sends a
> > line ending in , violating the RFC 5321 requirement
> > that lines must end in . Files: mantools/postlink,
> > proto/postconf.proto, global/mail_params.h, global/smtp_stream.c,
> > global/smtp_stream.h, smtpd/smtpd.c.
> 
> It will be available in the next releases for the 3.5 to 3.9 versions,
> although the new flag will be disabled on all versions except 3.9 by
> default.


For more info on Postfix fixes and timeline, see:

https://www.mail-archive.com/postfix-users@postfix.org/msg100901.html


Geert


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP smuggling

[Gellner, Oliver via mailop]

On 19.12.2023 at 13:31 Mark Alley via mailop wrote:

> Hey all, recently saw this mail server SMTP vulnerability that popped up on a 
> blog yesterday. Sharing here for those interested.
> https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/

Thanks for sharing, interesting read! I'd just appreciate it if such full 
disclosures would not accumulate shortly before christmas, although I 
understand that in this case they want to present their findings at CCC at the 
end of December.

Postfix is potentially vulnerable as for compatibility with broken clients it 
accepts . as an end-of-data command. Well, at least it did, Wietse has 
introduced a flag which fixes this kind of message smuggling:

> Protocol enforcement: with "smtpd_forbid_bare_newline =
> yes" (the default for Postfix 3.9), reply with "Error: bare
>  received" and disconnect when an SMTP client sends a
> line ending in , violating the RFC 5321 requirement
> that lines must end in . Files: mantools/postlink,
> proto/postconf.proto, global/mail_params.h, global/smtp_stream.c,
> global/smtp_stream.h, smtpd/smtpd.c.

It will be available in the next releases for the 3.5 to 3.9 versions, although 
the new flag will be disabled on all versions except 3.9 by default.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP smuggling

[Alessandro Vesely via mailop]

On Tue 19/Dec/2023 21:19:06 +0100 Marco Moock via mailop wrote:

Am 19.12.2023 um 17:20:20 Uhr schrieb Slavko via mailop:

Please, understand i properly, that it is no vulnerabiliy in SMTP 
itself, but in (some) implementations/servers only?


According to the stuff I read, sendmail and Postfix (and more) are 
affected, for sendmail a patched version exists and the behavior can be 
controlled in accessdb for specific hosts if needed.



A tool to check vulnerability is trivial if you already have an SMTP client. 
However, they are delaying the publication of their tool "maybe already at the 
37C3 conference", which is to be held on 27-30 December 2023.



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP smuggling

[Marco Moock via mailop]

Am 19.12.2023 um 17:20:20 Uhr schrieb Slavko via mailop:

> Please, understand i properly, that it is no vulnerabiliy in SMTP
> itself, but in (some) implementations/servers only?

According to the stuff I read, sendmail and Postfix (and more) are
affected, for sendmail a patched version exists and the behavior can be
controlled in accessdb for specific hosts if needed.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP smuggling

[ml+mailop--- via mailop]

On Tue, Dec 19, 2023, Slavko via mailop wrote:

> Please, understand i properly, that it is no vulnerabiliy in SMTP itself,
> but in (some) implementations/servers only?

The RFC is very precise about line endings and "end of message".
Some (legacy) MTAs try to be "nice" and accept other line endings
which can be abused in certain situations.

-- 
Please don't Cc: me, use only the list for replies, even if the
mailing list software screws up the Reply-To header.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP smuggling

[Slavko via mailop]

Dňa 19. decembra 2023 12:31:11 UTC používateľ Mark Alley via mailop 
 napísal:
>Hey all, recently saw this mail server SMTP vulnerability that popped up on
>a blog yesterday. Sharing here for those interested.

Please, understand i properly, that it is no vulnerabiliy in SMTP itself,
but in (some) implementations/servers only?

thanks


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] SMTP smuggling

[Mark Alley via mailop]

Hey all, recently saw this mail server SMTP vulnerability that popped up on
a blog yesterday. Sharing here for those interested.

https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/

-Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop