GitLab

Tasks needed for hardening device

General Risks:

The device we are using is a $100 consumer grade DIY board that is popular for building media tv boxes. If we are giving the device out for free and we are not securing it, then it is likely that word will get out that they are a hackable opportunity with a $100 profit margin.

Security Impactors:

root access

User debug enables root access by default. With root access, all apk source is inspectable by anyone with minimal Android dev background and tools. All data is accessible, with the exception of data secured with keys from keystore. FW applications may be recompiled and replaced, but permissions will not be correct due to signature mismatches.

ADB Access

Adb access is possible through the ethernet and wifi ports and full flashing is possible through the USB power cable. In Userdebug mode, root access is enabled through the inclusion of su, the superuser binary. All application source and data is reviewable. User applications can be recompiled, but will not have access to the system bridge due to signature mismatch. With a full factory reset and a complete complement of recompiled apps, a skilled, highly motivated developer could create a working mutation.

Data Partition access

• FW apps are stored on read only partitions that are not encrypted, but are protected by permissions.
• Data may be stored in eMMC flash memory on the user data and cache partitions.
• Data may also be stored on the SD card as internal or external storage.
  • If the SD card is formatted as internal storage, it will be treated as an extension of the user data partition. If the SD card is corrupted or removed the device will fail to boot.
  • if the SD card is formatted as external storage, it will be treated as a removable SD card would be treated.
  • If encryption is enabled, the internal storage will be encrypted, external stg will not.
  • External storage will be easily viewable to hackers, regardless of encryption
  • internal storage will be protected.
  • internal storage will be vulnerable to corruption cause by rebooting in the middle of write operations. Because the system include a power switch on the power cable, this form of corruption is significantly more likely.

Full Disk encryption prevents the ability of a hacker to make a raw copy of the entire filesystem and mount it on another linux system for inspection. It only affects data that would be stored on the user data partition.

If the user data and system partitions are able to be mounted externally and inspected, it would function similar to root access impacts for a skilled dev with both linux and android experience.

Hardening tasks, impacts and effort:

User mode build

Effort: mostly done**

• compile device in user mode, which requires SELinux to run in enforcing mode. Requires updates to device policies and QA/testing to resolve any permission denials that block feature enablements.
• this will eliminated uncontrolled access to ADB via ethernet and wifi.

Enable Trust.img, Verified boot and recovery image locking

Effort: 1-2 months** These processes are not well documented, so the effort is not predictable. The goal would be to establish a trust chain from recovery through system boot.

• eliminates the ability to flash alternate firmware. Image flashing is restricted to firmware images that are signed/generated by platform builds.

Full Disk Encryption

Effort: 1-2 weeks** FDE is functional with a minimal level of testing. The only part that is NOT functional is the ability to update firmware in place (without a factory reset). Low-level C code in recovery and complementing code in Java must be rewritten to enable firmware updates to be stored on encrypted drives. If FDE is enabled without this support, the time required to test firmware enhancements or bug fixes will be slowed down significantly. 1 dev cycle goes from 10mins(w/no state loss) to 45 mins(w/full state loss).