Forgot your password?
typodupeerror
Android Cellphones Operating Systems Security

Replicant OS Developers Find Backdoor In Samsung Galaxy Devices 126

Posted by Soulskill
from the caught-out dept.
An anonymous reader writes "Developers of the Free Software Foundation-endorsed Replicant OS have uncovered a backdoor through Android on Samsung Galaxy devices and the Nexus S. The research indicates the proprietary Android versions have a blob handling communication with the modem using Samsung's IPC protocol and in turn there's a set of commands that allow the modem to do remote I/O operations on the phone's storage. Replicant's open-source version of Android does away with the Samsung library to fend off the potential backdoor issue."
This discussion has been archived. No new comments can be posted.

Replicant OS Developers Find Backdoor In Samsung Galaxy Devices

Comments Filter:
  • Re:OTA updates (Score:5, Interesting)

    by dos1 (2950945) on Wednesday March 12, 2014 @06:39PM (#46469195)

    This is part of their undocumented protocol for communication with the modem. Modem can ask to read or write some file on disk using IPC_RFS_READ_FILE, IPC_RFS_WRITE_FILE, IPC_RFS_LSEEK_FILE, IPC_RFS_CLOSE_FILE, etc. messages and the library will happily do that for the modem. It's hardly unintended.

  • Re:OTA updates (Score:3, Interesting)

    by Anonymous Coward on Wednesday March 12, 2014 @07:01PM (#46469335)

    Or anyone who sets up a fake tower? That's a pretty common and relatively easy attack vector now...

  • Re:OTA updates (Score:5, Interesting)

    by megabeck42 (45659) on Wednesday March 12, 2014 @08:03PM (#46469717)

    I couldn't agree more. There is no evidence to suggest that it's a malicious backdoor.

    A quick strings on my samsung captivate glide's modem firmware, reveals all manner of novel debug messages and log strings:

    err/CP_MA_TRACE_%d_%04d%02d%02d%02d%02d%02d.bin
    [DUMP] FILE OPEN FAIL
    [ERROR]%s,%d,%s
    [DUMP] FILE CREATE FAIL
    [DUMP] Write MA Trace To /data/efs/err =====
    aurrcbp: discard cell due to system information read error
    [Net]NV Read Fail! OEM_NVM_TESTBED

    etc..

    I do know that a lot of data persistence for the radio is done with dotfiles scattered around and throughout /data and /efs (because real nvram is expensive).

    I'm curious what functionality is affected, if any is, by rejecting any of these IPC_RFS_ I/O.

    I don't think it's clearly a backdoor. But, I do believe the concern is warranted. The radio/modem's firmware blob is not auditable. Perhaps a combination of logging/auditing filesystem requests and limiting which files are accessible by the RILD? Actually, isn't the rild run as an unprivileged user, radio? (Possibly for this very reason?)

  • by TheGavster (774657) on Wednesday March 12, 2014 @09:16PM (#46470139) Homepage

    Does anyone do verification on the "airplane mode" setting of phones? The FCC and FAA seem to have come to the conclusion that there's no way you can detect active radios via undesired behavior of an aircraft, and are down to sorting out the social ramifications of phone use on planes. I'd like to see an independent (and preferably paranoid) lab check to make sure that "all radios off" means that the radios are off, and not just that they stop passing traffic from the PDA OS.

  • by ShaunC (203807) on Wednesday March 12, 2014 @09:53PM (#46470301)

    Two things, "Even Ham radio operators?" When did they become the retards of the RF world - I thought that title belonged to CB'ers? Honestly, hams are not interested in your phone.

    He wasn't calling hams retards, quite the contrary. He was pointing out that people with absolutely no control over your cellular carrier's towers, and thus no legitimate path into your cellphone, could give you problems despite not being an "authorized" party. Those people would still need to be extremely technically adept, familiar with radio, etc. so hams was a pretty good example IMO.

"Never give in. Never give in. Never. Never. Never." -- Winston Churchill

Working...