Asterisk suffers from a possible remote SQL injection vulnerability. Some databases can use backslashes to escape certain characters, such as backticks. If input is provided to func_odbc which includes backslashes it is possible for func_odbc to construct a broken SQL query and the SQL query to fail. Asterisk Open Source versions 16.x up to but not including 16.25.2, 18.x up to but not including 18.11.2, and 19.x up to but not including 19.3.2 are affected. Certified Asterisk versions 16.x up to but not including 16.8-cert14 are affected.
edf4f6fe7b4776e5bf9d41e581c5c4269feb931cb02ec2fa3c1c40c0cbad95e5When Asterisk receives a re-INVITE without SDP after having sent a BYE request a crash will occur. This occurs due to the Asterisk channel no longer being present while code assumes it is.
ed776e0af45a5b2a169abf425e456827171d23d6768bff6373779d772dd49e62Given a scenario where an outgoing call is placed from Asterisk to a remote SIP server it is possible for a crash to occur. The code responsible for negotiating SDP in SIP responses incorrectly assumes that SDP negotiation will always be successful. If a SIP response containing an SDP that can not be negotiated is received a subsequent SDP negotiation on the same call can cause a crash.
a598689c226c0f0b2be7c0f2f5f641be7af78caf65f348109e0446002e06d18fAsterisk 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.
246c916e8473ad9977ca8cf7ccf517b1947e0129d38290e5c1324a1d4ffccacdAsterisk 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.
2ca83ced6bedaa74703ffe260735d9b6a5f8e6d560c01ef31601708735e0b831Asterisk 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.
7deda55a35acebe5f67e42485b2042572f1941ee107a31867433c7a487a737c0Asterisk 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.
ad570e142eb4ed64ce1d02cb9f2d12edb9da7bbfbc9262b5c740e7b5ad1dc490Asterisk 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.
dc5c0fb3ca5feec836d616e3705c5e6f1fe136bb73fc595a8c84c639da8487a1Asterisk 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.
2a073eeba4b82f770c34c9371cc94f0c63cbd409c8022691691eeb71c498ae9dAsterisk 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.
570e74e1a02b9da9c957b15a54db607f1a0d2d9692d3bdfc29f57249f8d22599Asterisk 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.
97fcad4b2cc395997d99694e3df652f77ddb75c1bf9f3258efb47206a678a1c1Asterisk 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.
6c3e6ff53bbb942a49afc289970e7d998f9f519da49bdeaeadd6a6a039422b8eAsterisk 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.
1868539f0faf6bdd956adbc2ca0137de48c00afcc3285083d11a021aa2b17658Asterisk 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.
15a4222dbf1ccd2736fba02c722a20bb0de7e9d45367175f41e820c972765349Asterisk 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.
55c0f051137922494f6ce7feebfbe8e1ea4b9b2169a67c126fdff6d43bda124aAsterisk 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.
84eb5f3fb7ddc9a0f5ee17c933a15f1ce01cc2ecc88d2c7325407f4bef03640bAsterisk 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.
3fc37984a9d5b7488a013c0d4d7869919c15b588b2dfa950081c2998a81fc658Asterisk 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.
7b5b33cd2756da3ffe8c64031b7e60cd9b0cbd4644f5ab8e89498500f2a141bcAsterisk 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.
e86a0ecb6a897bcb9f1220e85d46af735a82bc2ef2a6208e6cc14a3c6f4996ddAsterisk 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.
3634bc8c6b1fcdae106d21b04636f67125dbeb10fda75b29b1244e3e1cd34bf0Asterisk Project Security Advisory - A format string vulnerability exists in the Logger and Manager of Asterisk.
d3c4daeab6197a01a301019b8aa89ad828883465386ae04592c4c0d6a701e033Asterisk 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.
7af0f5f8834e1ec6cfc12a2131ca26a0a7c955b7d3cc5c93dab300406251ab4bAsterisk 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.
20c92e563a5e81918a24b9db84f689f656287c30c74250a54b4c5f8c1b9ed24dAsterisk 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.
bc0c39530df4dd18a6dbdcdc793f1561ba085d70afb011dfde1d4bdcb5f322af
© 2024 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