Re: SMTP Smuggling

Matus UHLAR - fantomas writes:

>> Christoph Mitasch via courier-users writes:
>>> « HTML content follows
>>>
>>> is Courier MTA affected by the new SMTP smuggling attack?
>>>
>>> <URL:https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails- 
>>> worldwide/>https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e- 
>>> mails-worldwide/
>
> On 16.01.24 08:21, Sam Varshavchik wrote:
>> Nope, I see no issues here.
>>
>> Courier accepts either CRLF or LF as end of line sequence on inbound mail,  
>> and correctly un-dot-stuffs the message. On the outbound side Courier always  
>> uses CRLF, and always dot-stuff the message's contents. This is elementary  
>> SMTP. Any attempt to use Courier to leverage this exploit will fail.
>
> There's still question if courier can detect message that's been smuggled  
> through server not aware of this issue and what will courier do if this  
> happens.

Courier will see the smuggled message as part of the content of the carrier  
message, which gets to its dummy recipient, if the exploited mail server  
preserves bare LFs, which is probably the case most of the time.

If the exploited mail server is doubly-broken (replaces the bare LFs with  
CRLFs and does not dot-stuff the outgoing message) there's an infinitesimal  
chance that the garbled message will be accepted by Courier. For that to  
happen the actual TCP packet from the broken mail server needs to terminate  
precisely after <CRLF>.<CRLF> and before the smuggled message. And the first  
packet with the smuggled message must have its reception delayed long enough  
for the Courier to grab the already-delivered packet from the kernel (so  
even though there is some level of control that might be possible, by the  
hostile actor to arrange for specific packet boundaries that the broken mail  
server will send, that alone won't be enough). This is because Courier uses  
bulk reads for DATA, and assumes that the sender will stop sending  
everything voluntarily and wait for the response. SMTP does not require  
pipelining after DATA, so anything that's already been read after  
<CRLF>.<CRLF> will be quietly discarded.

All of that is subject to NATs, firewalls and routers playing games with  
packets. Note that the hostile actor is unlikely to have any operational  
control over the broken mail server, beyond injecting it with the smuggled  
message on the inbound side, more substantial control is needed to make the  
vulnerable mail server control its stream connection to Courier, in order to  
achieve this odds-defying feat.

_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRupkKLJP96aW75pIOKYPgoojZS4gUCZacUGwAKCRCKYPgoojZS
4kTAAP9QSgmQbShiexY9f+KObbGt1WCXmuAc9fGVHiJa2fKRtgD/ZSG5Owh+qY3r
rygvQKvlGIGPv3CWbIahLUx16JoqVQQ=
=Bn6H
-----END PGP SIGNATURE-----