Viktor Dukhovni:
> On Thu, Aug 23, 2018 at 09:04:15AM -0400, Viktor Dukhovni wrote:
>
> > Which means that the client's subsequent message is a single line
> > of base64 containing the client's initial GSS token:
> >
> > <base64-of-token>
> >
> > this line could be up to 12288 (or more) bytes long. In this context
> > Postfix should be prepared to read multiple 4k buffers up to a
> > generous line limit of 16k or more. If that's not the case, we're
> > somewhat out of spec in our SASL implementation. If, on the other
> > hand, the client's initial token is sent with the "AUTH GSSAPI"
> > command despite its excessive length, then the client is out of
> > spec. Looking at the traffic should show which is at fault.
>
> It looks like Postfix is not prepared to receive large tokens:
>
> src/smtpd/smtpd_sasl_glue.c:
>
> 309 /*
> 310 * Receive the client response. "*" means that the client gives
> up.
> 311 * XXX For now we ignore the fact that an excessively long
> response
> 312 * will be chopped into multiple responses. To handle such
> responses,
> 313 * we need to change smtpd_chat_query() so that it returns an
> error
> 314 * indication.
> 315 */
> 316 smtpd_chat_query(state);
>
> We need to replace smtpd_chat_query() with a sasl-specific function
> that calls smtp_get_line() one or more times as necessary to read
> and combine any partial lines to yield a complete client token, up
> to a limit of 12288 or more bytes (9K bytes before base64 encoding).
Fine as long as it does not introduce a memory exhaustion vulnerability,
and as long as it handles time limits and EOF consistent with other SMTP
server inputs.
If the response has a length indication perhaps one could benefit
from the brand-new smtp_fread() call (added for BDAT support).
Wietse
