|Subject:||Re: [osip-dev] SUBSCRIBE forking|
|Date:||Fri, 14 Apr 2017 13:49:24 +0200|
I currently only have the sources of eXosip 5.0.0; here it’s line 1053 in udp.c
yes – it’s the call of _eXosip_dialog_init_as_uac
… but according to RFC 3265 / RFC 6665 it is a valid use-case
to fork a SUBSCRIBE and generate additional dialogs with multiple NOTIFYs.
So, if you strictly allow only a single dialog per subscription,
you are on the safe side – but you disallow a feature, which should be possible !
What do you think about limiting the number of forks ? (e.g. to 8 oder 16, which could be a define)
we would only call _eXosip_dialog_init_as_uac in case that the max. number of dialogs
in the matching subscription is not yet reached.
otherwise we should send a 481 – without generating a dialog !
.. or ignore the NOTIFY request at all.
I have partly discovered the issue (where NOTIFY with
different tag are accepted even if dialog is established)
Reading quickly the code, it seems the leak occurs on line 1133
of udp.c file? The dialog is replaced but not release?
(--line is calling _eXosip_dialog_init_
Do you confirm this is the leak?
2017-04-13 12:26 GMT+02:00 FEICHTER Christoph <Christoph.FEICHTER@
we recently found out about a vulnerability of SIP regarding forking of SUBSCRIBE requests – which
also applies to eXosip.
The scenario is the following:
- UAC subscribes an event
- the UAS (subscribee) accepts and sends NOTIFY requests
- the UAS generates for each NOTIFY request a new From-tag.
This makes it look for the subscriber as if the SUBSCRIBE request has been forked,
and multiple subscribes do send NOTIFYs !
In eXosip it seems to no make a difference, whether these NOTIFY requests are answered
by 200 Ok or a 456xx response. eXosip does create dialogs for each NOTIFY ..
.. and the memory consumption increases until we are out of memory.
What do you think about this vulnerability ?
Should we specify a max. number of forks for SUBSCRIBE ?
Regards and happy easter,
Antisip - http://www.antisip.com
|[Prev in Thread]||Current Thread||[Next in Thread]|