Server proneness to Denial-of-Service

[GoogleCodeExporter]

There is a simple DoS attack against the UniMRCP server:

1. Client sends SIP INVITE.
2. Server creates and opens engine channel, starts listening for MRCPv2 
connection and answers.
3. If the client does not establish the MRCPv2 connection, the server session 
remains opened and the (engine) channel is frozen.
4. Since there is a limited number of channels, the server (resource) can get 
quickly out-of-service.

The behaviour in 3. need not be caused by an attacker, there might be just a 
network problem or a client crash.

The solution would be an ability to set a timeout it which the MRCPv2 
connection must be established (check in the poller task?), otherwise the 
session would be terminated.
It would be great if it was also possible to terminate the session from 
server-side (plugins) from other reasons, see
https://groups.google.com/forum/?fromgroups#!topic/unimrcp/rpyZ9W-hOt8

Original issue reported on code.google.com by tomas.valenta@speechtech.cz on 6 Apr 2014 at 3:25

[GoogleCodeExporter]

Hi Vali,

Agree with the resolution, but to say the truth, don't know how to approach 
this and other known issues related to the case, where the server is supposed 
to close the session because of inactivity, misuse, etc. Technically speaking, 
it's clear what needs to be done. The general problem, however, unfortunately 
doesn't lie in the technical field.

Although the same or related problems have been raised up several times by 3-rd 
party vendors using the UniMRCP server in production, none of them seems be 
interested enough to follow up and support the development efforts.

For the time being, you may need to work around this issue. And I'd be glad to 
assist you when I can.

Cheers.

Original comment by achalo...@gmail.com on 8 Apr 2014 at 3:15

• Added labels: Usability

[GoogleCodeExporter]

Hi Arsen,

I also noticed similar issue is addressed in other tickets, e.g. Issue-163. 
Well, I do have a kind of workaround, but it does not solve the problem, it 
just postpones it:

All checking is done in an engine plugin -- time from last MRCP request, last 
audio data, completion event (e.g. RECOGNITION-COMPLETE), whatever. When such a 
condition occurs, mrcp_session_terminate_request(session) is invoked. The 
session object is found in server's session hash table and the server object is 
engine_channel->engine->event_obj. Not only this workaround is ugly and not 
straightforward, it does not free all the resources associated with the 
session. It destroys the engine channel and the MRCP session, but (here I am 
not sure) not the RTP (MPF) session, Sofia/RTSP session and maybe something 
else. So sooner or later, the server runs out of RTP ports.

This was what I was able to do in a short time from what I understand about 
UniMRCP server design. As I see it, there would have to be some counters in 
other/signalling sessions (RTSP, Sofia, MRCPv2, MPF) so that when the number of 
MRCP sessions associated with them decreased to zero, the other sessions would 
terminate as well. I do not think I can do this myself, because I do not know 
the server design that well.

Last, I would vote, if there is a redesign of the server, for more information 
available in engine plugins, for example:
- client IP address (for better logging/billing),
- client identity -- IP, SSL certificate etc. (authentication),
- full server configuration (e.g. IP for generating saved waveform URI),
- the more info the better.

Thanks for support and cheers,
- Vali

Original comment by tomas.valenta@speechtech.cz on 8 Apr 2014 at 9:06