Fixes the following security issues:
- AST-2020-001: Remote crash in res_pjsip_session
Upon receiving a new SIP Invite, Asterisk did not return the created
dialog locked or referenced.
- AST-2020-002: Outbound INVITE loop on challenge with different nonce
If Asterisk is challenged on an outbound INVITE and the nonce is changed
in each response, Asterisk will continually send INVITEs in a loop. This
causes Asterisk to consume more and more memory since the transaction will
never terminate (even if the call is hung up), ultimately leading to a
restart or shutdown of Asterisk. Outbound authentication must be
configured on the endpoint for this to occur.
For details, see the announcement:
https://www.asterisk.org/asterisk-news/asterisk-13-37-1-16-14-1-17-8-1-18-0-1-and-16-8-cert5-now-available-security/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
BlueZ 4.x is deprecated since a long time (BlueZ 5.x has been released
in 2012) so drop it.
For cwiid, sconeserver and ussp-push, replace bluez_utils by
bluez5_utils. All other packages already support bluez5_utils so just
drop bluez_utils.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security vulnerabilities:
AST-2019-006: SIP request can change address of a SIP peer.
A SIP request can be sent to Asterisk that can change a SIP peer’s IP
address. A REGISTER does not need to occur, and calls can be hijacked as a
result. The only thing that needs to be known is the peer’s name;
authentication details such as passwords do not need to be known. This
vulnerability is only exploitable when the “nat” option is set to the
default, or “auto_force_rport”.
https://downloads.asterisk.org/pub/security/AST-2019-006.pdf
AST-2019-007: AMI user could execute system commands.
A remote authenticated Asterisk Manager Interface (AMI) user without
“system” authorization could use a specially crafted “Originate” AMI request
to execute arbitrary system commands.
https://downloads.asterisk.org/pub/security/AST-2019-007.pdf
AST-2019-008: Re-invite with T.38 and malformed SDP causes crash.
If Asterisk receives a re-invite initiating T.38 faxing and has a port of 0
and no c line in the SDP, a crash will occur.
https://downloads.asterisk.org/pub/security/AST-2019-008.pdf
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fixes the following security issues:
AST-2019-004: Crash when negotiating for T.38 with a declined stream
When Asterisk sends a re-invite initiating T.38 faxing, and the endpoint
responds with a declined media stream a crash will then occur in Asterisk.
https://downloads.asterisk.org/pub/security/AST-2019-004.pdf
AST-2019-005: Remote Crash Vulnerability in audio transcoding
When audio frames are given to the audio transcoding support in Asterisk the
number of samples are examined and as part of this a message is output to
indicate that no samples are present. A change was done to suppress this
message for a particular scenario in which the message was not relevant. This
change assumed that information about the origin of a frame will always exist
when in reality it may not.
https://downloads.asterisk.org/pub/security/AST-2019-005.pdf
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes the following security issues:
CVE-2019-12827: A specially crafted SIP in-dialog MESSAGE message can cause
Asterisk to crash:
https://downloads.asterisk.org/pub/security/AST-2019-002.html
CVE-2019-13161: When T.38 faxing is done in Asterisk a T.38 reinvite may be
sent to an endpoint to switch it to T.38. If the endpoint responds with an
improperly formatted SDP answer including both a T.38 UDPTL stream and an
audio or video stream containing only codecs not allowed on the SIP peer or
user a crash will occur. The code incorrectly assumes that there will be at
least one common codec when T.38 is also in the SDP answer:
https://downloads.asterisk.org/pub/security/AST-2019-003.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issue:
AST-2019-001: Remote crash vulnerability with SDP protocol violation
When Asterisk makes an outgoing call, a very specific SDP protocol violation
by the remote party can cause Asterisk to crash (CVE-2019-7251)
https://downloads.asterisk.org/pub/security/AST-2019-001.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch extends the configure checks for re-entrant resolver
functions to fix uclibc builds.
Quoting Yann:
http://lists.busybox.net/pipermail/buildroot/2017-September/203004.html
"As a final stroke of genius, asterisk checks for the re-entrant variant
of res_ninit(), and concludes that all such functions are available,
including res_nsearch(). Uclibc-ng has the former but not the latter, so
the build fails. Since there is no cache variable for that check, we
can't pre-feed that result to configure, and fixing it is a bigger
endeavour. So we make asterisk depend on glibc for now, until someone
is brave enough to fix it."
Musl builds are still broken:
output/build/asterisk-16.0.0/include/asterisk/astmm.h:165:35:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘->’ token
Do_not_use_calloc__use_ast_calloc->fail(a, b)
output/build/asterisk-16.0.0/include/asterisk/astmm.h:169:77:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘->’ token
Do_not_use_free__use_ast_free_or_ast_std_free_for_remotely_allocated_memory->fail(a)
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
- removed patches applied upstream, re-numbered remaining patches
- not available for static builds anymore:
8e36064109
- fixed license hashes after upstream whitespace removal
fd0ca1c3f9
- removed configure options not provided by upstream anymore
- fixed configure error, the file is included in asterisk source:
checking for bridges/bridge_softmix/include/hrirs.h... configure:
error: cannot check for file existence when cross compiling
- added "-without-pjproject-bundled" as noted in
https://wiki.asterisk.org/wiki/display/AST/New+in+15
- upstream switched from ncurses to libedit:
d6fda173a4
- added libatomic when needed
- updated core sound package
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes configure error
checking for the ability of -lsrtp2 to be linked in a shared object... yes
checking for srtp_crypto_policy_set_aes_cm_256_hmac_sha1_80 in -lsrtp2... yes
checking for srtp_crypto_policy_set_aes_cm_192_hmac_sha1_80 in -lsrtp2... no
checking for srtp_crypto_policy_set_aes_gcm_128_8_auth in -lsrtp2... no
checking for srtp_shutdown in -lsrtp2... yes
checking for srtp2/srtp.h... (cached) yes
configure: WARNING: ***
configure: WARNING: *** OpenSSL required when using libsrtp2, checking for libsrtp instead.
configure: WARNING: ***
using this defconfig:
BR2_PACKAGE_LIBSRTP=y
BR2_PACKAGE_ASTERISK=y
Please note that openssl support in libsrtp is not available for static
builds:
https://git.buildroot.net/buildroot/tree/package/libsrtp/libsrtp.mk#n27
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Ferdinand van Aartsen <ferdinand@ombud.nl>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since we reworked the download infra, the location for packages to look
for their files has moved to a per-package directory.
For systems where a download of the asterisk sound files was already
done in a version prior to the rework, all was working fine so far,
because the files were indeed in the main DL directory.
But for systems where the download is first attempted after the rework,
the files are not found (even though they are properly downloaded).
Fix the location where asterisk looks for its extra files.
Reported-by: ***** ***** <zyama.abel@mail.ru>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: ***** ***** <zyama.abel@mail.ru>
Cc: Carlos Santos <casantos@datacom.ind.br>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 0f9c0bf3d5 did a global replace of $(HOST_DIR)/usr/bin to
$(HOST_DIR)/bin. But later, a new occurrence of $(HOST_DIR)/usr/bin snuck
into the sources via commit 05e306d8d3 which added asterisk.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
AST-2018-002: Crash when given an invalid SDP media format description
By crafting an SDP message with an invalid media format description Asterisk
crashes when using the pjsip channel driver because pjproject's sdp parsing
algorithm fails to catch the invalid media format description.
AST-2018-003: Crash with an invalid SDP fmtp attribute
By crafting an SDP message body with an invalid fmtp attribute Asterisk
crashes when using the pjsip channel driver because pjproject's fmtp
retrieval function fails to check if fmtp value is empty (set empty if
previously parsed as invalid).
AST-2018-004: Crash when receiving SUBSCRIBE request
When processing a SUBSCRIBE request the res_pjsip_pubsub module stores the
accepted formats present in the Accept headers of the request. This code
did not limit the number of headers it processed despite having a fixed
limit of 32. If more than 32 Accept headers were present the code would
write outside of its memory and cause a crash.
AST-2018-005: Crash when large numbers of TCP connections are closed suddenly
A crash occurs when a number of authenticated INVITE messages are sent over
TCP or TLS and then the connection is suddenly closed. This issue leads to
a segmentation fault.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes the following security issues:
* AST-2017-014: Crash in PJSIP resource when missing a contact header A
select set of SIP messages create a dialog in Asterisk. Those SIP
messages must contain a contact header. For those messages, if the header
was not present and using the PJSIP channel driver, it would cause
Asterisk to crash. The severity of this vulnerability is somewhat
mitigated if authentication is enabled. If authentication is enabled a
user would have to first be authorized before reaching the crash point.
For more details, see the announcement:
https://www.asterisk.org/downloads/asterisk-news/asterisk-13185-1475-1515-and-1318-cert2-now-available-security
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes the following security issues:
14.6.1:
* AST-2017-005 (applied to all released versions): The "strictrtp" option in
rtp.conf enables a feature of the RTP stack that learns the source address
of media for a session and drops any packets that do not originate from
the expected address. This option is enabled by default in Asterisk 11
and above. The "nat" and "rtp_symmetric" options for chan_sip and
chan_pjsip respectively enable symmetric RTP support in the RTP stack.
This uses the source address of incoming media as the target address of
any sent media. This option is not enabled by default but is commonly
enabled to handle devices behind NAT.
A change was made to the strict RTP support in the RTP stack to better
tolerate late media when a reinvite occurs. When combined with the
symmetric RTP support this introduced an avenue where media could be
hijacked. Instead of only learning a new address when expected the new
code allowed a new source address to be learned at all times.
If a flood of RTP traffic was received the strict RTPsupport would allow
the new address to provide media and with symmetric RTP enabled outgoing
traffic would be sent to this new address, allowing the media to be
hijacked. Provided the attacker continued to send traffic they would
continue to receive traffic as well.
* AST-2017-006 (applied to all released versions): The app_minivm module has
an “externnotify” program configuration option that is executed by the
MinivmNotify dialplan application. The application uses the caller-id
name and number as part of a built string passed to the OS shell for
interpretation and execution. Since the caller-id name and number can
come from an untrusted source, a crafted caller-id name or number allows
an arbitrary shell command injection.
* AST-2017-007 (applied only to 13.17.1 and 14.6.1): A carefully crafted URI
in a From, To or Contact header could cause Asterisk to crash
For more details, see the announcement:
https://www.asterisk.org/downloads/asterisk-news/asterisk-11252-13171-1461-116-cert17-1313-cert5-now-available-security
14.6.2:
* AST-2017-008: Insufficient RTCP packet validation could allow reading
stale buffer contents and when combined with the “nat” and “symmetric_rtp”
options allow redirecting where Asterisk sends the next RTCP report.
The RTP stream qualification to learn the source address of media always
accepted the first RTP packet as the new source and allowed what
AST-2017-005 was mitigating. The intent was to qualify a series of
packets before accepting the new source address.
For more details, see the announcement:
https://www.asterisk.org/downloads/asterisk-news/asterisk-11253-13172-1462-116-cert18-1313-cert6-now-available-security
Drop 0004-configure-in-cross-complation-assimne-eventfd-are-av.patch as this
is now handled differently upstream (by disabling eventfd for cross
compilation, see commit 2e927990b3d2 (eventfd: Disable during cross
compilation)). If eventfd support is needed then this should be submitted
upstream.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The host menuselect tool is linked to our host libxml2 library, but it
is missing an RPATH to the host directory.
This is because menuselect does not use automake, so does not inherit
the LDFLAGS from the configure run.
We fix that by simply passing $(HOST_CONFIGURE_OPTS) in the make
environment.
At the same time, we also install the tool in the host directory, even
if not used from there, so that the sanity checks we run are properly
passed.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
DAHDI is the 'framework' to drive actual telehony cards. Using telephony
cards without signalling is pretty much meaningless, so signalling will
be added in later commits.
libtonezone is provided by dhadi-tools, while the dahdi headers are
provided by dahdi-linux. Go figure.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>