While reviewing code I noticed some dead code. It was not possible to
default to the channel variable because the parameter could not be
both full and empty.
If the parameter is not a non zero length string then the code looked
like it was intending to default to the channel variable
'presence_data_cols'. If neither of these are the case it is a noop.
By enabling the dead code, you now have access to set the
'presence_data_cols' in the dialplan or scripts like lua.
* commit '64fc3f7934888175b80e0cdd3a065d717d0a9014':
Changed the function parameter name in the function definition to match the updated parameter name in the function declaration. #doxygen
Changed the variable name for clarity.
There was a parameter mismatch between abs(), which expects an int,
and atol() which returns a long. Since max_drift is defined as an int,
there is no need to pars q as a long rather than an int.
Clang 3.5 reported the following error: error: taking the absolute
value of unsigned type 'unsigned int' has no effect
[-Werror,-Wabsolute-value]
Subtracting unsigned variables will never be negative and will either
be the small expected value or will wrap to a very big value. This
code is trying to determine if the difference between these timestamps
is greater than 16000.
The variables last_write_ts and this_ts deal with timestamps. In the
normal case this_ts will be a larger timestamp than
last_write_ts. This change will maintain the intended behavior of
reseting the video if the difference is larger than
16000 and in the abnormal case this value would wrap and still exceed
the 16000.
Building with Clang 3.5 gave the following warning: error: comparison
of array 'iface_out.sin6_addr.__in6_u.__u6_addr8' equal to a null
pointer is always false [-Werror,-Wtautological-pointer-compare]
This is a problem because as it is written the check will never be
true. A pointer to a structure within a structure will never be null. The
intention was either to null check the pointer or to check if the IP
address itself was not zero.
From context in the code this appeared to be a pointer null check so I
removed it.
There was a parameter mismatch between abs(), which expects an int,
and atol() which returns a long. Since max_drift is defined as an int,
there is no need to pars q as a long rather than an int.
In `srtp_unprotect_rtcp()` we are not validating that the packet
length is as long as the minimum required. This would cause
`enc_octet_len` to underflow, which would cause us to try to decrypt
data past the end of the packet in memory -- a buffer over-read and
buffer overflow.
In `srtp_protect_rtcp()`, we were similarly not validating the packet
length. Here we were also polluting the address of the SRTCP
encrypted flag and index (the `trailer`), causing us to write one word
to a bogus memory address before getting to the encryption where we
would also overflow.
In this commit we add checks to appropriately validate the RTCP/SRTCP
packet lengths.
`srtp_unprotect_rtcp_aead()` (but not protect) did correctly validate
the packet length; this check would now be redundant as the check in
`srtcp_unprotect_rtcp()` will also run first, so it has been removed.
In the defined AEAD modes, SRTP packets must always be encrypted and
authenticated, but SRTCP packets may be only authenticated. It's
possible, therefore, for us to end up in `srtp_protect_aead()` without
the `sec_serv_conf` bit being set. We should just ignore this and
encrypt the RTP packet anyway.
What we are doing instead is encrypting the packet anyway, but setting
`enc_start` to NULL first. This causes `aad_len` to underflow which
will cause us to over-read in `cipher_set_aad()`.
If we could get past that, we would try to read and write memory
starting at 0x0 down in `cipher_encrypt()`.
This commit causes us to not check the `sec_serv_conf` bit and never
set `enc_start` to NULL in `srtp_protect_aead()`.
`srtp_unprotect_aead()` does not contain a similar error.
When computing the start address of the RTP data to encrypt or SRTP
data to decrypt (`enc_start`), we are using `hdr->cc` (the CSRC
count), which is untrusted data from the packet, and the length field
of an RTP header extension, which is also untrusted and unchecked data
from the packet.
This value then pollutes our calculation of how much data we'll be
encrypting or decrypting (`enc_octet_len`), possibly causing us to
underflow.
We'll then call `cipher_encrypt()` or `cipher_decrypt()` with these
two values, causing us to read from and write to arbitrary addresses
in memory.
(In the AEAD functions, we'd also pollute `aad_len`, which would cause
us to read undefined memory in `cipher_set_aad`.)
This commit adds checks to verify that the `enc_start` we calculate is
sane based on the actual packet length.
We're checking whether we've hit the warning threshold before checking
whether we should just end the call. This causes an off-by-one error
where we take one SRTP error more than intended.
This commit reverses the order of the tests.
Travis Cross
Kathleen King
Anthony Minessale
Mike Jerris
Ken Rice
Brian West
areski
Jeff Lenk
Chris Rienzo
jfigus
Steve Underwood