Yes, that fix should address the vulnerability. There was one Cisco
product that reported an issue with this patch. Specifically, it
prevents a zero length payload packet from being decrypted. We never
received reports of this problem from downstream open source projects.
So you're probably safe with only applying this patch. But we did
augment the patch after the Cisco issue to address the zero payload
decryption problem.
On 03/31/2016 04:21 PM, Markus Koschany wrote:
Control: severity -1 grave
Control: tags -1 patch
Am 31.03.2016 um 15:14 schrieb John Foley:
It's my understanding the obsolete versions of libsrtp are vulnerable.
Quoting the original text from Randell Jesup...
srtp_unprotect (netwerk\srtp\src\srtp\srtp.c) can experience an
integer underflow. If it does, it calls a decryption function with a
buffer pointer pointing to memory to which it has no right, and with
a very large buffer length. This call could scramble large portions
of memory, causing incorrect and possibly insecure behavior.
The bug is in this code:
950: err_status_t
951: srtp_unprotect(srtp_ctx_t *ctx, void *srtp_hdr, int *pkt_octet_len) {
...
1073: if (stream->rtp_services & sec_serv_conf) {
1074: enc_start = (uint32_t *)hdr + uint32s_in_rtp_header + hdr->cc;
1075: if (hdr->x == 1) {
1076: srtp_hdr_xtnd_t *xtn_hdr = (srtp_hdr_xtnd_t *)enc_start;
1077: enc_start += (ntohs(xtn_hdr->length) + 1);
1078: }
1079: enc_octet_len = (uint32_t)(*pkt_octet_len - tag_len
1080: - ((enc_start - (uint32_t *)hdr) << 2));
1081: } else {
1082: enc_start = NULL;
1083: }
Thanks for your quick response and clarification. If I understand
correctly we can basically apply the same patch for our version in
Wheezy and Jessie and guard against the potential integer underflow by using
if (!((uint8_t*)enc_start < (uint8_t*)hdr + (*pkt_octet_len - tag_len)))
return err_status_parse_err;
before
enc_octet_len = (uint32_t)(*pkt_octet_len - tag_len
- ((enc_start - (uint32_t *)hdr) << 2));
Since it is clear now that Jessie and Sid are affected, I am going to
raise the severity to grave again. Please find attached my proposed
debdiffs.
Regards,
Markus
