CVE Details
ID : CVE-2020-12763
TrendNet ProView Wireless camera TV-IP512WN (version v1.0R) is vulnerable to buffer overflow in handling RTSP packet in firmware version 1.0.4 which may result in remote code execution or denial of service. The issue is in the binary rtspd which resides in /sbin folder which is responsible for serving rtsp connection received by the device. The problem arises in parsing “Authorization: Basic” RTSP header which could be arbitrarily long, the value of this header is copied onto stack memory without any bounds check which could lead to a buffer overflow. What makes this vulnerability more severe is that the user need not be authenticated to trigger the overflow.
Before we look at the technical details it is important to note that:
One thing to note is that the bug is discovered by doing static analysis, as I am faced issue in procuring the device due to covid-19 situation, producing the crash will little difficult. I will present many screenshots of the decompiled code in the post and to make the code more readable I have renamed lots of variable/function names.
The vulnerability a CWE-120 classic stack overflow which can lead to remote code execution(RCE) or denial of service(DOS). The overflow is in rtspd binary which is in sbin folder. This binary is responsible for handling rtsp connection received by the device.
The overflow occurs while parsing Authorization: Basic header in function(address 0x11a18) let refer to it as parse_auth_header. This function receives two parameters when called, first is the buffer which holds the request RTSP header and the second parameter is where the parsed header value is copied, below is the disassembly of that function.
Figure A: Disassembly of function which does the Authorization header parsing ( parse_auth_header)
Let try to understand this function a little bit :
Figure B: The decompiled code of check_authentication function
We can see on line 36 is call parse_auth_header function. The first parameter is the pointer of the first parameter of check_authentication function itself and the second parameter is the pointer to a char buffer which is of size 64. I hope you can see the problem here.
The second parameter(dest_buf) to parse_auth_header is of fixed size (64 bytes) and then is buffer is used in copying the data in parse_auth_header function at that point no bounds check done to ensure that size of the header value is less than or equal to dest_buf size.
This is all good but how do we know that this function processes the data received from the socket? good question. Let’s see what function is calling check_authentication function. Let’s call this function as is_client_authenticated, below is the disassembly of it:
Figure C : The decompiled code of is_client_authenticated function
On line 23 check_authentication function is called and based on the return value if block is executed. In if block (line24 – 35) some error message is printed on the console with the file and function name, and also there is a string which is appended to the buffer which has the string RTSP/1.0 401 Unauthorized, this buffer is then used in send call, which is a function that writes data to the socket. This proves these series of function are executing authentication and an overflow can be triggered by providing very long Authorization Basic header.
Let’s investigate it further, find all the reference to is_client_authencticate function will help us understand when is authentication check is done. Let’s look at those references
As you can see from the above code when various camera functionalities are triggered like PAUSE, SETUP, PLAY, TEARDOWN, etc is_client_authenticated function call is made to check if the received request has appropriate Authorization to execute the functionality. The return value of zero indicates authenticated, and then the functionality is triggered, else it simply returns.
This wikipedia page show the format of RTSP protocol which also further confirms different functionality which we saw in above Figures D – I.
Another very important point which we need to be aware of is that this bug is triggered while parsing for Authorization header which means this RCE can be triggered without authentication which raised the severity of this bug.
We looked at how a simple bug in packet parsing code can cause a buffer overflow. We also looked at how the attacker can trigger the bug without authentication. We couldn’t produce a working PoC of the RCE but in the second part of this post, I will try to emulate the binary with qemu and try to trigger to overflow by creating remote socket connect and create an RCE, until then happy hacking!