It appears I set it as a preference once. I hadn't bothered to change it. This better? Sorry for the horrification.

I'm replying again because it occurred to me. to check the dictionary.

A backdoor is an indirect and devious system conceived for the purpose of allowing access to resources by circumventing security protections.

This is not. This is a set of IPC requests an "API" to allow the modem firmware to store non-volatile information in a specific location of the host phone's filesystem.

You're absolutely right that a backdoor is a backdoor; however, this is not a backdoor. If they'd really meant to introduce backdoors, don't you think they'd have made even a trivial effort to hide or obfuscate it? For example, D-Link's special request header “xmlset_roodkcableoj28840ybtide” that would bypass the web admin authentication. That's a backdoor. Minterpreting wrappers for read() and write() is not.

I do believe you missed the point of my comment entirely. These IPC requests for doing file I/O are there to allow the to read and write to a small subset of files constrained to a specific portion of directory hierarchy.

Yes, the modem could potentially read other files - limited by unix access controls, but it cannot read nor write from arbitrary files.

> Maybe you're right and it should be called "criminal negligence" instead.

I was growing the impression you'd authored a post with value worth contributing to the discussion until I noticed this statement. I thank you for announcing your ignorance so clearly.

Want to prevent people from destroying/modifying your IMEI using a yet-unknown-and-incredibly-unlikely-but-still-technically-possible hypothetical remote privilege escalation? Use the chmod(1) command with the argument 640 to remove the group write permissions.

Really, how is this unlike any other phone that has a cellmodem with firmware and nvram?

If you really wanted to limit what files the rild could interact with on behalf of the modem, a trivial bind mount and chroot( ) would suffice.

Unfortunately, the daemon that opens, reads, and writes files on behalf of the modem, is running as a specific unprivileged user, radio (uid 1001 on my phone.) It could only wipe out the information I have in /efs and a few specific files in /data. Nothing bars it from triggering some other system/daemon/process responsible for more thorough wiping of data.
 

It's no more a backdoor than using using static functions in your compiled C. Simply because it's not documented, does not make it a backdoor.

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.

While, yes, technically anyone can communicate with your modem; anyone can communicate with your wifi card or your bluetooth adapter as well. And it would appear that the samsung radio interface IPC layer at least has a modicum less access to the entirety of your device than your wifi driver - which is in the kernel. People have, in the past, exploited mistakes in wifi drivers and wifi card firmware to remote exploit via wifi. (*: The specific instance I remember, was with an old intel 802.11b/g card and specially crafted management frames which could be trivially spoofed and didn't need to be encrypted to be accepted by the wireless card. The proof of concept was able to issue busmaster DMA read/writes which, ostensibly, would allow rewriting arbitrary kernel ram, etc.)

Across the scope of samsung phones I was able to check (ok, two of them), the radio interface, the android host side of this communications channel, runs as uid 1001 (radio). As far as my cursory inspection revealed, meant that the radio/modem can read/write the files in /efs and only read a number of other places, such as /sdcard. Granted, /sdcard contains a lot of your personal data. My point is that, in this case, a compromised modem is still less privileged than a compromised android service or, worse, compromised driver/kernel. Also, given that these IPC instructions are used for reading/writing modem "nvram" data such as the handset IMEI, to describe them as a "backdoor" is horribly inappropriate.

So, yeah, as you said, "huge technological challenge." Agreed. But, the idea that a data modem may be exploitable is by no means new.

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?)

I always include a $20.00 and a note when I send a laptop in for repair. In the note I explain exactly what I'd like done. Always works with Lenovo.

At risk of being put online? Don't people risk exposing their license plates every time they back out of the garage?

I think the real concern is, "This just puts millions of illegally parking individuals at risk of being publicly shamed."

The best protection for any one concerned their license plate may end up online seems pretty simple and obvious: think ahead, be considerate, and don't park like an asshole.