TrendNet Wireless Camera buffer overflow vulnerability

CVE Details

ID : CVE-2020-12763

Advisory

Description

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:

1. The vulnerability was discovered in the latest version of the firmware.
2. The vulnerability has been reported to TrendNet.
3. TrendNet disagreed to verify the vulnerability on the basis that the device has reached End-Of-Life.

Vulnerable Product

Product Images

Firmware Details

Vulnerability Details

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 :

1. As you can see from the above code, line 10-17 is a loop which searchers for the start of “Authorization: Basic” header and if found breaks out of the loop and forwards the pointer header by 0x15(which is the length of header key),
2. Then strstr function call is made to search for rn (end-of-line character) which returns a (char *)pointer.
3. The pointers created in above two points are used to calculate the size of the Authorization Basic header value by subtracting those two pointers. This value is used to find the size of the header value.
4. Then the memcpy is done from char * pointer from point 1 into the second parameter dest_buf of the function. It is at this point where the overflow could take place as no precaution is taken to check if the dest_buf is large enough to hold the auth header value. If the Authorization Basic header is very long then it can overflow the dest_buf buffer. I will prove it in a while.

Now let’s look at what are the parameter that is passed to this function. The function at 0x11ae8, let call it check_authentication, call parse_auth_header function. Let look at the disassembly of the check_authentication function.

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

Figure D

Figure E

Figure F

Figure G

Figure H

Figure I

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.

Conclusion

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!

EXPLIoT.io

At EXPLIoT.io, we build tools for security testing of Internet of Things (IoT) infrastructure and products.

1. EXPLIoT: IoT security testing and exploitation framework
2. Firmware Auditor: a pre-emptive firmware security analysis tool
3. DIVA [Damn Insecure and Vulnerable Application] Board
4. NANO: a compact hacker-friendly multi-purpose, multi-protocol hardware tool
5. ZigBee Auditor

These are products of our years of experience and expertise in the field of IoT security. We are here to help you better your security posture. For more information, visit https://expliot.io or drop us an email at [email protected]!