On Mon, Dec 18, 2023 at 02:48:43PM -0500, Bill Cole via Postfix-users wrote:

> > This research work has now been published by Sec Consult company, see
> > link below .
> 
> It is interesting that they seem to be unaware of some SMTP basics, such as
> the fact that message bodies, message headers, and the SMTP protocol have
> different format rules, defined in different RFCs that are clearly marked as
> such. They seem to think that the problem is grounded in legitimate
> misunderstanding of imprecise RFCs, when it seems clear to me that there's
> one right interpretation.
> 
> That very much ruins my ability to take what they are saying seriously. I
> believe they tested against the proprietary systems cited and found the
> issue, I find it extremely suspect that they show no examples for Sendmail
> or Postfix, merely an assertion.
> 
> > The Postfix issues the researcher mentions, we were not able to actually
> > reproduce
> 
> This is unsuprising.

- Postfix 3.9 (pending official release soon), rejects unuthorised
  pipelining by default: "smtpd_forbid_unauth_pipelining = yes".

- Postfix 3.8.1, 3.7.6, 3.6.10 and 3.5.20 include the same supporting
  code as 3.9 snapshots, but the "smtpd_forbid_unauth_pipelining"
  parameter defaults to "no".

  This default avoids breaking compatibility in a patch to stable
  release, in case some fax-to-email machine, or other minimally
  conformant device performs illegal pipeling.

  However, for most users it is IMHO prudent to override the default to
  "yes" in their configuration, after ensuring that that this is
  compatible with their mail flows.

With illegal pipelining blocked by default, the described attempts to
inject multiple messages into Postfix as a receiving system will fail.
This is because with very high probability any "<LF>.<LF>" will be
immediately followed by some part of the rest of the original message
content in the same TCP frame, or the next TCP frame in same TCP window.

To succeed, the sending TCP would have to exactly fill a TCP window with
content up and including the <LF>.<LF>, and would have to be stalled
waiting for missing ACKs.

As an outbound server, Postfix will never send <LF>.<LF>.  Its output
will always be RFC-conformant.  So any impact falls largely on systems
that send illegal bare LF in (non-BDAT) SMTP.

It should also be noted that the piggybacked message will not have a
matching DKIM signature, and can only succeed via SPF alignment.

It may be time to consider ditching SPF.

And of course, all that this "attack" achieves is "From:" header
"forgery", in cases where the outbound server would normally not allow
the submission client to use a "From:" header of their choice.

My personal view is that phishing attacks largely rely on distracting
the user with flashy message content that draws attention away from any
"From:" header that suggest the message is not "authentic".

None of the fake "Geek Squad" bills I receive on a steady basis actually
have a related domain in "From:".  They work to defraud some of their
marks by presending artfully constructed content with all the right
logos that looks like a plausible "Geek Squad" bill.

So I don't see much point for phishers to try to achieve "From:"
alignment when they can simply not bother.

-- 
    Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Reply via email to