Talos Vulnerability Report

TALOS-2018-0699

May 13, 2019

CVE Number

CVE-2018-4027

Summary

An exploitable denial-of-service vulnerability exists in the XML_UploadFile Wi-Fi command of the NT9665X Chipset firmware, running on the Anker Roav A1 Dashcam, version "RoavA1SWV1.9.” A specially crafted packet can cause a semaphore deadlock, which prevents the device from receiving any physical or network inputs. An attacker can send a specially crafted packet to trigger this vulnerability.

Tested Versions

Anker Roav A1 Dashcam RoavA1SWV1.9

Product URLs

CVSSv3 Score

5.3 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

CWE

CWE-833: Deadlock

Details

The Novatek NT9665X SOC is a chipset used in an large number of consumer camera devices, particularly in dashboard cameras. The chip provides default firmware that is a fork of the Embedded Configurable Operating System (eCOS) project, which is found within the Roav A1 Dashcam,the product we are focusing on in this advisory.

The Roav A1 Dashcam by Anker is a dashboard camera that allows users to connect using the Roav app for Android and iOS so that they can control the camera remotely. In order to do this, users must first enable the “Wi-Fi AP” setting manually on the dashcam, and then connect to the “RoavA1” SSID, with the default password of “goroavcam”.

From here, the app interacts mainly with the dashboard camera via an eCOS web server running on port 80 that requires no authentication. The standard HTTP POST, GET and DELETE requests can be used to upload, download or delete videos and pictures from the dashcam, but there’s also a separate interface used for configuration. When requesting any url, a set of commands is accessed by providing the following http query string: ?custom=1&cmd=<0000-9999>. It should be noted that only a firmware-specific subset of commands are implemented on any given device, the list of which can be found by accessing http://192.168.1.254/?custom=1&cmd=3012.

For the following vulnerability, the XML_UploadFile command (5001) will be discussed. Like all the other Wi-Fi commands, the prototype for this function is:

Stepping back before the call to XML_UploadFile, there’s two functions that handle the setup and calling of a given Wi-Fi opcode: WifiCmd_PutData and WifiCmd_DispatchCmd, the former of which calls the latter, the latter of which sometimes waits for the WifiCmd to finish before returning.

This particular vulnerability focuses on the WifiCmd_PutData in combination with XML_UploadFile, as this particular command seems to be the only WifiCmd that causes a specific code path inside of WifiCmd_PutData to occur.

The following function is called inside of WifiCmd_PutData before any processing is done on the HTTP request:

The WifiCmd_Lock, aptly named, locks the global WIFICMD_SEM_ID semaphore, such that only one thread can access the WiFi commands at any given time.
As such, when calling the XML_UploadFile function via a POST command to http://192.168.1.254/?custom=1&cmd=5001, the following log messages are displayed over UART:

At [0] we can see that the WifiCmd_Lock is correctly locked, and at [1] that the program did in fact spawn a new thread for the XML_UploadFile function. At [2], we hit a log message that indicates a file was opened for writing:

At [3], we see the 2330 for the CHK value printed above, assuring that this is indeed the right code path. From here, if the provided request does not provide a "par=%d" HTTP query parameter, then the function returns 0x0 back to WifiCmd_PutData() at the following disassembly:

The call at [4] is the WifiCmd that was just returned from, and the $s7 value that the code flow depends on at [5] is equal to 0x0, which causes the comparison to fail, and we reach the last basic block of the function which returns. To finally get around to where the vulnerability lies, let us examine the branch we did not take:

The path we take does not reach [6], and as such the WIFICMD_SEM_ID is never unlocked, thus all other Wi-Fi commands are disabled at this point until the device reboots. Note, however, that the Wi-Fi can still be reset via the buttons on the device, allowing normal operations to resume.

More severely, if five more Wi-Fi requests of any type are sent to the device, the following can be seen via the ker dump command over UART:

The device seems to lock up immediately as six new threads are contending for the WIFICMD_SEM_ID, which will never unlock. At this point, any subsequent HTTP communication results in the error message ERR: Exceed max clients 6, moreover, any and all button presses are ignored, even the power button.

Additionally, while the device still does record valid video to the SD card, it is possible to completely disable the device until the battery runs out.