* You are viewing the archive for April 23rd, 2012

Problem with blank/empty voicemails

Hi,
I hope for a hint on this issue.

I had a voicemail running on ast release 1.6.2 latest which i upgraded
to 1.8.11 latest release.
during this process I did add a couple of fields like minsecs and maxsecs.

I do now get empty emails where the attached voicefile only contains the
voice header,
the message length written in the email is ok.
If I go to the voicemailbox during the recording then I can se the files
grow to the filesize i would expect, looks like everything is ok until then.

When I press the ‘#’ or hangup then the email is generated with the
empty attachment and the voicefiles in the INBOX is now
44 bytes for .wav and
60 byes for .WAV

I have voicemail in mysql and messages stored i filesystem
here is some of the config (which worked ok on release 1.6.2)
attachfmt=wav
deletevoicemail=no
volgain=0.0
minsecs=2
maxsecs=600

[Apr 23 21:59:46] DEBUG[31841] app.c: Locked path
‘/var/spool/asterisk/voicemail/default/88855/INBOX’
[Apr 23 21:59:46] DEBUG[31841] app.c: Unlocked path
‘/var/spool/asterisk/voicemail/default/88855/INBOX’
[Apr 23 21:59:46] DEBUG[31841] channel.c: Scheduling timer at (50
requested / 50 actual) timer ticks per second
[Apr 23 21:59:46] VERBOSE[31841] file.c: –
Playing ‘beep.alaw’ (language ‘dk’)
[Apr 23 21:59:46] DEBUG[31841] channel.c: Scheduling timer at (182
requested / 182 actual) timer ticks per second
[Apr 23 21:59:46] DEBUG[31841] channel.c: Scheduling timer at (0
requested / 0 actual) timer ticks per second
[Apr 23 21:59:46] DEBUG[31841] channel.c: Scheduling timer at (0
requested / 0 actual) timer ticks per second
[Apr 23 21:59:46] DEBUG[31841] channel.c: Scheduling timer at (0
requested / 0 actual) timer ticks per second
[Apr 23 21:59:46] VERBOSE[31841] app_voicemail.c: — Recording the
message
[Apr 23 21:59:46] DEBUG[31841] app.c: play_and_record: ,
/var/spool/asterisk/voicemail/default/88855/tmp/N0NNlv, ‘wav49|gsm|wav’
[Apr 23 21:59:46] DEBUG[31841] app.c: Recording Formats: sfmts=wav49
[Apr 23 21:59:46] VERBOSE[31841] app.c: — x=0, open writing:
/var/spool/asterisk/voicemail/default/88855/tmp/N0NNlv format: wav49,
0xb3501378
[Apr 23 21:59:46] VERBOSE[31841] app.c: — x=1, open writing:
/var/spool/asterisk/voicemail/default/88855/tmp/N0NNlv format: gsm,
0xb266b1b0
[Apr 23 21:59:46] VERBOSE[31841] app.c: — x=2, open writing:
/var/spool/asterisk/voicemail/default/88855/tmp/N0NNlv format: wav,
0xb3519948
[Apr 23 21:59:46] DEBUG[31841] dsp.c: Setup tone 1100 Hz, 500 ms,
block_size=160, hits_required=21
[Apr 23 21:59:46] DEBUG[31841] dsp.c: Setup tone 2100 Hz, 2600 ms,
block_size=160, hits_required=116
[Apr 23 21:59:46] DEBUG[31841] channel.c: Set channel
SIP/_Mw_cHFm6vZAyV-00012a5c to read format slin
[Apr 23 22:00:03] VERBOSE[31841] app.c: — User hung up
[Apr 23 22:00:03] DEBUG[31841] channel.c: Set channel
SIP/_Mw_cHFm6vZAyV-00012a5c to read format alaw
[Apr 23 22:00:03] DEBUG[31841] app.c: Locked path
‘/var/spool/asterisk/voicemail/default/88855/INBOX’
[Apr 23 22:00:03] DEBUG[31841] app.c: Unlocked path
‘/var/spool/asterisk/voicemail/default/88855/INBOX’
[Apr 23 22:00:03] DEBUG[31841] app_voicemail.c: Attaching file
‘/var/spool/asterisk/voicemail/default/88855/INBOX/msg0000′, format
‘wav’, uservm is ’2048′, global is 2048
[Apr 23 22:00:03] VERBOSE[31841] config.c: == Parsing
‘/var/spool/asterisk/voicemail/default/88855/INBOX/msg0000.txt’: [Apr 23
22:00:03] DEBUG[31841] config.c: Parsing
/var/spool/asterisk/voicemail/default/88855/INBOX/msg0000.txt
[Apr 23 22:00:03] VERBOSE[31841] config.c: == Found
[Apr 23 22:00:03] VERBOSE[31841] config.c: == Parsing
‘/var/spool/asterisk/voicemail/default/88855/INBOX/msg0000.txt’: [Apr 23
22:00:03] DEBUG[31841] config.c: Parsing
/var/spool/asterisk/voicemail/default/88855/INBOX/msg0000.txt
[Apr 23 22:00:03] VERBOSE[31841] config.c: == Found
[Apr 23 22:00:03] DEBUG[31841] pbx.c: Evaluating ‘VM_NAME’ (from ‘VM_NAME}:
[Apr 23 22:00:03] DEBUG[31841] pbx.c: Result of ‘VM_NAME’ is ‘Freddi Hansen’
[Apr 23 22:00:03] DEBUG[31841] pbx.c: Evaluating ‘VM_DUR’ (from ‘VM_DUR}
lang besked (number ${VM_MSGNUM})
[Apr 23 22:00:03] DEBUG[31841] pbx.c: Result of ‘VM_DUR’ is ’0:16′
[Apr 23 22:00:03] DEBUG[31841] pbx.c: Evaluating ‘VM_MSGNUM’ (from
‘VM_MSGNUM})
[Apr 23 22:00:03] DEBUG[31841] pbx.c: Result of ‘VM_MSGNUM’ is ’1′
[Apr 23 22:00:03] DEBUG[31841] pbx.c: Evaluating ‘VM_MAILBOX’ (from
‘VM_MAILBOX} fra ${VM_CALLERID}, den ${VM_DATE}. Tak!
[Apr 23 22:00:03] DEBUG[31841] pbx.c: Result of ‘VM_MAILBOX’ is ’88855′
[Apr 23 22:00:03] DEBUG[31841] pbx.c: Evaluating ‘VM_CALLERID’ (from
‘VM_CALLERID}, den ${VM_DATE}. Tak!
[Apr 23 22:00:03] DEBUG[31841] pbx.c: Result of ‘VM_CALLERID’ is
‘”voicemailtest” <_mw_chfm6vzayv>‘
[Apr 23 22:00:03] DEBUG[31841] pbx.c: Evaluating ‘VM_DATE’ (from
‘VM_DATE}. Tak!
[Apr 23 22:00:03] DEBUG[31841] pbx.c: Result of ‘VM_DATE’ is ‘Monday, 23
April 2012 at 22:00:03′
[Apr 23 22:00:03] DEBUG[31841] app_voicemail.c: creating attachment
filename msg0000.wav, no second attachment.
[Apr 23 22:00:03] DEBUG[31841] app_voicemail.c: Sent mail to
fh@danovation.dk with command ‘/usr/sbin/sendmail -t’
[Apr 23 22:00:03] DEBUG[31841] pbx.c: Spawn extension
(voicemailtest,222,2) exited non-zero on ‘SIP/_Mw_cHFm6vZAyV-00012a5c’

Grandstream 1.0.3.30 BETA Firmware

If you are using Grandstream GXP 21XXX and 14XX phones and you are doing
any kind of remote firmware updates or config updates DO NOT use the
1.0.3.30 BETA version. We have found a bug in it that causes HTTP updates
to not work if you are using a domain name and not an IP address for
pulling configs and firmware. It can put you in a state where you can’t
update the configs or firmware without direct web or telnet contact to the
phone.

Thanks

Bryant

HELP!! Caller ID “unknown” for all inbound call (Satria Anamarta)

Hi

I’m not agree problem could be cause from IRQ setting, I think in that way problem should be more unstable, moreover no voice communication problem with DAHDI service start up.
Best regards

Mc GRATH Ricardo
E-Mail mcgrathr@mail2web.com

Remote Crash Vulnerability in SIP Channel Driver

Asterisk Project Security Advisory – AST-2012-006

Product Asterisk
Summary Remote Crash Vulnerability in SIP Channel Driver
Nature of Advisory Remote Crash
Susceptibility Remote Authenticated Sessions
Severity Moderate
Exploits Known No
Reported On April 16, 2012
Reported By Thomas Arimont
Posted On April 23, 2012
Last Updated On April 23, 2012
Advisory Contact Matt Jordan < mjordan AT digium DOT com >
CVE Name

Description A remotely exploitable crash vulnerability exists in the
SIP channel driver if a SIP UPDATE request is processed
within a particular window of time. For this to occur, the
following must take place:

1. The setting ‘trustrpid’ must be set to True

2. An UPDATE request must be received after a call has been
terminated and the associated channel object has been
destroyed, but before the SIP dialog associated with the
call has been destroyed. Receiving the UPDATE request
before the call is terminated or after the SIP dialog
associated with the call will not cause the crash
vulnerability described here.

3. The UPDATE request must be formatted with the
appropriate headers to reflect an Asterisk connected line
update. The information in the headers must reflect a
different Caller ID then what was previously associated
with the dialog.

When these conditions are true, Asterisk will attempt to
perform a connected line update with no associated channel,
and will crash.

Resolution Asterisk now ensures a channel exists before performing a
connected line update, when that connected line update is
initiated via a SIP UPDATE request.

In Asterisk versions not containing the fix for this issue,
setting the ‘trustrpid’ setting to False will prevent this
crash from occurring (default is False)

Affected Versions
Product Release Series
Asterisk Open Source 1.8.x All versions
Asterisk Open Source 10.x All versions
Asterisk Business Edition C.3.x All versions

Corrected In
Product Release
Asterisk Open Source 1.8.11.1, 10.3.1
Asterisk Business Edition C.3.7.4

Patches
SVN URL Revision
http://downloads.asterisk.org/pub/security/AST-2012-006-1.8.diff v1.8
http://downloads.asterisk.org/pub/security/AST-2012-006-10.diff v.10

Links https://issues.asterisk.org/jira/browse/ASTERISK-19770

Asterisk Project Security Advisories are posted at
http://www.asterisk.org/security

This document may be superseded by later versions; if so, the latest
version will be posted at
http://downloads.digium.com/pub/security/AST-2012-006.pdf and
http://downloads.digium.com/pub/security/AST-2012-006.html

Revision History
Date Editor Revisions Made
04/16/2012 Matt Jordan Initial release.

Asterisk Project Security Advisory – AST-2012-006
Copyright (c) 2012 Digium, Inc. All Rights Reserved.
Permission is hereby granted to distribute and publish this advisory in its
original, unaltered form.

Heap Buffer Overflow in Skinny Channel Driver

In the Skinny channel driver, KEYPAD_BUTTON_MESSAGE events are queued for processing in a buffer allocated on the heap, where each DTMF value that is received is placed on the end of the buffer. Since the length of the buffer is never checked, an attacker could send sufficient KEYPAD_BUTTON_MESSAGE events such that the buffer is overrun.

Now, the length of the buffer is now checked before appending a value to the end of the buffer.

Affected Versions:

  • Product Release Series
  • Asterisk Open Source 1.6.2.x All Versions
  • Asterisk Open Source 1.8.x All Versions
  • Asterisk Open Source 10.x All Versions

Corrected In Product Release:

  • Asterisk Open Source 1.6.2.24, 1.8.11.1, 10.3.1

Asterisk Manager User Unauthorized Shell Access

A user of the Asterisk Manager Interface can bypass a security check and execute shell commands when they lack permission to do so. Under normal conditions, a user should only be able to run shell commands if that user has System class authorization. Users could bypass this restriction by using the MixMonitor application with the originate action or by using either the GetVar or Status manager actions in combination with the SHELL and EVAL functions. The patch adds checks in each affected action to verify if a user has System class authorization. If the user does not have those authorizations, Asterisk rejects the action if it detects the use of any functions or applications that run system commands.

Asterisk now performs checks against manager commands that cause these behaviors for each of the affected actions.

The following versions are affected:

  • Asterisk Open Source 1.6.2.x All versions
  • Asterisk Open Source 1.8.x All versions
  • Asterisk Open Source 10.x All versions
  • Asterisk Business Edition C.3.x All versions

Corrected In Product Release:

  • Asterisk Open Source 1.6.2.24, 1.8.11.1, 10.3.1
  • Asterisk Business Edition C.3.7.4