About Root de la Vega

A rooting exploit of the Samsung GALAXY Note 3 was recently posted online. Named after AT&T Mobility President and CEO, Ralph de la Vega, this rooting exploit leverages a hashing vulnerability when booting into ODIN download mode, which leaves some modifications of the system.img undetected during signature verification. 
The exploit flashes a modified system.img to the target device using the ODIN download tool. Due to the hashing vulnerability, the modified system.img may be accepted and then it replaces the original system partition on the target device. More specifically, this rooting exploit modifies a high-privileged start-up script to further invoke an attack script on the SD card, which remounts the /system partition to be writable and copies a rootkit to the /system partition.
Unlike CF-Auto-Root, Root de la Vega poses a threat to the integrity of KNOX-enabled devices. Due to the hashing vulnerability, the rooting exploit can bypass the rooting detection mechanism. As a result, the rooting will go undetected and the KNOX bit will not be burned. In other words, if an attacker has physical access to a KNOX device, they can use the Root de la Vega technique to flash a modified system.img to it. This modified system.img can then be used as a springboard for further attacks that threaten the integrity of vital components of the device’s software stack. For example, system services can be changed and new malicious apps installed without being detected by KNOX.
Samsung has fixed the hashing vulnerability, and security patches are being rolled out for all vulnerable models. This security patch also includes a roll-back prevention feature so that a patched device can no longer be brought back to the vulnerable state. In addition, Samsung GALAXY Note 3 devices offer remote attestation, another defense against such rooting exploits. 
During the Trusted Boot process, each GALAXY Note 3 collects the measurements of boot loaders and the kernel image through the TrustZone secure world. In applications with high security requirements, a remote server (e.g. an MDM or attestation server) can perform remote attestation with the target device, during which the TrustZone attestation app on the device will collect, sign, and transmit the measurements back to the server. The remote server can verify whether the vulnerable boot loaders and/or the kernel run on the target device and then make security decisions (e.g. refuse to create a KNOX Container or remove sensitive data from the device).