[sr-dev] improving the dialog module
Klaus Darilion
klaus.mailinglists at pernau.at
Wed Mar 17 18:30:47 CET 2010
Am 17.03.2010 18:18, schrieb IƱaki Baz Castillo:
> 2010/3/17 Klaus Darilion<klaus.mailinglists at pernau.at>:
>
>>> But that is not a spoofed reply, instead it's just a 100% valid reply
>>> with a different To-tag. It could occur if the called is a proxy which
>>> performs serial forking (so after some seconds our proxy receives
>>> responses with a new To-tag, i.e. the remote voicemail server).
>>
>> Let's call it a malicious reply. I was talking about a false from-tag, not
>> to-tag. Thus, tm will accept the 200 ok and terminate the transaction (if it
>> is implemented RFC conform). If dialog module checks from-tag it probably
>> will ignore the reply.
>
> You are rigth, sorry, I understood "To-tag".
> Well, from the proxy point of view the transaction must end (even if
> From tag doesn't match the dialog data), as the transaction layer is
> not dialog aware.
>
> But of course the dialog module would ignore the response as From-tag
> doesn't match, and that's the expected behavior (the UAC wouuld also
> ignore such response).
I checked dialog code: it is safe. Dialog does not have to check
callid/tags as the dialog is already identified via the tm-callback (at
least of out-of-dialog transactions).
Thus, a malicious response can not be used to bring tm/dialog out of
synchronization.
>> Anyway, I guess dialog module is only good as helper module but shouldn't be
>> used as a reliable module (e.g. for security, accounting ...)
>
> That's the question. Theorically dialog module is just a helper, but
> looking at OpenSIPS there are several modules offering functionality
> based on dialog module... so... It's like "it's not a secure/robust
> module but I don't care".
I think it is OK for things like NAT traversal as an attacker can just
stop its NAT traversal.
But for example it is unreliable for accounting. E.g. a malicious BYE
request with manipulated RURI (sip:foo.bar instead of
sip:00431234 at ip.address.of.gw) will stop the dialog, but never reach the
gateway.
regards
klaus
More information about the sr-dev
mailing list