Closed Bug 863669 Opened 7 years ago Closed 2 years ago

Malware treatment in FirefoxOS

Categories

(Core Graveyard :: DOM: Apps, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: macajc, Unassigned)

References

Details

Currently there's no real way to treat malware that has been either distributed through a trusted store or through an untrusted third party site. After talking to Jonas IRL, we drafted a (very rough, just to start the argument rolling) first draft of a solution which would go as follows:

Trusted Stores:
a) Packaged apps: if a packaged app is found to be malware, then the trusted store will update the mini-manifest to add a field marking the application as malware.
b) Hosted apps: For hosted apps the trusted store will serve a black-list (for example, from a well-known URL) specifying the Manifest URLS that have been found to be malware

Untrusted third parties: 
c) For applications, both packed and unpacked, installed from untrusted third parties, the device will check upon a trusted third party which will serve (from a well-known URL?) a black-list. 

The device will identify apps as being malware, either because their update minimanifest (a) says it's malware now, or because it's identified as such by the list on either (b) or (c). That property (isMalware: true) will be exposed to Gaia as part of the mozApp API (possibly as part of the app.mgmt API so an app cannot know if it is marked as malware?). This will allow Gaia to act according to UX requirements (and mark the app somehow/inform the user).

To be clear, this bug isn't related to the UX that the user will see. It's related only to the best way to inform the platform that some apps (packaged or hosted) that it has installed are malware.
If we ping the trusted store in b) for hosted apps (that will return a list of malware manifest URLs I guess), why do we need a) for packaged apps? Or are we also replacing the application content with some "malware warning" in a) ?
Component: General → DOM: Apps
Product: Boot2Gecko → Core
Version: unspecified → Trunk
That's a good question. We will have to ping the store anyway to check for updates, so it seems like putting malware information for packaged apps in either the update-manifest or in the malware-list used for hosted apps would work. I don't know if there's an advantage to either?

Something else that needs to be clarified here. For the c) scenario in comment 0, we should both ping the store that the app came from, just like in a) and b). But we should also ping a trusted malware source.

Stores should always have the ability to mark applications installed through the store as malware since the stores reputation is on the line.

Though I guess we could enable stores to tell the device "don't check me for malware info, I'm happy to just rely on the trusted source".
(In reply to Fabrice Desré [:fabrice] from comment #1)
> If we ping the trusted store in b) for hosted apps (that will return a list
> of malware manifest URLs I guess), why do we need a) for packaged apps? Or
> are we also replacing the application content with some "malware warning" in
> a) ?

I think what Carmen was thinking about a was to reuse as much as possible of the current app update mechanism. For packaged apps no new flows would be required this way, instead the app could be marked as malware reusing the current update mechanism. It's true, though, than the mechanism described on b) can be used for both packaged and unpackaged apps. 

The main advantage of a), as I see it, is that we already have most of the pieces to implement it in place. I think the only thing required to make it work right now would be adding a new field verification on the minimanifest loading code, and some gaia code to inform the user visually of the malware installed on his device. For b) though, the changes required seem more extensive. And the risk associated, lower. So by separating both cases we can easily and quickly fix the riskier of the cases, and separately fix the other one.
(In reply to Jonas Sicking (:sicking) from comment #2)
> That's a good question. We will have to ping the store anyway to check for
> updates, so it seems like putting malware information for packaged apps in
> either the update-manifest or in the malware-list used for hosted apps would
> work. I don't know if there's an advantage to either?
> 
> Something else that needs to be clarified here. For the c) scenario in
> comment 0, we should both ping the store that the app came from, just like
> in a) and b). But we should also ping a trusted malware source.

I think the idea behind c was to cover the cases where the app wasn't downloaded from a store (trusted or untrusted) but rather it was directly downloaded from a third party site (like the app developer site, or just some compromised site), and that as such cannot be trusted to identify the apps it has served as malware. That's why a third party trusted 'reputation' server is required. Other consideration, if we allow non trusted parties to serve black lists, is that those black lists should be restricted to the content/manifest they're hosting, to avoid DoS attacks where a mallicious 'store' can mark other store content as malware.
This is also part of the FxOS Security team's malware defense strategy, I am really glad to see such detailed initiative.

From our perspective we actually need three mechanisms:

1) Using the Marketplace update mechanism for flagging malware in packaged and web apps and triggering removal.

2) Using the (planned) much broader Safe Browsing blacklist mechanism to identify and block bad URLs used in hosted/web app manifests.

3) A gonk-level mechanism tied to the update process that can identify and remove backdoors and other modifications made by malware that made it through gecko and down to the OS level.

Do we really allow sideloading packaged apps? I was assuming that you can only install hosted/web apps without going through the/a Marketplace.
(In reply to Christiane Ruetten [:cr] from comment #5)
> This is also part of the FxOS Security team's malware defense strategy, I am
> really glad to see such detailed initiative.
> 
> From our perspective we actually need three mechanisms:
> 
> 1) Using the Marketplace update mechanism for flagging malware in packaged
> and web apps and triggering removal.

Removing apps without user consent seems a bit too much to me, but that's a different discussion.

> 2) Using the (planned) much broader Safe Browsing blacklist mechanism to
> identify and block bad URLs used in hosted/web app manifests.

Is there information on that blacklist mechanism somewhere?

> Do we really allow sideloading packaged apps? I was assuming that you can
> only install hosted/web apps without going through the/a Marketplace.

You can sideload package apps using developer tools, yes.
(In reply to Fabrice Desré [:fabrice] from comment #6)

> > 1) Using the Marketplace update mechanism for flagging malware in packaged
> > and web apps and triggering removal.
> 
> Removing apps without user consent seems a bit too much to me, but that's a
> different discussion.

Oh, I wonder where this idea came from. Hopefully such actions are out of the question unless there is user consent on a per-incident basis.


> > 2) Using the (planned) much broader Safe Browsing blacklist mechanism to
> > identify and block bad URLs used in hosted/web app manifests.
> 
> Is there information on that blacklist mechanism somewhere?

I think that pauljt can provide more detail on what the integration plans are for FxOS. It basically works the same as in Chrome and other browsers which check against blacklists of URLs known to distribute malware, and we would only need to include web app manifest URIs in such a mechanism.


> > Do we really allow sideloading packaged apps? I was assuming that you can
> > only install hosted/web apps without going through the/a Marketplace.
> 
> You can sideload package apps using developer tools, yes.

Will devtools sideloading still be available in release versions? Since it is easy to create any sort of packaged apps distribution system around sideloading from the desktop, we might want to discuss the option of restricting sideloading to developer versions of FxOS. Will the release phones come with an open fastboot?

As long as sideloading won't become Android-style simple as clicking a URL and package on the device, I'd expect that jumping the devtools hoop is nothing for the vast majority of users.

What are the options to include sideloaded packages in the Marketplace update mechanism that could flag them as malware? That would also mitigate the sideloading threat.
Flags: needinfo?(ptheriault)
(In reply to Christiane Ruetten [:cr] from comment #7)

> Will devtools sideloading still be available in release versions? Since it
> is easy to create any sort of packaged apps distribution system around
> sideloading from the desktop, we might want to discuss the option of
> restricting sideloading to developer versions of FxOS. Will the release
> phones come with an open fastboot?

We don't use fastboot to sideload apps, but a remote debugging actor. I don't know of any plans to restrict that for release phones.

> As long as sideloading won't become Android-style simple as clicking a URL
> and package on the device, I'd expect that jumping the devtools hoop is
> nothing for the vast majority of users.

For privileged and certified apps, you need to connect your device to a host to sideload apps. For unprivileged apps, hosting on any web page is enough.

> What are the options to include sideloaded packages in the Marketplace
> update mechanism that could flag them as malware? That would also mitigate
> the sideloading threat.

Sideloaded apps have no known manifest url before they are installed, so we can't use the manifest URL. What we could use is the package hash, but that does not look very strong either.
(In reply to Fabrice Desré [:fabrice] from comment #8)

> We don't use fastboot to sideload apps, but a remote debugging actor. I
> don't know of any plans to restrict that for release phones.

Of course not, but this is not what I meant. I was asking because an open fastboot is required for reflashing the device with a developer version.

In fact, I have conflicting information from pauljt on the availability of the debugging actor on release phones.

So for further discussion, I feel that we need to clarify this and collect the different install and update paths for certified apps, packaged apps, and web app manifests. Is there a central documentation? Otherwise we should start it here and I'll transfer it into MDN or the wiki.
Flags: needinfo?
I don't know that it's really worth while trying to worry about malware detection of side-loaded apps before we know if that will really become a common way for people to install apps.

That said, it's quite likely that we can use the same logic for malware detection of side-loaded apps, as for apps coming through 3rd party stores. In both cases identifying a packaged app will likely have to be done by using a hash of the app package.
Flags: needinfo?
I agree that side-loading is not the major concern, yet, but as long as sideloading is easy with the majority of the user base, it is safe to assume that someone will come up with a successfull desktop host-based point-and-click workaround for Marketplace(s) via sideloading.

I maintain my request for collecting the information on which app type can be installed which way and under which conditions, and what gets queried upon installation, execution, and update. That way we can come up with a proper threat model. I have started a draft here:

https://etherpad.mozilla.org/fxosappthreatmodel
The types of applications we have are:

1) Hosted, unsigned, normal apps
2) Packaged, unsigned, normal apps
3) Packaged, signed, normal apps
4) Packaged, signed, privileged apps
5) Packaged, signed, certified apps

1 and 2 can be installed from 3rd party stores as well as directly from developers.

1, 3 and 4 can be installed through the mozilla marketplace.

5 can only come preinstalled on the device and are always updated with the device. I.e. they are always built-in on the device.

Note that signing is always done by the marketplace, not the developer. So a developer that wants to write a packaged app sends it unsigned to the marketplace, which then signs it.


Side-loading enables any combination of packaged/hosted and normal/privileged/certified. We don't check the signature on side-loaded apps, so they can be signed or unsigned.
> 1, 3 and 4 can be installed through the mozilla marketplace.

Do 3 and 4 actually differ other than requesting no or some permissions respectively? In that case it might not be worth distinguishing them here.


> Note that signing is always done by the marketplace, not the developer. So a
> developer that wants to write a packaged app sends it unsigned to the
> marketplace, which then signs it.

For the sake of simplicity it's probably alright to not consider reviewer signing in this context for now. Just making sure that it is not forgotten.


> Side-loading enables any combination of packaged/hosted and
> normal/privileged/certified. We don't check the signature on side-loaded
> apps, so they can be signed or unsigned.

Oh my. Unless restricted in the release version, sideloading will become established procedure and thus a major infection vector for FxOS malware. Android crashed down that slippery slope, too.

Possible mitigation would be per-device developer signing, on-install blacklist checks, or mentioned restriction to developer firmware – rather for any sideloading, but at least at the privileged/certified level.

Thanks for the input! I'll update the etherpad accordingly. Please, feel free to edit out my mistakes.
(In reply to Christiane Ruetten [:cr] from comment #13)
> > 1, 3 and 4 can be installed through the mozilla marketplace.
> 
> Do 3 and 4 actually differ other than requesting no or some permissions
> respectively? In that case it might not be worth distinguishing them here.

Yes. Privileged apps automatically get a CSP policy applied which has be implications regarding to the behavior of several core APIs.

https://wiki.mozilla.org/Apps/Security#Default_CSP_policy
(In reply to Christiane Ruetten [:cr] from comment #7)
> (In reply to Fabrice Desré [:fabrice] from comment #6)
> 
> I think that pauljt can provide more detail on what the integration plans
> are for FxOS. 

I think I might have given you the wrong impression here on the status of safe browsing. It exists in desktop (as Phishing Protection), but not on Firefox OS as yet (there is bug 839120, but no more than that). In any case, that is a blacklist for URLs, not a blacklist of apps. I think we need both, and this bug is about the latter not the former.

Re: side-loaded apps, I think we should have a warning about sideloading, but beyond that I agree with comment 10 - not our problem, but if we can help the user remove a bad app then we should.
Flags: needinfo?(ptheriault)
The side-loading discussion is going off topic for the the issue of malware handling, so I continued it in a new bug at https://bugzilla.mozilla.org/show_bug.cgi?id=872053 .
Product: Core → Core Graveyard
I don't think we are going to work on this anymore, closing.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.