Bug 19352 - asterisk new security issue AST-2016-007 (CVE-2016-7551)
Summary: asterisk new security issue AST-2016-007 (CVE-2016-7551)
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 5
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/703987/
Whiteboard: MGA5-64-OK advisory
Keywords: validated_update
Depends on:
Blocks:
 
Reported: 2016-09-14 00:21 CEST by David Walser
Modified: 2016-10-27 14:40 CEST (History)
4 users (show)

See Also:
Source RPM: asterisk-13.8.1-2.mga6.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2016-09-14 00:21:23 CEST
Upstream has issued an advisory on September 8:
http://downloads.asterisk.org/pub/security/AST-2016-007.html

The issue is fixed in versions 11.23.1 and 13.11.1.
David Walser 2016-09-14 00:21:32 CEST

Whiteboard: (none) => MGA5TOO

Comment 1 Nicolas Lécureuil 2016-09-27 18:05:57 CEST
mga5 updated to 11.23.1

CC: (none) => mageia

Comment 2 David Walser 2016-09-27 19:32:50 CEST
Thanks Nicolas!

Package dropped for now from Cauldron.

Testing procedure:
https://bugs.mageia.org/show_bug.cgi?id=11094#c5

Advisory:
========================

Updated asterisk packages fixes security vulnerability:

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 (AST-2016-007).

References:
http://downloads.asterisk.org/pub/security/AST-2016-007.html
========================

Updated packages in core/updates_testing:
========================
asterisk-11.23.1-1.mga5
libasteriskssl1-11.23.1-1.mga5
asterisk-addons-11.23.1-1.mga5
asterisk-firmware-11.23.1-1.mga5
asterisk-devel-11.23.1-1.mga5
asterisk-plugins-corosync-11.23.1-1.mga5
asterisk-plugins-alsa-11.23.1-1.mga5
asterisk-plugins-calendar-11.23.1-1.mga5
asterisk-plugins-cel-11.23.1-1.mga5
asterisk-plugins-curl-11.23.1-1.mga5
asterisk-plugins-dahdi-11.23.1-1.mga5
asterisk-plugins-fax-11.23.1-1.mga5
asterisk-plugins-festival-11.23.1-1.mga5
asterisk-plugins-ices-11.23.1-1.mga5
asterisk-plugins-jabber-11.23.1-1.mga5
asterisk-plugins-jack-11.23.1-1.mga5
asterisk-plugins-lua-11.23.1-1.mga5
asterisk-plugins-ldap-11.23.1-1.mga5
asterisk-plugins-minivm-11.23.1-1.mga5
asterisk-plugins-mobile-11.23.1-1.mga5
asterisk-plugins-mp3-11.23.1-1.mga5
asterisk-plugins-mysql-11.23.1-1.mga5
asterisk-plugins-ooh323-11.23.1-1.mga5
asterisk-plugins-oss-11.23.1-1.mga5
asterisk-plugins-pktccops-11.23.1-1.mga5
asterisk-plugins-portaudio-11.23.1-1.mga5
asterisk-plugins-pgsql-11.23.1-1.mga5
asterisk-plugins-radius-11.23.1-1.mga5
asterisk-plugins-saycountpl-11.23.1-1.mga5
asterisk-plugins-skinny-11.23.1-1.mga5
asterisk-plugins-snmp-11.23.1-1.mga5
asterisk-plugins-speex-11.23.1-1.mga5
asterisk-plugins-sqlite-11.23.1-1.mga5
asterisk-plugins-tds-11.23.1-1.mga5
asterisk-plugins-osp-11.23.1-1.mga5
asterisk-plugins-unistim-11.23.1-1.mga5
asterisk-plugins-voicemail-11.23.1-1.mga5
asterisk-plugins-voicemail-imap-11.23.1-1.mga5
asterisk-plugins-voicemail-plain-11.23.1-1.mga5
asterisk-gui-11.23.1-1.mga5

from asterisk-11.23.1-1.mga5.src.rpm

Version: Cauldron => 5
Assignee: oe => qa-bugs
Whiteboard: MGA5TOO => (none)

Comment 3 Lewis Smith 2016-10-09 22:31:48 CEST
Testing M5 x64 real hardware.

BEFORE update: installed 'asterisk' which pulled in 10 packages, of which just 4 apply to this update:
 asterisk-11.21.2-1.mga5
 asterisk-firmware-11.21.2-1.mga5
 asterisk-plugins-pktccops-11.21.2-1.mga5
 lib64asteriskssl1-11.21.2-1.mga5
There was a complaint about no user 'asterisk' nor group 'asterisk', so root would be necessary to run it. Suggesting that if these were pre-defined, they could be used instead.

To fire up a controlling terminal, asterisk -cvvv produces a huge output; 
 # asterisk -c[v]
is sufficient. This terminates in a prompt:
 *CLI>
Innocent asterisk commands to try are:
 help, core show help, timing test (or others from the list).

From a *different* root terminal, to connect to the already running asterisk:
 # asterisk -r[v]
The controlling terminal shows (with enough v's):
     -- Remote UNIX connection
The connected terminal prompt is:
 <hostname>*CLI>
All commands are available. Plus, for connected terminals, 'exit'.
 localhost*CLI> exit
 Asterisk cleanly ending (0).
 Executing last minute cleanups
This shows on the controlling terminal (with enough v's):
    -- Remote UNIX connection disconnected

 # systemctl status asterisk
â asterisk.service - Asterisk PBX and telephony daemon.
   Loaded: loaded (/usr/lib/systemd/system/asterisk.service; enabled)
   Active: inactive (dead)
This output always seems to be the same, regardless.

The controlling terminal has *no* exit or quit command, instead ^C:
 *CLI> Asterisk cleanly ending (0).
 Executing last minute cleanups

A shutdown command available from both controlling & connected terminals:
 core stop gracefully

# systemctl stop asterisk.service        [in case, to apply the update]

AFTER update, which was without incident:
 asterisk-11.23.1-1.mga5
 asterisk-firmware-11.23.1-1.mga5
 asterisk-plugins-pktccops-11.23.1-1.mga5
 lib64asteriskssl1-11.23.1-1.mga5

All behaviour the same as before the update, EXCEPT that I noticed:
 core stop gracefully         [whether from controlling or connected terminal]
produced at the *controlling* terminal only:
 Segmentation fault
I cannot find my equivalent test before the update; only the command from a connected terminal (-r) to asterisk already started:
 # asterisk
 Privilege escalation protection disabled!
i.e. without a controlling terminal.
I will re-try the original version for this tomorrow, to see whether it was always thus (= update OK) or is a reversion.

CC: (none) => lewyssmith

Comment 4 Lewis Smith 2016-10-10 20:24:17 CEST
Continued from previous comment...

I took out (updated) asterisk and its lib64, and re-installed them pre-update:
 asterisk-11.21.2-1.mga5
 asterisk-firmware-11.21.2-1.mga5
 asterisk-plugins-pktccops-11.21.2-1.mga5
 lib64asteriskssl1-11.21.2-1.mga5

Fired up a controlling terminal:
 # asterisk -c
...
 *CLI>
and a connected terminal:
 # asterisk -r
...
 localhost*CLI>

I did this twice, first with 'core stop gracefully' from the connected terminal; second issued from the controlling terminal. Neither produced 'segmentation fault' on the controlling terminal as per post-upate. So this aspect of the update looks like a REVERSION, which may be unimportant.
Comment 5 Lewis Smith 2016-10-10 20:50:43 CEST
Postscript on PRE-update asterisk.
I found an obscure fault: if you fire up just a controlling terminal:
 # asterisk -c
and end it with either ^C or 'core stop gracefully', its shell command prompt continues to function normally.
If you then add a connected termial:
 # asterisk -r
and terminate that with 'exit', still normal behaviour of the controlling terminal shell prompt (when you eventually get back to it).
IF, however, you use 'core stop gracefully' from the connected terminal, that messes up the controlling terminal shell prompt:
- Each one (<Enter>) follows on on the same line;
- there is no command echoing - type blindly.

However, output from the command appears. This happens ad infinitum despite re-starting asterisk -c. Only logging out/in restores normality.
This at least seems to have been fixed by the update!
Lewis Smith 2016-10-11 21:28:43 CEST

Whiteboard: (none) => feedback

Comment 6 Len Lawrence 2016-10-17 15:33:23 CEST
Just tried asterisk 11.21.2-1 on a 64bit vbox and cannot reproduce this fault.  It rings some distant bells but I cannot remember what were the circumstances.  Anyway, currently, the fault is not there.  Checked the command line on both terminals while they were both active, controlling terminal at shell prompt, then other terminal at shell prompt, then other terminal back to user, then other terminal closed.  In all four cases the command line functioned normally.
@lewis: Seems like your experience must have involved a special set of contingent circumstances.  Most annoying when that happens.

CC: (none) => tarazed25

Comment 7 Lewis Smith 2016-10-18 09:56:30 CEST
(In reply to Len Lawrence from comment #6)
> Just tried asterisk 11.21.2-1 on a 64bit vbox and cannot reproduce this
> fault
> @lewis: Seems like your experience must have involved a special set of
> contingent circumstances.  Most annoying when that happens.
Thanks Len for this follow-up. Accept both that it is a 'me special', and scarcely important anyway if it was solid.
Hence am validating this update at last; advisory to follow.

Keywords: (none) => validated_update
Whiteboard: feedback => MGA5-64-OK
CC: (none) => sysadmin-bugs

Nicolas Lécureuil 2016-10-18 14:48:49 CEST

Whiteboard: MGA5-64-OK => MGA5-64-OK advisory

Comment 8 Mageia Robot 2016-10-18 20:44:29 CEST
An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2016-0344.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED

David Walser 2016-10-19 22:07:28 CEST

URL: (none) => http://lwn.net/Vulnerabilities/703987/

Comment 9 David Walser 2016-10-27 14:40:20 CEST
This is CVE-2016-7551:
http://lwn.net/Vulnerabilities/704697/

According to:
https://bugzilla.redhat.com/show_bug.cgi?id=1374733

Summary: asterisk new security issue AST-2016-007 => asterisk new security issue AST-2016-007 (CVE-2016-7551)


Note You need to log in before you can comment on or make changes to this bug.