### Summary
An exploitable vulnerability exists in the signature verification of the firmware update functionality of Circle with Disney. Specially crafted network packets can cause an unsigned firmware to be installed in the device resulting in arbitrary code execution. An attacker can send a series of packets to trigger this vulnerability.
### Tested Versions
Circle with Disney 2.0.1
### Product URLs
https://meetcircle.com/
CVSSv3 Score
9.9 - CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
### CWE
CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
### Details
Circle with Disney is a network device used to monitor internet use of children on a given network.
Circle provides an API command to update its firmware, which is usually used by the "Circle Home App" installed on the device administrator's phone.
The API command is "/api/UPLOAD_FIRMWARE" and is handled by the `apid` binary in function `sub_417528`. At high level, the function works as follow:
```
if "/api/UPLOAD_FIRMWARE" in url_string
if substr(source_ip, 10) != "10.123.234"
return "Bad source address in multipart post"
save_postfilebin()
if check_token()
if system("/mnt/shares/usr/bin/scripts/install_firmware.sh /tmp/postfile.bin")
system("/mnt/update_firmware.sh &")
```
The function ensures that the request comes from the network "10.123.234", then saves the uploaded firmware to "/tmp/postfile.bin" and continues the update using shell scripts.
The "install_firmware.sh" contains the following code:
```
#!/bin/sh
...
CIRCLE_ROOT=`cat /tmp/CIRCLE_ROOT`
if [ -s $1 ]; then
cd /mnt;
rm -f update_firmware.sh;
rm -f /mnt/firmware.bin;
cp -f $1 /mnt/firmware.bin
if [ -f /mnt/firmware.bin ] ; then
mount -o remount,rw,noatime,nodiratime /dev/sda3 /mnt #remount to remove sync
aescrypt -d -o /mnt/firmware.tar.gz /mnt/firmware.bin
$CIRCLE_ROOT/fwverify /mnt/firmware.tar.gz > /tmp/tmp.out || exit 1;
grep "Verified signature" /tmp/tmp.out > /dev/null || exit 1
gunzip -c /mnt/firmware.tar.gz | tar xf -
rm -f /mnt/firmware.tar.gz
...
```
First the firmware is decrypted using `aescrypt` resulting in a tar archive with a 0x200 bytes signature at its end. Then this archive is verified using `fwverify` and if the output contains "Verified signature" then the archive is extracted in "/mnt", allowing for overwriting most of the device binaries.
`aescrypt` performs a symmetric AES encryption and can be used by an attacker to create custom firmware images by using the switch "-e" in place of "-d". Moreover, since the signature verification and the update operations are not executed atomically, a race condition exists which could allow an attacker to supply an unsigned firmware that will be flashed without verification ([A] and [B] are used to refer to two parallel requests):
```
1- [A] Attacker sends an original and correctly signed firmware image
2- [A] aescrypt decrypts the image in /mnt/firmware.tar.gz
3- [A] fwverify reads /mnt/firmware.tar.gz and starts the verification process
4- [B] Attacker sends a custom, non signed firmware image
5- [B] aescrypt decrypts the image in /mnt/firmware.tar.gz
6- [A] fwverify completes the verification process, which outputs "Verified signature"
7- [A] grep succeeds and /mnt/firmware.tar.gz (from request B) is extracted in /mnt
```
### Timeline
* 2017-08-30 - Vendor Disclosure
* 2017-10-31 - Public Release
暂无评论