[sr-dev] LCR: defunct_gw() is dangerous

Iñaki Baz Castillo ibc at aliax.net
Wed Dec 28 17:12:38 CET 2011


2011/12/28 Juha Heinanen <jh at tutpro.com>
>
> > An ugly client sends us a request with a malformed P-Asserted-Identity
> > as follows:
> >
> >   P-Asserted-Identity(sip at domain.com
> >
> > Note that it's an *invalid* header. But Kamailio "allows" it and the
> > request arrives to the GW. But the GW drops the request due to the
> > malformed header so it sends NO reply at all. Then timeout occurs in
> > the client transaction and failure_route block is called in which I
> > call to defunct_gw().
>
> check the headers you are forwarding to your gws.

There is no way to detect a header like I meant:

  P-Asserted-Identity(sip at domain.com

Kamailio parser does not detect such header as "P-Asserted-Identity".

Also, it's unfeasible that a proxy checks the syntax of all the
headers. Typically a proxy just cares about some few headers.


> also, you can count
> the number of failures yourself by using htable, for example, and not
> defunct your gw based on the first failure.

So the attacker should just send 5 malformed requests rather than one.


> further, you could define a
> timed route, and based on the htable, ping your gws.

Right, but is failure_route executed for those locally sent requests?
I must check it.



> > Conclusion: an attacker could dissable my gws just by sending a simple
> > malformed request. I strongly miss the monitorization feature in the
> > old LCR module.
>
> my conclusion is as it was before:  keep lcr module simple and do
> monitoring separately.  it might be possible to include a mi command to
> manage defunct time of a gw, but i'm not sure about it, because
> currently the tables may not include enough info to pinpoint a
> particular gw.

IMHO that's due to the design of the tables in LCR module. IMHO there
should be a table just with gws definition (without containing the
lcr_id field). It would make easier the management for cases like the
present (just my opinion).

Regards.


--
Iñaki Baz Castillo
<ibc at aliax.net>



More information about the sr-dev mailing list