*Title* Libsrtp srtp_protect/hmac_compute buffer overflow *Affected products* - - libsrtp (https://github.com/cisco/libsrtp) all versions *Description* Libsrtp is the Cisco Systems, Inc. reference implementation of the Secure Real-time Transport Protocol (SRTP), RTP is the Real-time Transport Protocol, an IETF standard for the transport of real-time data such as telephony, audio, and video, defined by RFC 3550. Secure RTP (SRTP) is an RTP profile for providing confidentiality to RTP data and authentication to the RTP header and payload. SRTP is an IETF Proposed Standard, defined in RFC 3711, and was developed in the IETF Audio/Video Transport (AVT) Working Group. There is a buffer overflow in libsrtp based on how the function crypto_policy_set_from_profile_for_rtp applies the cryptographic profiles srtp_profile_aes128_cm_sha1_32/srtp_profile_aes256_cm_sha1_32 to a srtp_policy, as shown by the source code of srtp/srtp.c (line 2059, #b705554) err_status_t crypto_policy_set_from_profile_for_rtp( crypto_policy_t *policy, srtp_profile_t profile) { ... case srtp_profile_aes128_cm_sha1_32: crypto_policy_set_aes_cm_128_hmac_sha1_32(policy); crypto_policy_set_aes_cm_128_hmac_sha1_80(policy); break; ... case srtp_profile_aes256_cm_sha1_32: crypto_policy_set_aes_cm_256_hmac_sha1_32(policy); crypto_policy_set_aes_cm_256_hmac_sha1_80(policy); break; ... The above code shows that the functions crypto_policy_set_* are called in more than one opportunity with different policies, setting the member auth_tag_len of the crypto_policy_t struct to 10 bytes instead of 4 bytes which is expected. Later, when an auth_type_t for our selected crypto policy is allocated, it will has a wrong value in the member out_len. The buffer overflow arise when the function srtp_protect() tries to add the authentication tag to the packet using the macro auth_compute(), which expands to a hmac_compute() function using the out_len member mentioned previously as length for a write operation, writing 6 bytes more than expected to the buffer pointed by the rtp_hdr argument, triggering a buffer overflow. *Security Patches* - - Cisco has fixed this issue in the public repository of the libsrtp. *Credits* This security issue was discovered and researched by Fernando Russ (fruss), Security Researcher of Groundworks Technologies (http://www.groundworkstech.com) *Time line* 05-23-2013 - Groundworks Technologies contacts Cisco's PSIRT about a potential vulnerability in libsrtp. 05-23-2013 - PSIRT acknowledge the reception of the report and assigns the PSIRT-0717634467 track number to the issue. 05-24-2013 - PSIRT informs that they had started researching the issue, keeping Groundworks Technologies posted about this. 05-28-2012 - A Issue called "Potential buffer overflow in srtp_protect()" is publicly opened with id #24 in libsrtp's github repo without any credits to Groundworks Technologies. (https://github.com/cisco/libsrtp/issues/24) 05-28-2012 - A patch to the libsrtp's documentation hinting this issue was committed with id #5e33729 (https://github.com/cisco/libsrtp/commit-5e33729c149aa698433c3 f9375c6e8bb21cc3e56) 05-30-2013 - PSIRT informs that this issue is a "documentation" issue, and they will fit it according. PSIRT justifies this saying, [...]"A conservative design would ensure that there was enough room at the end of the packet for a 10-byte authentication tag, which is the length recommended by the standard. If the implementations did this, then the bug in the "set from profile" function wouldn't cause any issues."[...] 05-03-2012 - Groundworks Technologies responds to Cisco's PSIRT saying, [...]"From my point of view, allocating more space in a buffer to avoid a buffer overflow triggered because we setup the library to write a 32bits tag at the end of a buffer and it writes 80bits because its applies the wrong crypto policy... has nothing to do with "conservative design" or "documentation". It's a bug with security implications."[...] Groundworks asks about if there is any intention of publishing a PSIRT security notice regarding this issue and tell about the uncredited ticket #24 which appears before the last notification. Also, Groundworks Technologies informs that it will make this issue public. 05-30-2013 - PSIRT answers saying that they have no intention on publishing any security notice regarding this issue, because Cisco don't use this library in any of its products. Also said, that the library is maintained by purely voluntarism of its maintainers. Also, they said that they will fix the credits for the Issue #24 a soon as possible. 05-30-2013 - The credits information for the Issue #24 was added. 05-30-2013 - A pull request with the final patches for this issue was submitted with id #26 (https://github.com/cisco/libsrtp/pull/26) 06-03-2013 - Groundworks Technologies publish this advisory. *License* The contents of this advisory are copyright (c) 2013 Groundworks Technologies, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License: http://creativecommons.org/licenses/by-nc-sa/3.0/us/