-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

*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
doesn't use this actual library in any of its products, but a derivate
version without the double invocation issue. 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.

06-04-2013 - Cisco's PSIRT asks Groundworks Technologies to correct
the timeline's paragraph mentioning that Cisco has no intention on
publishing a security notice (line 113). The paragraph mentions that
the reason is because Cisco doesn't use this library, and the correct
statement is that they don't use this actual library version but a
derivate version without the double invocation issue.

06-03-2013 - Groundworks Technologies publish an amendment for this
advisory changing the following sentences,

@113
- -05-30-2013 - PSIRT answers saying that they have no intention on
- -publishing any security notice regarding this issue, because Cisco
- -doesn'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.
@113
+05-30-2013 - PSIRT answers saying that they have no intention on
+publishing any security notice regarding this issue, because Cisco
+doesn't use this actual library in any of its products, but a
derivate +version without the double invocation issue. 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.



*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/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRrkecAAoJEA60Yy1ZGlWzv9MQAKnJvrO2KrXv7v807TpUmN9/
HQjr6xFPfnDxir3WM5l0mWAA3bJnUOAZd9peZY1qr7nBFtmPzQP3ZPMZOfgd6LNS
U/p93GCzGtnIkaJ5OOXTAgTzHoMFqh+ryVhgpkxr8oWj/w0G+LXLv+djaa6jClO8
tt9aK6+7HJIwycB48l+J+nqwWHu31Obrmrx9sd/Wputkc0Gxwl/37cAsVRkPu2o5
jpMjJJ+oBxI8Zvo8RvrNsRP6HdEpwAxnmJNyRS9Jd6a5elPK1xJgkeTmPzttvTsM
u+6BkYmM9SpGA58DlrbIqH/R0Bq+9Hz7D6vzj2cvYU+1oPO5lo/Ri5mIaXDKvmMF
vUovaCl1xC7qql/mDH14SKwfl0tkiQTpkRuHW8x9UJ/B1IZ8+kc2IoTJ9K3O1IkV
yq+9RQqHlZwYAgniBPQblTLRDQ0XODL5xyrCQvfg90Sd6jqjllTwyss9cdD+MphI
QW2goklVVmxmSOq31OvHKFJHSsjJJE1vBPB83z3dfvjfmPkwEbeq9SwZJwj3SY4B
aK8ticyYOUskjDLBE3FmuTgZYZ4XpSQrYJRRaRNQ+VmTFmET5LgqB9umfSWBZdih
SSaRSrGfZLWFNLe0uamJRSp7kIxvfUP1qOnltIjEFjfibow2WtTU++dfM9ikk0Bw
/zNaGqyaaW1U9x+2uCRc
=qs1C
-----END PGP SIGNATURE-----