On Wednesday, July 24th Google launched the Chromecast. As soon as the source code hit GTV Hacker began their audit. Within a short period of time they had multiple items to look at for when their devices arrived. Then they received their Chromecasts the following day and were able to confirm that one of the bugs existed in the build Chromecast shipped with. From that point on they began building what you are now seeing as our public release package.
Exploit Package:
GTV Hacker Chromecast exploit package will modify the system to spawn a root shell on port 23. This will allow researchers to better investigate the environment as well as give developers a chance to build and test software on their Chromecasts. For the normal user this release will probably be of no use, for the rest of the community this is just the first step in opening up what has just been a mysterious stick up to this point. GTV Hacker hope that following this release the community will have the tools they need to improve on the shortfalls of this device and make better use of the hardware.
Is it really ChromeOS?
No, it’s not. GTV Hacker had a lot of internal discussion on this, and have concluded that it’s more Android than ChromeOS. To be specific, it’s actually a modified Google TV release, but with all of the Bionic / Dalvik stripped out and replaced with a single binary for Chromecast. Since the Marvell DE3005 SOC running this is a single core variant of the 88DE3100, most of the Google TV code was reused. So, although it’s not going to let you install an APK or anything, its origins: the bootloader, kernel, init scripts, binaries, are all from the Google TV.
How does the exploit work?
Lucky for GTV Hacker, Google was kind enough to GPL the bootloader source code for the device. So they could identify the exact flaw that allows us to boot the unsigned kernel. By holding down the single button, while powering the device, the Chromecast boots into USB boot mode. USB boot mode looks for a signed image at 0×1000 on the USB drive. When found, the image is passed to the internal crypto hardware to be verified, but after this process the return code is never checked! Therefore, they could execute any code at will.
ret = VerifyImage((unsigned int)k_buff, cpu_img_siz, (unsigned int)k_buff);
The example above shows the call made to verify the image, the value stored in ret is never actually verified to ensure that the call to “VerifyImage” succeeded. From that, they were able to execute our own kernel. Hilariously, this was harder to do than our initial analysis of exploitation suggested. This was due to the USB booted kernel needing extra modifications to allow us to modify /system as well as a few other tweaks. GTV Hacker then built a custom ramdisk which, when started, began the process of modifying the system by performing the following steps:
- Mount the USB drive plugged in to the chromecast.
- Erase the /system partition (mtd3).
- Write the new custom system image.
- Reboot.
Note: /system is squashfs as opposed to normally seen EXT4/YAFFS2.
The system image installed from our package is a copy of the original with a modified /bin/clear_crash_counter binary. This binary was modified to perform its original action as well as spawn a telnet server as root.
After the above process, the only modification to the device is done to spawn a root shell. No update mitigations are performed which means that theoretically, an update could be pushed at any moment patching our exploit. Even with that knowledge, having an internal look at the device is priceless and they hope that the community will be able to leverage this bug in time.
Downloads and instructions for exploitation can be found on their wiki at: GTVHacker Wiki: Google Chromecast
Null Pointer 