Backport upstream alignment fix to correct bus error on platforms
that require strict memory alignment such as SPARC
Author: Jaap Keuter <firstname.lastname@example.org>
Date: Fri Nov 7 00:13:10 2014 +0100
While setting the IV for AES ICM the nonce is simply typecast from
a void * to a v128_t *. This breaches alignment requirements for
v128_t objects on platforms that require it.
Instead make a copy of the nonce to assure proper alignment.
The new C compiler breaks a lot of things. snprintf and timespec now exist, and redefining causes an error.
Many more things are warnings, so warnings-as-errors will fail - remove it from some projects for now.
V8: don't pass VS version to build batch file.
mod_sofia: Config has too-long if/elseif chain. Break this up to avoid "parser stack overflow; program too complex".
Add mod_conference.h to project and dir to includes.
Latest automake will detect then warn if the Makefile uses source
files that are in subdirectories, but the subdirs option is not
set. In the FreeSWITCH build system the current expected behavior is
to expect the subdirs option to be enabled.
These two files should only be built when OpenSSL is not enabled. See
the configure script of the original sources and Makefile from upstream.
Fixes a -Wimplicit-function-declaration warning.
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
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
`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
We'll then call `cipher_encrypt()` or `cipher_decrypt()` with these
two values, causing us to read from and write to arbitrary addresses
(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.
sha1_init, sha1_update, and sha1_final were ending up as undefined
symbols in libfreeswitch.so because of the inline declaration, which
caused us to blow up while linking the freeswitch executable. Declare
these as static inline instead.