March 13, 2014 By: Will Verduzco
Earlier today, we talked about how the Replicant team found a potential backdoor in Samsung’s proprietary radio software. As demonstrated in a proof-of-concept attack, this allowed certain baseband code to gain access to a device’s storage under a specific set of circumstances. But upon closer inspection, this backdoor is most likely not as bad as it was initially made out to be.
A few hours after posting our previous article on the alleged backdoor, a highly respected security expert who wishes to remain anonymous approached us, stating that the way in which the proof-of-concept attack was framed by the Replicant team was a bit misleading. Essentially, it boils down to the POC requiring a modified firmware with with security features disabled. Thus, if a user is running an updated version of the official firmware, this attack will not work. To that end, the Replicant team even states in their write-up that SELinux would considerably restrict the potential files that the modem can access, such as those on the /sdcard partition.
Now, another highly trusted security researcher (XDA Recognized Developer djrbliss) has gone on record with Ars, stating that there’s “virtually no evidence” that this is indeed a true backdoor, although his reasons are a bit different. There is absolutely no indication at this time that the baseband file access can be controlled remotely. Rather, this is only a “possibility,” since the baseband software is proprietary. Instead, it’s far more likely that this was only ever intended to write radio diagnostic files to the /efs/root directory, as that is is the radio user’s home directory.
In summary, we shouldn’t rush to replace our Samsung phones just yet. There is absolutely no evidence to state that this can be controlled remotely. And even if it were possible, using SELinux, which is set to Enforcing in stock firmware, would restrict the radio user’s access.
March 13, 2014 By: Will Verduzco
You may recall that about five months ago, we touched upon a study demonstrating how OEM modifications are the primary cause for most “Android” security issues. Unfortunately, we offer yet another example of OEM-caused security issues—but this time, it’s not because of an OEM skin or bloatware. Rather, this is a potential vulnerability at a far deeper level: proprietary modem software.
The OEM in question is none other than Samsung, the Android ecosystem’s largest and most successful device manufacturer, and the backdoor itself comes as proprietary radio software. This software is responsible for communicating with the modem hardware, and is capable of implementing RFS commands. These RFS commands are then able to perform I/O operations on the device’s storage.
No big deal, right? I’ll just load CyanogenMod and be done with it. Wrong.
Since the cause is a proprietary radio software, changing to an aftermarket ROM will not solve anything, so long as the ROM uses Samsung’s proprietary blobs. In fact, the Replicant team used Galaxy Note II and Galaxy S III devices running CM10.1 to demonstrate how this was ROM-agnostic.
Currently the list of known affected devices includes the Galaxy S, Galaxy S II, Galaxy Note, Galaxy Tab 2, Galaxy S III, and Galaxy Note II, but it’s highly likely that many other Samsung devices are vulnerable. Furthermore, this also seems to affect the Samsung-built Google Nexus S and Galaxy Nexus, as this is a back door at the radio software level, rather than as a part of an OEM skin. Whatsmore, on certain devices, this incriminated process runs as root.
While it is entirely possible that there is a legitimate reason for this backdoor, it’s hard to envision a scenario where one would be necessary. As such, it would be great to hear Samsung’s official statement on the matter. Until then, perhaps it would be a good idea to look into fully open source projects like Replicant, or at the very least, building an aftermarket kernel capable of blocking (and logging) RFS command requests.
You can learn more by heading over to the source link below.