[Home]

Summary:ASTERISK-10057: Potential for DoS attack?: sip history recording can go on forever if SIP dialog never expires or is destroyed
Reporter:Jon Moldenauer (jmoldenhauer)Labels:
Date Opened:2007-08-09 12:54:59Date Closed:2007-08-21 13:31:27
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) patch.2
Description:When SIP history is being recorded (which is pretty much always in the current version even when it is turned off, see related issue 10418), it is possible to exhaust system memory simply by generating lots of history events for the same SIP dialog if the dialog never expires or is destroyed.

I believe that a correctly written SIP UA could exploit this problem to cause a DoS attack by causing a significant amount of memory to be consumed by the SIP history recording interface.

It is unknown to me whether it could be remotely exploited by anonymous users; I believe you would have to be authenticated either by IP or by username/secret.

I have only confirmed that this is a problem for SUBSCRIBE packets; it is unknown if this could be a problem for other SIP packets.

****** ADDITIONAL INFORMATION ******

In my setup, I have several Grandstream GXP-2000s running firmware 1.1.4.18.  They send a SUBSCRIBE for each button mapped to an Asterisk BLF setting.  They appear to do this VERY frequently (about every 30 seconds for each button), even though the expiration is set for 3600 seconds.  My knowledge of SIP is limited, but I would argue that this is not correct behaviour.

Still, what this causes to occur in asterisk with SIP history recording turned on is quite bad.  I believe the following is a rough outline of what happens based upon my observations of the code and actual CLI output.  Not everything may be in the correct order but this is the general flow:

1. Phone sends an unauthorized SUBSCRIBE packet for an extension
2. Asterisk creates a new SIP dialog and adds an "Auth" history entry and
  sends back an authorization required SIP packet.
3. Phone sends back an authorized SUBSCRIBE packet
4. Asterisk adds an "AuthOk" history entry to the dialog
5. Asterisk adds an "Subscribestatus" history entry to the dialog
6. Asterisk sets the dialog expiration, which in my case is 3600 seconds which
  I believe is the default setting.  It schedules the destruction of the SIP
  dialog for the expiration time.
7. Asterisk sends the phone an "ACK" or "OK" or whatever packet in response to
  the SUBSCRIBE.
8. Before the expiration occurs, the phone sends another unauthorized
  SUBSCRIBE packet.
9. Asterisk adds an "Auth" history entry and sends back an authorization
  required packet.
10. The phone response with correctly authorized SUBSCRIBE packet.
11. Asterisk adds an "AuthOk" history entry to the dialog
11. Asterisk treats this as a re-SUBSCRIBE.  It cancels the pending destruction
  of the SIP dialog.  It appends a "CancelDestroy" message to the history.
12. Go to step 5 above.

Note that since the dialog is never destroyed because the dialog destruction is cancelled, the history is also never destroyed.  The result is that the history continues to grow, and grow, and grow.  In my production system, I observed asterisk running the system out of memory in as little as 24 hours and swapping would begin within 8 hours.  My system is fairly small, but I could see that with an increased number of GXP-2000 phones that the system could run out of memory even faster.

The patch I am attaching to this deals with the problem exclusively for the SUBSCRIBE packet and it is not an optimal solution.  I think a longer term solution might be to simply have a per-dialog history limit (say 100 items, or 50, or 10, or maybe user configurable) that is enforced in the append_history_va function.  Since the list is implemented as a doubly-linked list, enforcing the limit would not be cpu-cycle intensive.
Comments:By: Digium Subversion (svnbot) 2007-08-21 13:24:20

Repository: asterisk
Revision: 80183

------------------------------------------------------------------------
r80183 | russell | 2007-08-21 13:24:18 -0500 (Tue, 21 Aug 2007) | 7 lines

Don't record SIP dialog history if it's not turned on.  Also, put an upper
limit on how many history entires will be stored for each SIP dialog.  It is
currently set to 50, but can be increased if deemed necessary.
(closes issue ASTERISK-10057, closes issue ASTERISK-9983, patches suggested by jmoldenhauer,
patches updated by me)
(Security implications documented in AST-2007-020)

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-08-21 13:31:27

Repository: asterisk
Revision: 80184

------------------------------------------------------------------------
r80184 | russell | 2007-08-21 13:31:25 -0500 (Tue, 21 Aug 2007) | 15 lines

Merged revisions 80183 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r80183 | russell | 2007-08-21 13:42:15 -0500 (Tue, 21 Aug 2007) | 7 lines

Don't record SIP dialog history if it's not turned on.  Also, put an upper
limit on how many history entires will be stored for each SIP dialog.  It is
currently set to 50, but can be increased if deemed necessary.
(closes issue ASTERISK-10057, closes issue ASTERISK-9983, patches suggested by jmoldenhauer,
patches updated by me)
(Security implications documented in AST-2007-020)

........

------------------------------------------------------------------------