This patch resolves two sources of memory leaks when using TLS in Asterisk:
1) It removes improper initialization (and multiple re-initializations) of
portions of the SSL library. Asterisk calls SSL_library_init and
SSL_load_error_strings during SSL initialization; collectively this
obviates the need for calling any of the following during initialization
or client connection handling:
* ERR_load_crypto_strings (handled by SSL_load_error_strings)
* OpenSSL_add_all_algorithms (synonym for SSL_library_init)
* SSLeay_add_ssl_algorithms (synonym for SSL_library_init)
2) Failure to completely clean up all memory allocated by Asterisk and by
the SSL library for TLS clients. This included not freeing the SSL_CTX
object in the SIP channel driver, as well as not clearing the error
stack when the TLS client exited.
Note that these memory leaks were found by Thomas Arimont, and this patch
was essentially written by him with some minor tweaks.
(closes issue AST-889)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
patches:
(bugAST-889.patch) by Thomas Arimont (license 5525)
Review: https://reviewboard.asterisk.org/r/2105
........
Merged revisions 373061 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373062 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373079 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The new API allows for sorted containers, insertion options, duplicate
handling options, and traversal order options.
* Adds the ability for containers to be sorted when they are created.
* Adds container creation options to handle duplicates when they are
inserted.
* Adds container creation option to insert objects at the beginning or end
of the container traversal order.
* Adds OBJ_PARTIAL_KEY to allow searching with a partial key. The partial
key works similarly to the OBJ_KEY flag. (The real search speed
improvement with this flag will come when red-black trees are added.)
* Adds container traversal and iteration order options: Ascending and
Descending.
* Adds an AST_DEVMODE compile feature to check the stats and integrity of
registered containers using the CLI "astobj2 container stats <name>" and
"astobj2 container check <name>". The channels container is normally
registered since it is one of the most important containers in the system.
* Adds ao2_iterator_restart() to allow iteration to be restarted from the
beginning.
* Changes the generic container object to have a v_method table pointer to
support other types of containers.
* Changes the container nodes holding objects to be ref counted.
The ref counted nodes and v_method table pointer changes pave the way to
allow other types of containers.
* Includes a large astobj2 unit test enhancement that tests the new
features.
(closes issue ASTERISK-19969)
Reported by: rmudgett
Review: https://reviewboard.asterisk.org/r/2078/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372997 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With this option in use, it may be necessary to regulate your log files
externally.
(closes issue ASTERISK-20189)
Reported by: Jaco Kroon
Patches:
asterisk-logger-norotate-trunk.patch uploaded by Jaco Kroon (license 5671)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
message.c makes use of a special message queue channel that exists
in thread storage. This channel never goes away due to the fact that
the taskprocessor used by message.c does not get shut down, meaning
that it never ends the thread that stores the channel.
This patch fixes the problem by shutting down the taskprocessor when
Asterisk is shut down. In addition, the thread storage has a destructor
that will release the channel reference when the taskprocessor is destroyed.
(closes issue AST-937)
Reported by Jason Parker
Patches:
AST-937.patch uploaded by Mark Michelson (License #5049)
Tested by Jason Parker
........
Merged revisions 372885 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 372888 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372891 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The previous fix still would look in the static_RTP_PT table, which
is inappropriate since we specifically want to find a codec that has
been negotiated.
(closes issue ASTERISK-20296)
reported by NITESH BANSAL
Patches:
codec_negotiation.patch Uploaded by NITESH BANSAL (License #6418)
........
Merged revisions 372311 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The AMI Originate action can allow a remote user to specify information that can
be used to execute shell commands on the system hosting Asterisk. This can
result in an unwanted escalation of permissions, as the Originate action, which
requires the "originate" class authorization, can be used to perform actions
that would typically require the "system" class authorization. Previous attempts
to prevent this permission escalation (AST-2011-006, AST-2012-004) have sought
to do so by inspecting the names of applications and functions passed in with
the Originate action and, if those applications/functions matched a predefined
set of values, rejecting the command if the user lacked the "system" class
authorization. As noted by IBM X-Force Research, the "ExternalIVR"
application is not listed in the predefined set of values. The solution for
this particular vulnerability is to include the "ExternalIVR" application in the
set of defined applications/functions that require "system" class authorization.
Unfortunately, the approach of inspecting fields in the Originate action against
known applications/functions has a significant flaw. The predefined set of
values can be bypassed by creative use of the Originate action or by certain
dialplan configurations, which is beyond the ability of Asterisk to analyze at
run-time. Attempting to work around these scenarios would result in severely
restricting the applications or functions and prevent their usage for legitimate
means. As such, any additional security vulnerabilities, where an
application/function that would normally require the "system" class
authorization can be executed by users with the "originate" class authorization,
will not be addressed. Instead, the README-SERIOUSLY.bestpractices.txt file has
been updated to reflect that the AMI Originate action can result in commands
requiring the "system" class authorization to be executed. Proper system
configuration can limit the impact of such scenarios.
(closes issue ASTERISK-20132)
Reported by: Zubair Ashraf of IBM X-Force Research
........
Merged revisions 371998 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 371999 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 372000 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372001 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes numerous doxygen warnings across Asterisk. It also updates
the makefile to regenerate the doxygen configuration on the local system
before running doxygen to help prevent warnings/errors on the local system.
Much thanks to Andrew for tackling one of the Asterisk janitor projects!
(issue ASTERISK-20259)
Reported by: Andrew Latham
Patches:
doxygen_partial.diff uploaded by Andrew Latham (license 5985)
make_progdocs.diff uploaded by Andrew Latham (license 5985)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371989 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The original implementations simply wrap pthread functions, which take
absolute time as an argument. The spinlock version for systems without
those functions treated the argument as a delta. This patch fixes the
spinlock version to be consistent with the pthread version.
(closes issue ASTERISK-20240)
Reported by: Egor Gorlin
Patches:
lock.c.patch uploaded by Egor Gorlin (license 6416)
........
Merged revisions 371718 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 371720 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371721 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With the SCOPED_LOCK macro, you can create a variable
that locks a specific lock and unlocks the lock when the
variable goes out of scope. This is useful for situations
where many breaks, continues, returns, or other interruptions
would require separate unlock statements. With a scoped lock,
these aren't necessary.
There are specializations for mutexes, read locks, write locks,
ao2 locks, ao2 read locks, ao2 write locks, and channel locks.
Each of these is a SCOPED_LOCK at heart though.
Review: https://reviewboard.asterisk.org/r/2060
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When compiling with BETTER_BACKTRACES enabled, Asterisk will sometimes
crash when "core show locks" is run. This happens regularly in the
testsuite since several tests run "core show locks" to help with
debugging. This seems to be a fault with libraries on certain operating
systems (notably CentOS 6.2/6.3) running on virtual machines and
utilizing gcc 4.4.6.
(issue ASTERISK-20090)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371535 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When formatting documentation fields, the XML documentation parser calls
xmldoc_get_formatted. This function allocates a string buffer at the
beginning of its routine. Unfortunately, on certain code paths, it also
calls xmldoc_string_cleanup, which assumes that it will create the string
buffer. The previously allocated string buffer is then leaked by the
xmldoc_string_cleanup routine.
Now: we don't do that.
(closes issue AST-932)
Reported by: Alexander Homig
........
Merged revisions 371469 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 371491 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 371492 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371493 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the feature "Private representation of caller, connected
and redirecting party ids", as previously discussed with us (DATUS) and
Digium.
1. Feature motivation
Until now it is quite difficult to modify a party number or name which can
only be seen by exactly one particular instantiated technology channel
subscriber. One example where a modified party number or name on one
channel is spread over several channels are supplementary services like
call transfer or pickup. To implement these features Asterisk internally
copies caller and connected ids from one channel to another. Another
example are extension subscriptions. The monitoring entities (watchers)
are notified of state changes and - if desired - of party numbers or names
which represent the involving call parties. One major feature where a
private representation of party names is essentially needed, i.e. where a
party name shall be exclusively signaled to only one particular user, is a
private user-specific name resolution for party numbers. A lookup in a
private destination-dependent telephone book shall provide party names
which cannot be seen by any other user at any time.
2. Feature Description
This feature comes along with the implementation of additional private
party id elements for caller id, connected id and redirecting ids inside
Asterisk channels.
The private party id elements can be read or set by the user using
Asterisk dialplan functions.
When a technology channel is initiating a call, receives an internal
connected-line update event, or receives an internal redirecting update
event, it merges the corresponding public id with the private id to create
an effective party id. The effective party id is then used for protocol
signaling.
The channel technologies which initially support the private id
representation with this patch are SIP (chan_sip), mISDN (chan_misdn) and
PRI (chan_dahdi).
Once a private name or number on a channel is set and (implicitly) made
valid, it is generally used for any further protocol signaling until it is
rewritten or invalidated.
To simplify the invalidation of private ids all internally generated
connected/redirecting update events and also all connected/redirecting
update events which are generated by technology channels -- receiving
regarding protocol information - automatically trigger the invalidation of
private ids.
If not using the private party id representation feature at all, i.e. if
using only the 'regular' caller-id, connected and redirecting related
functions, the current characteristic of Asterisk is not affected by the
new extended functionality.
3. User interface Description
To grant access to the private name and number representation from the
Asterisk dialplan, the CALLERID, CONNECTEDLINE and REDIRECTING dialplan
functions are extended by the following data types. The formats of these
data types are equal to the corresponding regular 'non-private' already
existing data types:
CALLERID:
priv-all
priv-name priv-name-valid priv-name-charset priv-name-pres
priv-num priv-num-valid priv-num-plan priv-num-pres
priv-subaddr priv-subaddr-valid priv-subaddr-type priv-subaddr-odd
priv-tag
CONNECTEDLINE:
priv-name priv-name-valid priv-name-pres priv-name-charset
priv-num priv-num-valid priv-num-pres priv-num-plan
priv-subaddr priv-subaddr-valid priv-subaddr-type priv-subaddr-odd
priv-tag
REDIRECTING:
priv-orig-name priv-orig-name-valid priv-orig-name-pres priv-orig-name-charset
priv-orig-num priv-orig-num-valid priv-orig-num-pres priv-orig-num-plan
priv-orig-subaddr priv-orig-subaddr-valid priv-orig-subaddr-type priv-orig-subaddr-odd
priv-orig-tag
priv-from-name priv-from-name-valid priv-from-name-pres priv-from-name-charset
priv-from-num priv-from-num-valid priv-from-num-pres priv-from-num-plan
priv-from-subaddr priv-from-subaddr-valid priv-from-subaddr-type priv-from-subaddr-odd
priv-from-tag
priv-to-name priv-to-name-valid priv-to-name-pres priv-to-name-charset
priv-to-num priv-to-num-valid priv-to-num-pres priv-to-num-plan
priv-to-subaddr priv-to-subaddr-valid priv-to-subaddr-type priv-to-subaddr-odd
priv-to-tag
Reported by: Thomas Arimont
Review: https://reviewboard.asterisk.org/r/2030/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
You cannot unref a pointer and then expect to ref it again later.
* Fix potential NULL pointer deref if the call pickup search fails.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371052 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Quote from review board:
This patch extends the extension state callbacks so that monitoring channels
(as chan_sip) get more information of the devices which are responsible for
an extension state change. The additional information is needed by chan_sip
to present names/numbers of the caller and callee in an early-state SIP
notification. Users of extenstion state callback not interested in the
additional information are not affected by the changes.
Motivation: to present the involved party's name/number in an early-state
nofification (used by the notified device as a pickup offer) one after another
so that a user can see which call he will pick up in an undirected pickup.
Such a pickup offer to a user shall indicate the same call (number/name-A calls
number/name-B) as the call which would be picked up when an undirected pickup
is executed.
Users interested in additional state info must use the new functions
ast_extension_state_add_extended() resp.
ast_extension_state_add_destroy_extended() to register an extended state
callback. When the callback is registered this way, an extra member
device_state_info of struct ast_state_cb_info is passed to the callback in
addition to the aggregated extension state. This container holds an object for
every device of the monitored extension hint consisting of the device name, the
device state and a channel reference to the channel which (presumably) caused
the device state.
The information is used by chan_sip for early-state notifications. When the
state of a device changes and the new state contains AST_EVENT_RINGING, an
early-state notification is sent to the subscribed devices with the
caller/callee names/numbers of the oldest ringing channel of the monitored
extension. The notified user may then invoke a direct pickup, which will pickup
exactly this channel.
Users of the old non-extended callbacks will only be called when the aggregated
state did change (same behavior as before). Users of the extended callback will
also be called when the state is unchanged but does contain AST_EVENT_RINGING.
That could be the case if two channels are ringing at one device and one of
them hangs up, so the aggregated state does not change. This way the monitoring
channel can create a new early-state notification with the now ringing
party-ids.
Review: https://reviewboard.asterisk.org/r/2048
This contribution comes from Guenther Kelleter
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370979 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is based on the work done by Olle Johansson on review board.
The idea is that the channel specified in an AMI originate or call
file is typically not connected to the outgoing extension until the
channel has been answered. With this change, an EarlyMedia header can
be specified for AMI originates and an early_media option can
be specified in call files. With this option set, once early media is
received on a channel, it will be connected with the outgoing extension.
(closes issue ASTERISK-18644)
Reported by Olle Johansson
Review: https://reviewboard.asterisk.org/r/1472
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Implementation of a dialplan function for checking manager accounts. Right now
it only returns the number of logged in sessions for a manager account, but
other attributes can be added later.
Patch by: Olle Johansson
Review: https://reviewboard.asterisk.org/r/421/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370943 65c4cc65-6c06-0410-ace0-fbb531ad65f3
