Hello Wietse Venema.
Wietse Venema via Postfix-users wrote in
<4yn8j34j6lzj...@spike.porcupine.org>:
|Full disclosure: I was the original finder of the STARTTLS plaintext
|injection problem, which affected Postfix and several other SMTP
|server implementations. See the text and links to other info in
|
|https://www.postfix.org/CVE-2011-0411.html
Oh, such more-data-in-buffer problems came up much later again,
too, fyi. Aah, hahaha, no no, please see here
Commit: Steffen Nurpmeso <stef...@sdaoden.eu>
CommitDate: 2020-07-30 14:28:46 +0200
n_tls_open(): call mx_socket_reset_io_buf() (Kevin McCarthy)..
Introduce mx_socket_reset_{read,write,io}_buf(), and call the
latter after SSL_set_fd() (some time) in order to avoid possible
MITM injections to remain and be evaluated after STARTTLS / STLS.
See CVE-2011-0411 aka http://www.postfix.org/CVE-2011-0411.html.
Seen via mutt, by Kevin McCarthy.
The mutt MUA again. It came over via
Commit: Kevin McCarthy <ke...@8t8.us>
CommitDate: 2020-06-17 14:14:26 -0700
Fix STARTTLS response injection attack.
Thanks again to Damian Poddebniak and Fabian Ising from the Münster
University of Applied Sciences for reporting this issue. Their
summary in ticket 248 states the issue clearly:
We found another STARTTLS-related issue in Mutt. Unfortunately, it
affects SMTP, POP3 and IMAP.
...
There is a nice blogpost by Wietse Venema about a "command
injection" in postfix (http://www.postfix.org/CVE-2011-0411.html).
What we have here is the problem in reverse, i.e. not a command
injection, but a "response injection."
...
I remembered that.
|This is an easy to make mistake, and it is also easy to re-introduce
|unless there are pre-relase checks in place that catch this.
|
|DANE and MTA-STS are ways to discover that a domain or MX host
|supports SMTP over TLS. Neither protects against vulnerabilities
|like CVE-2011-0411. DANE requires DNSSEC, and can protect against
|"downgrade to plaintext" attacks, MTA-STS does not.
|
|I am all in favor of skipping STARTTLS. The Postfix SMTP client
|already TS wrappermode, and all that is needed is a few lines of
|code to automatically turn on TS wrappermode dependng on the service
|name. This can work equaly well for MX lookups or SRV lookups.
|
|(I'd probably add a new SMTP client configuration parameter that
|says "these service names use implicit TLS". So it is more like ~2
|lines of code to convert a parameter value into a matchlist object,
|and another ~2 lines plus error handling to ask this list whether
|a service uses implicit TLS).
|
|I just don't think that it is a good idea to return a NullPort
|response to an SRV query for SMTPS, to announce that a property for
|a different service (SMTP property STARTTLS) is available. I would
|expect that a NullPort response means that the SMPS service is NOT
|AVAILABLE, similar to a Null MX response.
I have changed this, together with lots of other problems that
Jeremy Harris has pointed out, in
https://www.ietf.org/archive/id/draft-nurpmeso-smtp-tls-srv-03.txt
|Without DNSSEC, your idea cannot protect against "downgrade to
|plaintext" attacks. It is less useful than other available mechansisms
|to discover whether a domain supports SMTP over TLS.
It is true that secure DNS is a precondition. As true as it is
for DANE. That is the *only* advantage of that -STS thing,
because it goes over HTTPS (and the hardly maintainable
.well-known trashbin). I want to point out HTTPS mostly means the
CA certificate pool. Whatever that means, i do not truly know;
but real trust i do not have. I am all for DANE per se, even raw
public certificates, the IETF has quite a lot of solutions which
would address the problems, if only they would come into play.
Even then there is *no* upgrade path for Implicit TLS defined by
the IETF for SMTP yet. That is plain fact. And your arguments
are just as valid for IMAP, for the unfortunately dying POP3 (i
would only have needed two more commands to be happy, i think it
is about syncing iirc), SUBMISSION, as long as the *S discovery is
performed via SRV, at least. "Less useful" is a bit harsh thus,
given those things are standardized since decades.
I mean secure DNS also does not necessarily mean DNSSEC, it could
also mean TLS secured DNS zone transfer / lookup of a server, and
then TLS secured DNS lookup of a client to that server. (The
whole chain of merde, as is mostly well-known, that is.) In the
second when major players truly start supporting DNSSEC that ship
has sailed completely. I cannot help that. It is *only* -STS, no
plural in that mechanisms. (And it is totally overengineered, to
have that mentioned once. I do not look now *how* much, but it is
very much. Then rather a serialized SVCB RR to satisfy also
Viktor and to be looked up via HTTPS, no more no less.)
| Wietse
There is an extensive infrastructure of the IETF, including DANE,
that relies upon DNSSEC. (Crossing fingers here.)
--End of <4yn8j34j6lzj...@spike.porcupine.org>
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|In Fall and Winter, feel "The Dropbear Bard"s pint(er).
|
|The banded bear
|without a care,
|Banged on himself for e'er and e'er
|
|Farewell, dear collar bear
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
