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:
In particular, the states that were causing the problem on these
systems were things like:
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:
I then used a call file:
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.