[asterisk-bugs] [JIRA] (ASTERISK-20175) Security Vulnerability: denial of service attack through exploitation of device state caching

[Alec Davis (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-20175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alec Davis updated ASTERISK-20175:
----------------------------------

    Regression: Yes  (was: No)
    
> Security Vulnerability: denial of service attack through exploitation of device state caching
> ---------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-20175
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20175
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/General
>    Affects Versions: 1.8.14.1, 10.6.1, 10.6.1-digiumphones
>            Reporter: Matt Jordan
>            Assignee: Kinsey Moore
>      Target Release: 1.8.19.1, 10.11.1, 10.11.1-digiumphones, 11.1.1
>
>         Attachments: event-cachability-3.diff
>
>
> 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:
> {noformat}
>     *CLI> event dump cache DeviceState
> {noformat}
> In particular, the states that were causing the problem on these
> systems were things like:
> {noformat}
>     Local/12341234 at whatever
>     DAHDI/i8/12341234
> {noformat}
> 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:
> {noformat}
>    ; sip.conf
>     [someserver]
>     type=peer
>     host=someserver.com
>     fromdomain=example.com
>     fromuser=foo
> {noformat}
> I then used a call file:
> {noformat}
>     Channel: SIP/foo at someserver
>     CallerID: "My Name" <1111111>
>     Application: Playback
>     Data: beep
> {noformat}
> 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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira