*** src/lib/gssapi/krb5/k5unseal.c (revision 19510) --- src/lib/gssapi/krb5/k5unseal.c (revision 19511) *************** *** 457,464 **** if ((ctx->initiate && direction != 0xff) || (!ctx->initiate && direction != 0)) { ! if (toktype == KG_TOK_SEAL_MSG) xfree(token.value); *minor_status = G_BAD_DIRECTION; return(GSS_S_BAD_SIG); } --- 457,467 ---- if ((ctx->initiate && direction != 0xff) || (!ctx->initiate && direction != 0)) { ! if (toktype == KG_TOK_SEAL_MSG) { xfree(token.value); + message_buffer->value = NULL; + message_buffer->length = 0; + } *minor_status = G_BAD_DIRECTION; return(GSS_S_BAD_SIG); } REFERENCES ========== This announcement is posted at: http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2007-003.txt This announcement and related security advisories may be found on the MIT Kerberos security advisory page at: http://web.mit.edu/kerberos/advisories/index.html The main MIT Kerberos web page is at: http://web.mit.edu/kerberos/index.html CVE: CVE-2007-1216 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1216 ACKNOWLEDGMENTS =============== This bug was found while exercising the GSS-API library using the GSSTEST test program provided by SAP AG. DETAILS ======= The kg_unseal_v1() function in src/lib/gssapi/krb5/k5unseal.c frees memory allocated for the "message_buffer" gss_buffer_t when it detects an invalid direction encoding on the message. It does not set the pointer to NULL, nor does it set the length to zero. An application subsequently calling gss_release_buffer() on this gss_buffer_t will cause memory to be freed twice. Much code provided with MIT krb5 does not attempt to call gss_release_buffer() when gss_unseal() or gss_unwrap() fails, even though the GSS-API C-bindings specification permits it to do so. The RPCSEC_GSS authentication flavor for the RPC library, introduced in krb5-1.4, does call gss_release_buffer() when gss_unwrap() fails. This allows an authenticated attacker to trigger a double-free situation. Third-party applications calling the RPC library provided with MIT krb5 and using the RPCSEC_GSS authentication flavor are vulnerable. Third-party applications calling the MIT GSS-API library are vulnerable if they call gss_release_buffer() when they experience errors from gss_unseal() or gss_unwrap(). REVISION HISTORY ================ 2007-mm-dd original release Copyright (C) 2007 Massachusetts Institute of Technology