There are two aspects to the vulnerability:
(1) res_jabber/res_xmpp use SSLv3 only. This patch updates the module to use
TLSv1+. At this time, it does not refactor res_jabber/res_xmpp to use the
TCP/TLS core, which should be done as an improvement at a latter date.
(2) The TCP/TLS core, when tlsclientmethod/sslclientmethod is left unspecified,
will default to the OpenSSL SSLv23_method. This method allows for all
encryption methods, including SSLv2/SSLv3. A MITM can exploit this by
forcing a fallback to SSLv3, which leaves the server vulnerable to POODLE.
This patch adds WARNINGS if a user uses SSLv2/SSLv3 in their configuration,
and explicitly disables SSLv2/SSLv3 if using SSLv23_method.
For TLS clients, Asterisk will default to TLSv1+ and WARN if SSLv2 or SSLv3 is
explicitly chosen. For TLS servers, Asterisk will no longer support SSLv2 or
SSLv3.
Much thanks to abelbeck for reporting the vulnerability and providing a patch
for the res_jabber/res_xmpp modules.
Review: https://reviewboard.asterisk.org/r/4096/
ASTERISK-24425 #close
Reported by: abelbeck
Tested by: abelbeck, opsmonitor, gtjoseph
patches:
asterisk-1.8-jabber-tls.patch uploaded by abelbeck (License 5903)
asterisk-11-jabber-xmpp-tls.patch uploaded by abelbeck (License 5903)
AST-2014-011-1.8.diff uploaded by mjordan (License 6283)
AST-2014-011-11.diff uploaded by mjordan (License 6283)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@425986 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Drop an error log message to debug level 1 since distributed device
state functions correctly when receiving this message and it spams the
logs.
(closes issue ASTERISK-22410)
Reported by: abelbeck
Patches:
asterisk-1.8-res_jabber-log-nonpubsub-error-to-debug.patch uploaded by abelbeck (License 5903)
asterisk-11-res_xmpp-log-nonpubsub-error-to-debug.patch uploaded by abelbeck (License 5903)
........
Merged revisions 401119 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@401120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Sometimes the Google Voice servers have a bad habit of sending out 1
byte replies to the xmpp resource. When a blank 1 byte reply is
received from the socket the buffer attempts to wait (endlessly) for
the rest of the reply from google which effectively blocks the socket
and google voice calls will no longer come into the server.
This patch allows the xmpp module to correctly detect empty packets and
send out ping replies to google. It also sets a socket timeout on the
default socket which prevents the xmpp socket from closing and
preventing future google voice calls from coming into the server.
Furthermore instead of sending an empty reply back to google we send a
proper xmpp ping reply back. This also adds several more
socket messages.
(closes issue ASTERISK-22347)
Reported by: Andrew Nagy
Review: https://reviewboard.asterisk.org/r/2771
Patches:
xmpp_fix_1.diff uploaded by Andrew Nagy (License #6524)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@398618 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The mailbox and context are swapped on the receiving end for all users
of Jabber and XMPP distributed MWI in Asterisk 1.8 and all more recent
versions. This swaps those values to be correct when publishing to the
internal event system from Jabber/XMPP distributed MWI state.
(closes issue ASTERISK-22435)
Reported by: abelbeck
Tested by: Michael Keuter
Patches:
asterisk-1.8-res_jabber-aji_handle_pubsub_event.patch uploaded by abelbeck
asterisk-11-res_xmpp-xmpp_pubsub_handle_event.patch uploaded by abelbeck
........
Merged revisions 398523 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@398558 65c4cc65-6c06-0410-ace0-fbb531ad65f3
res_xmpp was not adding AST_EVENT_IE_CACHABLE to the event as each message came in,
then devstate_change_collector_cb() was unable to find AST_EVENT_IE_CACHABLE in the event,
so defaulted incorrectly to AST_DEVSTATE_NOT_CACHABLE.
(issue ASTERISK-20175)
(closes issue ASTERISK-21429)
(closes issue ASTERISK-21069)
(closes issue ASTERISK-21164)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2452/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@385938 65c4cc65-6c06-0410-ace0-fbb531ad65f3
An error existed in res_xmpp where it would attempt to delete attributes from
a node that itself was also deleted. Per the iksemel documentation, attributes
added using iks_insert are copied to the parent node's stack, and will be
reclaimed when that node is itself destroyed.
(closes issue ASTERISK-20982)
Reported by: marcelloceschia
patches:
delete-node-fix.diff uploaded by marcelloceschia (License 6036)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@381159 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Again, since res_jabber/res_xmpp have duplicate APIs, their documentation ref
links have to specify which reference they're referring to. The various
documentation parsers can interpret the module attribute however they want
in order to construct the appropriate links.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@379228 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since res_jabber/res_xmpp provide the same APIs (app/func/manager/etc.),
the XML documentation for each needs to call out which module is providing
the documentation. The module attribute has been added to the various XML
fragments for this purpose.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@379209 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously if an XMPP client reconnected any filters added by an external module were lost.
This issue exhibited itself with chan_motif not receiving and reacting to Jingle signaling.
(closes issue ASTERISK-20916)
Reported by: kuj
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@378917 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch changes res_xmpp to no longer cache events under certain circumstances.
(issue ASTERISK-20175)
Reported by: Russell Bryant, Leif Madsen, Joshua Colp
Tested by: kmoore
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@378411 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Similar to r378287, res_xmpp was marshaling data read from an external source
onto the stack. For a sufficiently large message, this could cause a stack
overflow. This patch modifies res_xmpp in a similar fashion to res_jabber by
removing the stack allocation, as it was unnecessary.
(issue ASTERISK-20658)
Reported by: wdoekes
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@378409 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While XEP-0115 states that the node and ver attributes are both required, some
devices fail to provide either field. Prior to this patch, failure to provide
the node or ver attribute would cause a crash in res_xmpp. While failing to
provide the node or ver attribute is technically invalid, since this
information is not utilized by Asterisk except for reporting purposes, for
interoperability reasons, we continue to process the capability stanza anyways.
(closes issue ASTERISK-20495)
Reported by: Martin W
Tested by: Martin W
patches:
20495.patch uploaded by Martin W (license #6434)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using the channel technology agnostic application/AMI command MessageSend,
the "From" field is technically optional for the SIP channel driver. However,
if being sent by the XMPP resource module (either res_xmpp or res_jabber), the
"From" field is necessary, and must correspond to a defined account. This
patch updates the documentation for this application/AMI command to reflect
this.
(closes issue ASTERISK-20405)
Reported by: Leif Madsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374611 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in res_xmpp on unload.
This patch fixes an issue where hangup flags were not being reset on a
channel, affecting subsequent use of that channel. The patch also adds some
additional cleanup to res_xmpp to fix an issue with reloading the module.
(closes ASTERISK-20360)
Reported by: Noah Engelberth
Tested by: beagles
Review: https://reviewboard.asterisk.org/r/2134/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@374019 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A number of applications/AMI commands in Asterisk have specific behavioral
differences depending on the resource or channel technology those
applications are executed on. For example, the MessageSend application/
command is technology agnostic, but how the channel drivers that support
that functionality behave is dependant on the protocols and channel
driver implementation. Prior to this patch, those details were either
documented in the application/command documentation itself, or were left
undocumented.
This patch adds a new element to the documentation schema, <info/>. An info
node is essentially a piece of technology specific reference information that
can be included by any top level XML documentation node. For example, the
MessageSend application can now include XMPP/SIP specific information, where
that technology specific information can be defined in chan_motif/res_xmpp/
chan_sip. Likewise, that information can also be included in the MessageSend
AMI command.
Review: https://reviewboard.asterisk.org/r/2049
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370278 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The pubsub code did not attempt to remove subscriptions at all. This has now changed so that if a client is being disconnected it will unsubscribe. It will also unsubscribe at connection time so if it unexpectedly disconnected duplicate subscriptions will not occur.
(closes issue ASTERISK-19882)
Reported by: mattvryan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370157 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The MWI and device state propagation code wrongly assumes that an XMPP client connection will remain established at all times. This fix corrects that by making the lifetime of the subscription the same as the lifetime of the connection itself. As the connection is established and disconnected the subscription itself is created and destroyed.
(closes issue ASTERISK-18078)
Reported by: elguero
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370152 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A server sending a service discovery request to us may or may not put a from attribute in the message. If the from attribute is present use it in the to attribute for the result. If the from attribute is not present do not add a to attribute.
(issue ASTERISK-16203)
Reported by: wubbla
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370126 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This channel driver is a replacement for both chan_gtalk and chan_jingle but adds additional features not found in either.
These features include full configuration reload, video, full codec support, bidirectional cause code mapping, hold,
unhold, and ringing indication. It is also compliant with the current published Jingle and Google Jingle specifications.
The original Google Talk protocol is also supported for Google Voice interoperability.
You may ask yourself though where the name motif comes from... and I would say to you... music!
motif: a perceivable or salient recurring fragment or succession of notes
Sorta like a jingle!
Review: https://reviewboard.asterisk.org/r/1917/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
