Hello Juha,
On 04/01/2009 10:05 AM, Juha Heinanen wrote:
Juha Heinanen writes:
does the module check that reply to the request
from uas really includes
the added parameter in its r-r header or is correct operation of
in-dialog requests at the mercy of the uas?
answering to myself, i read the source code and looks like
restore_from_reply function does not check that the r-r param that was
added when request was processed, was copied by uas to the reply or that
the reply contains the r-r header that the proxy added to the
request.
isn't this a security risk? even without the from replacing business,
shouldn't proxy ALWAYS check that the reply contains the r-r header that
it added? if it does not, the uac can be fooled to send in-dialog
requests to somewhere else (unless it is configured to always use this
proxy as its next hop).
so if proxy receives a request that contains a (possibly missing) r-r
header:
r-r: a,b
and it adds itself (c) there
r-r: a,b,c
when reply comes back, shouldn't the proxy check that the r-r header in
the reply starts with
r-r: a,b,c
if not, what am i missing here?
Indeed, there can be an extra check there. Not sure how much protection
it adds here. When X calls Y, if caller is trusted (e.g., auth user,
trusted peer) then either call goes to costly resource (PSTN) that is
also trusted, to a local user or untrusted destination, case in which
you route only if does not cost you anything. If local users are not
trustable and use "custom UA", then replies can go to first Via,
skipping the rest of Via stack, ignoring negative replies after 200ok.
Unless there is symmetric nat and they are forced to use the proxy, the
safest will be a b2bua.
Say you get a 200OK to an INVITE with spoofed r-r, should it be dropped?
Cheers,
Daniel
--
Daniel-Constantin Mierla