PROTOCOL: Identify RTMP client, stack overflow crash, generate core file.

[HCLAC]

Zhao Wenjie:
Jie Ge, when multiple users are watching live broadcasts, there is a problem with the server crashing. After checking the generated core file, it seems that there is a stack overflow. By reading the source code, I found that in the identify_create_stream_client function of the SrsRtmpServer class, it is still recursively calling itself (identify_create_stream_client) in the case of an infinite loop. Personally, I feel that the original intention of this function is: after receiving the createstream command from the client, it should respond to the client and wait for the client to either pull or push the stream. If it is determined what type of client it is, then the mission of this function is completed. However, if it cannot determine the nature of the client, it will keep recursively calling itself, waiting for the client's message command.
Personally, I feel that this has a vulnerability. If a malicious RTMP client, which is properly processing the flow according to the RTMP protocol, continuously sends createstream commands, it will cause the server to crash.
I want to add a parameter to provide a protection mechanism by calculating the number of recursive calls to ensure the normal operation of the server. I don't know if this idea is correct. I hope Jie Ge can guide me when you have time.

TRANS_BY_GPT3

[idxa]

Can we implement it without using recursion?

TRANS_BY_GPT3

[HCLAC]

Well, I looked at the code again and removed the recursion. It is now implemented with a while loop.

TRANS_BY_GPT3

[winlinvip]

I have never encountered such a malicious client.

TRANS_BY_GPT3

[winlinvip]

Fixed in SRS3, set recursive depth to 3 at

srs/trunk/src/protocol/srs_rtmp_stack.cpp

Line 2528 in fe78c75

return identify_create_stream_client(dynamic_cast<SrsCreateStreamPacket*>(pkt), stream_id, 3, type, stream_name, duration);