FreshPorts - VuXML

The Asterisk project reports:

A specially crafted SIP in-dialog MESSAGE message can cause Asterisk to crash.

< 13.27.1

< 15.7.3

< 16.4.1

The Asterisk project reports:

AST-2020-003: A crash can occur in Asterisk when a SIP message is received that has a History-Info header, which contains a tel-uri.

AST-2020-004: A crash can occur in Asterisk when a SIP 181 response is received that has a Diversion header, which contains a tel-uri.

< 13.38.1

< 16.15.1

< 18.1.1

The Asterisk project reports:

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.

< 13.37.1

< 16.14.1

< 18.0.1

The Asterisk project reports:

A SIP request can be sent to Asterisk that can change a SIP peers 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 peers 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.

< 13.29.2

< 16.6.2

The Asterisk project reports:

Upon receiving a new SIP Invite, Asterisk did not return the created dialog locked or referenced. This caused a gap between the creation of the dialog object, and its next use by the thread that created it. Depending upon some off nominal circumstances, and timing it was possible for another thread to free said dialog in this gap. Asterisk could then crash when the dialog object, or any of its dependent objects were de-referenced, or accessed next by the initial creation thread.

< 13.37.1

< 16.14.1

< 18.0.1

The Asterisk project reports:

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.

< 13.27.1

< 15.7.3

< 16.4.1

The Asterisk project reports:

A remote authenticated Asterisk Manager Interface (AMI) user without system authorization could use a specially crafted Originate AMI request to execute arbitrary system commands.

< 13.29.2

< 16.6.2

The Asterisk project reports:

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.

This issue presented itself when an RTP packet containing no audio (and thus no samples) was received. In a particular transcoding scenario this audio frame would get turned into a frame with no origin information. If this new frame was then given to the audio transcoding support a crash would occur as no samples and no origin information would be present. The transcoding scenario requires the genericplc option to be set to enabled (the default) and a transcoding path from the source format into signed linear and then from signed linear into another format.

Note that there may be other scenarios that have not been found which can cause an audio frame with no origin to be given to the audio transcoding support and thus cause a crash.

< 13.28.1

< 16.5.1

The Asterisk project reports:

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.

< 15.7.4

< 16.5.1