Closed Bug 751048 Opened 13 years ago Closed 12 years ago

[Security Review] USB storage device support

Categories

(mozilla.org :: Security Assurance, task, P1)

x86
macOS

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: pauljt, Assigned: pauljt)

References

()

Details

Tracking bug for security review of 737153
Assignee: nobody → ptheriault
This is actually very close to bug 744542 - I'm leaving them separate for now, but maybe these reviews can be merged. The bug that this blocks relates to the auto-mounting of USB devices and headphone support. Security threats are probably limited to physical access (e.g. plugging the phone into a malicious host) - I can't think of any threats via the headphone jack. Assumptions: Connecting a phone via USB allow access to the sdcard will allow complete access to the contents of the phones internal sdcard. Question: Is there a way to disable USB mounting? (e.g. a setting to enable usb access) Seems to be yes from https://wiki.mozilla.org/B2G/Meeting/2012-04-03 but need to confirm. Is this off by default?
Whiteboard: [pending secreview][start mm/dd/yyyy][target mm/dd/yyyy] → [pending secreview][2012/05/08][target mm/dd/yyyy]
As currently coded, automounting is enabled. The intention is that there will be an option. I've written up the automounter side of the code once I get an actual option name.
Ok thanks. From a security perspective I think this would be better if this is disabled by default. But this might not be a good user experience? My main concern is when you lose your phone: you have passcode lock but if the phone is plugged in maybe all your data can be stolen regardless of the code lock. (sure a determined attacker probably can get the data anyway but it would be nice to make it more difficult). What data can be accessed when the phone is plugged in like this? On reflection - I think other phones provide full access to photos, music etc once the device is plugged in so maybe enabled by default is needed for a parity approach. We should at least make this decision consciously though, and document the risk.
(In reply to Paul Theriault [:pauljt] from comment #4) > Ok thanks. From a security perspective I think this would be better if this > is disabled by default. But this might not be a good user experience? My > main concern is when you lose your phone: you have passcode lock but if the > phone is plugged in maybe all your data can be stolen regardless of the code > lock. (sure a determined attacker probably can get the data anyway but it > would be nice to make it more difficult). It certainly makes sense to me to have the data not be accessible if the phone is locked (regardless of whether automounting is enabled or not). We could easily make the phone being locked be an additional gate on whether access is allowed. All I really need is a way to query (from C++) whether the phone is currently locked, and an event every time the locked status changes. > What data can be accessed when the phone is plugged in like this? Whatever is present in the sdcard partition. > On reflection - I think other phones provide full access to photos, music > etc once the device is plugged in so maybe enabled by default is needed for > a parity approach. We should at least make this decision consciously though, > and document the risk. You can power the phone off and put it into download mode, and then you've complete access to everything on the phone (not just the sdcard, but complete access to all of the data), although this is not something you typical user would know how to do. The only way to prevent this is to encrypt the data that's stored in the flash.
If we could make the phone being unlocked a requirement for connection that would be good. I can't think of any other security concerns, but I'll document this, and run it past the rest of the security team to make sure. We may want to do some code review/fuzz testing, but since physical access is equivalent to compromise as you point out, I am not sure of the value of performing this sort of testing.
Whiteboard: [pending secreview][2012/05/08][target mm/dd/yyyy] → [pending secreview][2012/05/08][target 14/05/2012]
Priority: -- → P1
Depends on: 755357
Update: trying to confirm USB not mounted when phone is locked. https://github.com/mozilla-b2g/gaia/pull/1467 appears to implement the required functionality but not sure if the lockscreen actually sets the required settings yet.
I tested it again today and it works properly for me on the sgs2 (the only phone I have)
USM is disabled when locked, which was the only outstanding item from the security review so I am closing it now. For future reference, see this page which explains the settings in detail: https://wiki.mozilla.org/B2G/USBMassStorage
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [pending secreview][2012/05/08][target 14/05/2012]
Sorry for bringing up an old issue. I was just using my phone today to get some pictures off it, and I realized that it's not intuitive for the user to have to enable Mass Storage before using it. My primary concerns are: 1. In our target markets, people are used to connecting their device to a computer to transfer files, so this is a scenario they will face often. 2. Most users will expect USB mass storage to work out of the box without additional settings changes, because this is how many devices behave. 3. Currently, the setting for enabling mass storage is hidden in "Media Storage". I don't think that's a very intuitive place for people to look for it. I understand the concerns about having someone else steal your files. I think that preventing access to storage when the device is locked is an effective strategy for addressing this, regardless of whether the setting is enabled or disabled. What I'm asking for is: If we have mitigated the security risk by preventing access to storage when the device is locked, can we change the USB mass storage setting to be enabled by default?
Flags: needinfo?(ptheriault)
From a security perspective, so long as automounting is disabled when the device is locked, that addresses the main security risk. This is the case at the moment so I dont see any issue with enabling the USB Mass Storage Setting by default.
Flags: needinfo?(ptheriault)
You need to log in before you can comment on or make changes to this bug.