Asterisk Project Security Advisory - 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.
d09b1ff158348303d04ff506414c1e3eAsterisk Project Security Advisory - 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.
f18e104dffba1574edc8eaf43287eb35Asterisk Project Security Advisory - The RTP support in Asterisk maintains its own registry of dynamic codecs and desired payload numbers. While an SDP negotiation may result in a codec using a different payload number these desired ones are still stored internally. When an RTP packet was received this registry would be consulted if the payload number was not found in the negotiated SDP. This registry was incorrectly consulted for all packets, even those which are dynamic. If the payload number resulted in a codec of a different type than the RTP stream (for example the payload number resulted in a video codec but the stream carried audio) a crash could occur if no stream of that type had been negotiated. This was due to the code incorrectly assuming that a stream of the type would always exist.
c2d13e4e6902f9085785bc357baaa195Asterisk Project Security Advisory - If a compound RTCP packet is received containing more than one report (for example a Receiver Report and a Sender Report) the RTCP stack will incorrectly store report information outside of allocated memory potentially causing a crash.
d33abf8cba4f7b05dabb7516ee12b675Asterisk Project Security Advisory - 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 RTP support 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.
9b47fa3102cac35b9edb365cc0f63511Asterisk Project Security Advisory - If an SDP offer or answer is received with the Opus codec and with the format parameters separated using a space the code responsible for parsing will recursively call itself until it crashes. This occurs as the code does not properly handle spaces separating the parameters. This does NOT require the endpoint to have Opus configured in Asterisk. This also does not require the endpoint to be authenticated. If guest is enabled for chan_sip or anonymous in chan_pjsip an SDP offer or answer is still processed and the crash occurs.
041fd53f58fe5e07f7c50e9f4561784eAsterisk Project Security Advisory - On September 8, the Asterisk development team released the AST-2016-007 security advisory. The security advisory involved an RTP resource exhaustion that could be targeted due to a flaw in the "allowoverlap" option of chan_sip. Due to new information presented to the Asterisk team by Walter Doekes, they have made updates to the advisory.
6c4481b9145d0e111804430a2f9ed652Asterisk Project Security Advisory - The overlap dialing feature in chan_sip allows chan_sip to report to a device that the number that has been dialed is incomplete and more digits are required. If this functionality is used with a device that has performed username/password authentication RTP resources are leaked. This occurs because the code fails to release the old RTP resources before allocating new ones in this scenario. If all resources are used then RTP port exhaustion will occur and no RTP sessions are able to be set up.
a71c6e2e1707e12bb56ed82ed1a9cc50Asterisk Project Security Advisory - The Asterisk HTTP server currently has a default configuration which allows the BEAST vulnerability to be exploited if the TLS functionality is enabled. This can allow a man-in-the-middle attack to decrypt data passing through it.
6a4fbedbc5d908f3f403f2cb676b9c18Asterisk Project Security Advisory - When handling a WebSocket frame the res_http_websocket module dynamically changes the size of the memory used to allow the provided payload to fit. If a payload length of zero was received the code would incorrectly attempt to resize to zero. This operation would succeed and end up freeing the memory but be treated as a failure. When the session was subsequently torn down this memory would get freed yet again causing a crash. Users of the WebSocket functionality also did not take into account that provided text frames are not guaranteed to be NULL terminated. This has been fixed in chan_sip and chan_pjsip in the applicable versions.
199d71b570df3f72b699ecfa9a017deaAsterisk Project Security Advisory - When handling an INVITE with Replaces message the res_pjsip_refer module incorrectly assumes that it will be operating on a channel that has just been created. If the INVITE with Replaces message is sent in-dialog after a session has been established this assumption will be incorrect. The res_pjsip_refer module will then hang up a channel that is actually owned by another thread. When this other thread attempts to use the just hung up channel it will end up using freed channel which will likely cause a crash.
ad443124e8b31e3f67b0ef3190563e16Asterisk Project Security Advisory - The chan_pjsip channel driver uses a queue approach for actions relating to SIP sessions. There exists a race condition where actions may be queued to answer a session or send ringing AFTER a SIP session has been terminated using a CANCEL request. The code will incorrectly assume that the SIP session is still active and attempt to send the SIP response. The PJSIP library does not expect the SIP session to be in the disconnected state when sending the response and asserts.
1f457cd6c67d3293e290a8b8a59622abAsterisk Project Security Advisory - The ConfBridge application uses an internal bridging API to implement conference bridges. This internal API uses a state model for channels within the conference bridge and transitions between states as different things occur. Under load it is possible for some state transitions to be delayed causing the channel to transition from being hung up to waiting for media. As the channel has been hung up remotely no further media will arrive and the channel will stay within ConfBridge indefinitely.
2945c50e19d44b99fd92e50ebc97bd9fAsterisk Project Security Advisory - A remotely exploitable crash vulnerability exists in the PJSIP channel driver if the "qualify_frequency" configuration option is enabled on an AOR and the remote SIP server challenges for authentication of the resulting OPTIONS request. The response handling code wrongly assumes that a PJSIP endpoint will always be associated with an outgoing request which is incorrect.
dd6a6ccd5211873a753b83153d64e8d6Asterisk Project Security Advisory - A remotely exploitable crash vulnerability exists in the SIP channel driver if an ACK with SDP is received after the channel has been terminated. The handling code incorrectly assumes that the channel will always be present.
7a62518551aefdf4d135c81e2573574cAsterisk Project Security Advisory - Asterisk includes a demonstration AJAX based manager interface, ajamdemo.html which uses the prototype.js framework. An issue was uncovered in this framework which could allow someone to execute a cross-site AJAX request exploit.
243db55520978150b9f0e5bf94929f45Asterisk Project Security Advisory - It is possible to determine if a peer with a specific name is configured in Asterisk by sending a specially crafted REGISTER message twice. The username that is to be checked is put in the user portion of the URI in the To header. A bogus non-matching value is put into the username portion of the Digest in the Authorization header. If the peer does exist the second REGISTER will receive a response of "403 Authentication user name does not match account name". If the peer does not exist the response will be "404 Not Found" if alwaysauthreject is disabled and "401 Unauthorized" if alwaysauthreject is enabled.
0d01e8fee5aeda9518aace2d5be56041Asterisk Project Security Advisory - A format string vulnerability exists in the Logger and Manager of Asterisk.
6d2796e16b0e7293fc27b52ab1085f17Asterisk Project Security Advisory - Two buffer overflows exist in the RTP payload handling code of Asterisk. Both overflows can be caused by an INVITE or any other SIP packet with SDP. The request may need to be authenticated depending on configuration of the Asterisk installation.
9af18bb93f79be77066637b6ba8f4e94Asterisk Project Security Advisory - The handling of the BYE with Also transfer method was broken during the development of Asterisk 1.4. If a transfer attempt is made using this method the system will immediately crash upon handling the BYE message due to trying to copy data into a NULL pointer.
f650cdc7e34b6e2ec797a8d92bb23acdAsterisk Project Security Advisory - The Asterisk STUN implementation in the RTP stack has a remotely exploitable crash vulnerability. A pointer may run past accessible memory if Asterisk receives a specially crafted STUN packet on an active RTP port. The code that parses the incoming STUN packets incorrectly checks that the length indicated in the STUN attribute and the size of the STUN attribute header does not exceed the available data. This will cause the data pointer to run past accessible memory and when accessed will cause a crash.
7406ca12249f52e17bf976b8271095c2
© 2020 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed