GSSAPI SASL auth code sends extra null byte in authorization identity
I recently debugged an interoperability issue between fetchmail and Exchange 2013, and I believe Mutt has the same bug in its native GSSAPI auth code. This is from code inspection; the mutt binary I use does GSSAPI auth via Cyrus SASL and does not exhibit this issue.
In the last step of GSSAPI SASL authentication, the client sends a wrap token containing the security level (one byte), buffer size (three bytes), and the authorization identity in the remaining bytes. In Mutt's native imap/auth_gss.c the end of the code to assemble this wrap token is:
strncpy (buf1 + 4, idata->conn->account.user, sizeof (buf1) - 4);
request_buf.value = buf1;
request_buf.length = 4 + strlen (idata->conn->account.user) + 1;
maj_stat = gss_wrap (&min_stat, context, 0, GSS_C_QOP_DEFAULT, &request_buf,
&cflags, &send_token);
The + 1
at the end of the request_buf.length computation will cause a trailing null byte to be included with the authorization identity. Although it is easy for a C server implementation to ignore that byte, Exchange 2013 rejects authorization identities with the trailing null byte and is within its rights to do so. Cyrus SASL does not add the trailing null byte and interoperates with Exchange 2013.
(Also if the length of the username exceeds 8188 this code will overrun buf1, but that seems unlikely to be a practical issue as the username is in control of the user and will never be that long.)