hi aymeric,
you are right – it’s not a real leak, but memory consumption.
the allocated memory is not lost; it is still accessible and is regularly freed when the subscription is terminated.
… but by using this SUBSCRIBE forking method,
a subscribee can make the subscriber run out of memory.
I agree with your idea, to reject NOTIFYs being received after 32 seconds.
this is probably the most accurate solution.
to count the number of forks would require a counter;
the birth_time is available anyway and can be checked against the current time.
first patch:
I agree with this – was a copy/paste mistake ;-)
seconds patch:
is also ok !
finally a comment to what you mentioned:
“-of course, if the remote app is sending every NOTIFY with a different tag, which is not compliant, every NOTIFY will
be rejected... as expected...-”
I think, with a subscribee behaviour like this, the NOTIFYs are propagated
to the app for 64 seconds – and after this period no more forks – or what looks like forking – are allowed.
NOTE: the subscriber cannot differentiate between a single subscribee that sends
NOTIFY requests each with a new tag, and real SUBSCRIBE forking !
although the subscriber only has a single remote party (proxy, B2BUA, …)
the NOTIFY requests my originate from a single subscribee or multiple subscribes.
br,
christoph
From: Aymeric Moizard [mailto:address@hidden
Sent: Freitag, 14. April 2017 13:49
To: FEICHTER Christoph
Cc: address@hidden
Subject: Re: [osip-dev] SUBSCRIBE forking
Hi Christoph,
I've been analysing more my own code. I have written the
code years ago and I had to understand it again.
In fact, the code is accepting a NOTIFY with a different
tag and creating a new dialog for each of them.
I initially though you were reporting a "real leak": ie
lost memory for ever.
However, it looks like the current code is correct
and the only issue is about the growing memory
which is still accessible by exosip?
Please confirm that this is correct?
Thus, I understand that you want to put a limit.
It's not a bad idea. ;)
But.. what do you think about this solution:
-> reject any NOTIFY coming after more than 32 seconds?
NOTIFY with different tag are only supposed to come
very early in the process. They would come from
a real forking of a SUBSCRIBE.
Thus, after 32 seconds, there is no more possibility to
receive any new NOTIFY with different tag.
First patch: reviewing the code, I've seen a minor mistake
which is ending with a possible wrong log... very minor fix:
Second:
When matching the NOTIFY, it can only be the results of forking. And thus
there is a protocol limit for accepting such NOTIFY. I haven't been able to
see any information about this use-case in the specification. However, I'm
almost sure it is acceptable to suppose no new NOTIFY can come except
from forking.
Thus, remote app may establish the exchange after 32 seconds max.
And the new NOTIFY may exist for a period of 32 seconds max. Thus,
such NOTIFY can't come after 64 seconds. Right after matching the
dialog, I check the time and reject:
if (_eXosip_match_notify_for_subscribe (js, evt->sip) == 0) {
////NEW CODE
if (js->s_out_tr!=NULL) {
time_t now = osip_getsystemtime (NULL);
if (now-js->s_out_tr->birth_time>64) {
/* we are receiving a NOTIFY with different tag, but we don't expect newer dialogs to be initiated outside of forking */
OSIP_TRACE (osip_trace (__FILE__, __LINE__, OSIP_WARNING, NULL, "eXosip: outoftime NOTIFY no part of any established dialogs\n"));
osip_list_add (&excontext->j_transactions, transaction, 0);
_eXosip_send_default_answer (excontext, jd, transaction, evt, SIP_INTERNAL_SERVER_ERROR, NULL, "Outoftime Notification", __LINE__);
return;
}
}
////END OF NEW CODE
Can you check this new code and confirm that it is acceptable?
-of course, if the remote app is sending every NOTIFY with a different tag, which is not compliant, every NOTIFY will
be rejected... as expected...-
Regards
Aymeric
2017-04-13 13:58 GMT+02:00 FEICHTER Christoph <address@hidden>:
hi aymeric,
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.
regards,
Christoph
From: Aymeric
Moizard [mailto:address@hidden]
Sent: Donnerstag, 13. April 2017 12:36
To: FEICHTER Christoph
Cc: address@hidden
Subject: Re: [osip-dev] SUBSCRIBE forking
Hi Christoph,
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_as_uac--)
Do you confirm this is the leak?
Regards
Aymeric
2017-04-13 12:26 GMT+02:00 FEICHTER Christoph <address@hidden>:
hi aymeric,
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,
Christoph
_______________________________________________
osip-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/osip-dev
--
Antisip -
http://www.antisip.com
--
Antisip -
http://www.antisip.com