Details
-
Type:
Bug
-
Status: Closed
-
Severity:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.8.14.1, 10.6.1, 10.6.1-digiumphones
-
Target Release Version/s: 1.8.19.1, 10.11.1, 10.11.1-digiumphones, 11.1.1
-
Component/s: Core/General
-
Security Level: None
-
Labels:None
-
Regression:No
Description
From Russell:
I have been working with someone on some performance issues with their
Asterisk cluster that uses distributed device state. One of the
problems that we identified was that the size of the device state
cache was growing out of control. To view the cache, you can do:
*CLI> event dump cache DeviceState
In particular, the states that were causing the problem on these
systems were things like:
Local/12341234@whatever
DAHDI/i8/12341234
Certain "device states" like this are useless to cache. Imagine an
outbound call center that uses Local channels in their dialplan and
PRIs for doing outbound calls. They get entries in the cache for
every number they dial. Ouch. That's a bug that needs to be
addressed and I'm not quite sure how to fix it in a good generic way
yet. However, that's not the vulnerability. It's just the background
that led me to the vulnerability.
I started thinking about how far this problem really reaches. I
wondered, can I remotely grow the cache, causing performance problems
and eventually running out of RAM? Unfortunately, yes. I have
verified this with SIP. I imagine the same issue exists with IAX2.
In chan_sip, if you allow anonymous calls, the channel name is based
on the domain in the From header. I verified this vulnerability by
doing the following:
; sip.conf
[someserver]
type=peer
host=someserver.com
fromdomain=example.com
fromuser=foo
I then used a call file:
Channel: SIP/foo@someserver
CallerID: "My Name" <1111111>
Application: Playback
Data: beep
The domain in the From header should be "example.com". The channel
name on the remote server should be "SIP/example.com-<something>". An
entry will be added to the cache for "SIP/example.com". This means
that I can very easily continue to send calls with different domains
and fill up the cache.
The public server that I tested this against happened to be running
Asterisk 10. I believe that this affects all versions that have the
device state cache, which would be 1.6.something and up.
This is a nasty problem and I'm not sure what the fix should be. It's
an architectural problem. The cache needs to only consist of things
that are defined locally, and not things that are dynamically
generated, but there's not a good generic way to determine that given
a "device" name. I'd be happy to brainstorm with others on this.
While the original report came from me, I'd like to credit Leif Madsen
and Joshua Colp for their assistance with verifying the vulnerability.
Thanks,
–
Russell Bryant
Issue Links
- causes
-
ASTERISK-21069
xmpp distributed device states aggregation update fails
-
- Closed
-
-
ASTERISK-21164
Need clarification on distributed device state behavior and whether this behavior is a possible regression
-
- Closed
-
-
ASTERISK-21429
Distributed Device State using JABBER/XMPP not working since Secuity Advisory AST-2012-015
-
- Closed
-
- must be completed before resolving
-
ASTERISK-20807
1.8.20.0 Blockers
-
- Closed
-
-
ASTERISK-20808
10.12.0 Blockers
-
- Closed
-
-
ASTERISK-20809
11.2.0 Blockers
-
- Closed
-
Consumers for further state distribution:
res_xmpp
res_jabber
res_corosync
Direct consumers of device state:
app_queue
CCSS
pbx hints
devicestate
All of these seem to hook device state unconditionally except CCSS which hooks information for specific devices as they require CCSS.