[GTA-2013-01] - Libsrtp srtp_protect/hmac_compute buffer overflow

[Groundworks Technologies Advisories Team <advisories () groundworkstech com>]

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

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

iQIcBAEBAgAGBQJRrKcCAAoJEA60Yy1ZGlWzJYcQAMcubv1fHHyn5KQUkh18CjOC
c6c91quQBFY/69cT1CROnLxKxuTvkTberaB8+mgPAJPZv6buAzcXyZvYcjV/tnvU
0eTrx66+tTXZ4k8rFDQz4+bHdUziap2i0jL83ttri+AJSPYniZignlPNbYhME9qw
awt4z0jMcwU0Zi7XRSLMO6vuLF1rT38yjbvfJNsKfb6XzM09ei0Mtxgrc7+mQh2y
9EviiBezYPCjvfzftUcB6mVIzwwbS/N/iFdvghidYanR90eBWMiIPrCIje+zO075
p0n3BQAyOzlk0ZXdSyXYVUH3vbCtUTuh+f5JSw1fGyoKN9AAh7IqHYgv9VToisYV
0Cp8eDI4WS+tXOPCJ7hrbrzNXKPXyvdyFQlZrfjsU8rRtuQ4PWU1PGjzQMaQjVyN
7FDpmaUzGMJltEI1p8d1ClRQIooEdM/E9DOOqiZ1kB1784knIaX1AMOS3raBrJ+x
09ZgggL5WioPiarpWgSa7Y04f2/NY0IlVTpp2bM+wT0h40F2KpS/DFlbIaFQSbYR
6a5Ca3nHDUhoI+lWQi1Ixx424kIwTvzvXNDmJOCMcDgWmbU4QyRVfKVrfenx6eZo
cSQEEpQdf2lPELsUYDBoWLqMgRgbol4GbvxVKYTVRWEm+/XGVwJWJz7CiHUERM62
yxAOE0mnjYNfL3Kcdhcj
=K1yw
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/