Approaches to Malware in Software Ecosystems

Today, any software ecosystem, whether it’s software for an OS, addons for a browser, or apps for a phone, has to consider the possibility of malware.

If one wants to deal with the problem of malware, I see the following solutions:

  1. Have a single point of software distribution for your platform that you control, e.g. the Apple App Store for iOS. This does not entirely eliminate the possibility of malware, but does make it less likely, and does enable you to take quick action when it’s discovered. Depending on the policies and entry requirements of such a distribution point, of course, this may lead to unacceptable restrictions on user or developer freedom.
  2. Have software which attempts to detect and stop malware, e.g. virus scanners. This puts you into an arms race with the malware authors, who come up with amazing things like self-modifying polymorphic code. And they will write code to disable or work around your code. There are a lot more of them than you, and they can make a lot of money if they succeed.
  3. Have a reputation system, e.g. by requiring all code to be signed by the developer or a reviewer, and have a blacklist of “bad developers” or bad/stolen signing keys. This gives developers a key management problem, and also potentially the expense and hassle of obtaining a identifying certificate.
  4. Rely on your users to be smart, and hope that people don’t fall for the enticements to download the malware. This approach is the one taken by Ubuntu – even though anyone could make a .deb of malware and start to promote it via spam or compromised websites, it’s very rare. I suggest that this is due to the smaller and better-informed market which uses Linux, and perhaps a diversity of processors meaning that compiled code doesn’t run everywhere.

Unless I’ve missed one (tell me :-), any other solution will be a hybrid of components of the above. For example, on Android, there is by default a single point of software distribution for a given Android device (the Android Market or another vendor’s market), but you can check a preference to allow the installation of non-Market applications and, when you do, it’s up to you to avoid installing something malicious. (Let’s leave CarrierIQ out of the discussion for now!) So that’s a hybrid of 1 and 4.

Question for discussion: which solution is best for Firefox add-ons?

Currently, although there is a website for downloading addons, we allow non-AMO addons with just an “are you sure” prompt to prevent nagware. We do have the capability for code signing, but no-one uses it, and no-one notices whether anyone is using it, because there are no significant penalties for not using it. So it seems to me like we are effectively using solution 4.

16 thoughts on “Approaches to Malware in Software Ecosystems

  1. You have to first also consider the threat model: do all malware authors actually want to write malware for you? In case of Ubuntu, for example, I claim that the real reason is that its just not worth the investment.

    In the case of Firefox, how many actual attempts at malware have you seen? I think the best option is to have all 4 ready and turn them on when/if you start noticing actual attacks in the wild targeting a significant chunk of users.

    Also, 1+2 can be significantly more powerful than anti-virus tools: polymorphic code can be detected; its the false positives that kill, but in 1. you can just dictate policy to say “your code should not do any obfuscation at all”

  2. To me, the description you give for (3) does not match a “reputation system”, but instead sounds like a description of code signing, which could be part of the implementation of a distributed reputation system, but could also be part of a distributed form of (1), so it is kind of orthogonal.

    You could view No-Script as a version of (2) with a (non-centralized) white-list instead of a black-list (depending on how you configure it).

    Some kind of “permission system” (as i think android have?) where the app have to ask for an have the permission granted upfront, would be a implementation of (4) I guess. The trick seems to find the right level.

    So perhaps your 4 categories could be described by who decides and if it is a black- or white-list, i.e. (1) platform-owner/white-list, (2) third-party/black-list, (3) platform-owner/black-list, (4) user/white-list.

  3. You are right that what I describe is the technical basis for a reputation system (you have to be able to strongly associate reputations with code), not the whole system. 1) also implies some sort of reputation system, in that the store owner can revoke your account. But reputation (e.g. “5 stars”) in a store is more about consumer choice than about malware prevention.

    No-Script is sort-of 2, although it solves a different problem – JS is supposed to be sandboxed anyway! It doesn’t attempt to determine what JS code is malicious and what is not, it just gives you finer control over what runs without asking you.

    I think the Android permissions system sort of fits into this space, but (as roc and others have written) it’s not awesome because very few people understand the permissions they are granting. How many Android users have refused to install an app because it asked for overly-generous permissions? Less than 1%, I’m sure. (I think I have, once, maybe.) And if the developer has a plausible story (“I need to access your contacts in my SuperContactManager app, of course!”) then who is going to refuse if they’ve already decided to install the software?

    Your final categorization is interesting, though :-)

  4. As the earlier comment says, you first need to consider why people would bother to write malware to run as a Firefox add-on. If by exploiting a flaw in Firefox (or a plugin) or using a bit of social engineering, it is just as easy, or easier, to run the malware natively on the OS that Firefox is running on, malware within Firefox is unlikely to be a significant problem. So solution 4 is good enough. Maybe boot-to-gecko changes that…

  5. People might write malware as a Firefox addon because if you are inside the browser it’s easier to e.g. steal a user’s passwords or login cookies and (ab)use their various online accounts – anything from email to Facebook to their bank.

    • For some reason I just got all the comments from the RSS at once (maybe Google Reader rather than on the blog side…)

      “if you are inside the browser it’s easier to e.g. steal a user’s passwords or login cookies”

      Is it? I’m not an expert, but I don’t see why it would be easier to run your malware inside the browser, rather than just sending the passwords/cookies elsewhere and using your own code to read them. The only problem would be with something like a cookie that was tied to a particular IP, but I don’t think that’s a common scenario – stealing a password and using it to log in is much easier.

      • Sending them from where? From inside the browser it’s easier to lay hands on them. Then your malware extension, once it has them, can use them itself or send them anywhere.

        • Either sending the SQLite file with the passwords in it, reading passwords out of the SQLite file, or recording keystrokes. Once you can run code on the user’s machine, I would have thought doing any of those directly would be more straightforward than doing things within the browser. (Although a master password would help, but such a tiny number of people use a master password that it wouldn’t matter…).

  6. Another option is to employ an object capability model with proven[1] security features like full separation of objects. On top of that, you could develop a tiered system of capabilities the user can grant to applications.

    To work around alert fatigue, maybe a set of basic capabilities could be automatically granted, whereas more invasive capabilities that most apps/ addons shouldn’t normally need require explicit consent or maybe even signed code.

    Unfortunately, I don’t think anyone has come up with a good answer to the question of how (and how much) to involve the user into this process. To little involvement à la solution 1 is a real problem for free speech and hinders competition and innovation, whereas too much (or the wrong kind of) it makes the system self-defeating by making the user agree to everything.

    Systems that (to varying degrees) go in this direction are SELinux[2], HP Polaris[3], Android[4] and, probably most interesting, Caja[5]

    [1]: As proofs down to the CPU are unrealistic, these features can only be proven inside the engine, but that should at least get you on par with solution 1 and maybe 3 as those rely on the system being able to defend against circumvention of security measures, too.

    [2]: http://en.wikipedia.org/wiki/Security-Enhanced_Linux
    [3]: http://www.hpl.hp.com/personal/Alan_Karp/polaris/index.html
    [4]: http://permalink.gmane.org/gmane.comp.capabilities.general/12543
    [5]: http://code.google.com/p/google-caja/

  7. I would suggest that “develop[ing] a tiered system of capabilities the user can grant to applications” is just another variant of 4 – expecting your users to be smart :-) “Automatically granting basic capabilities” just means that they aren’t capabilities at all – they are platform features. This doesn’t help with alert fatigue; pretty much every app needs some capability that could be abused in the wrong hands.

  8. «We do have the capability for code signing, but no-one uses it, and no-one notices whether anyone is using it, because there are no significant penalties for not using it.»

    Isn’t there the penalty that without code signing, an add-on not hosted at AMO can normally not implement automatic updates? I know, automatically updated extensions outside AMO are still few and far between, and essentially, once an add-on user starts shopping off AMO, (s)he’d better know whom to trust and whom not to. I’d say that the Toolkit add-ons subsystem is also a mixture of (1) and (4): AMO is a central distribution point, with strict entry criteria, review of everything that gets in by (supposedly) expert people, and then there are all the off-AMO add-ons, some of them very good, but the user had better be smart and know (by reputation and word of mouth, maybe, or by the author’s standing in the Mozilla community) which authors can be trusted. Which brings us to (3) (a reputation system) but not necessarily with keys. Option (2) doesn’t seem very heavily used… wait… isn’t there a sort of blacklisting system for known misbehaving add-ons? Or is that plug-ins (which are a totally different kind of beast, not XPIs at all, but executable libraries in a format dating back IIRC to pre-Mozilla Netscape, and which can be shared with all other major browsers except IE)?

    So it seems that Toolkit extensions use all four options as circumstances require, which IMHO is the way to go. Is the ranking 1-4-3-2 the ideal one? I don’t know, but if it isn’t, we (stiill) have the ability to modulate our efforts in any other direction.

  9. One thing pointed out to me after I wrote my post (which I had heard before but forgot) is that fine-grained permissions manifests can help with all of options 1, 2, 3 and 4 because the manifest gives you an upper bound on what the code can do, which is very useful information for anyone or anything evaluating the code.

  10. the best is the android model, but implemented better. For example 1) is very useful but you always have to give the alternative way to install, and like android to have a “hidden” option is the best way. Also permissions are very useful but they’re poorly implemented. You need to have permission to know if there’s an incoming call and the same permission give you also the ability to retrieve the ID of the phone. But internet doesn’t need permission… They should also be optional and possibly at runtime. So if I think the train app doesn’t require my authentication key to fb I remove that permission and the app shouldn’t crash.
    And for addons with javascript, you can’t use polymorphic code, right? So a simple blacklist or an heuristic wouldn’t be so bad

  11. People might write malware as a Firefox addon because if you are inside the browser it’s easier to e.g. steal a user’s passwords or login cookies and (ab)use their various online accounts – anything from email to Facebook to their bank.

    My view is that currently getting malware on to the computer is easy, and after that it is trivial for the malware to install a firefox addon. Not really much you guys can do about it.

    Again, this is based on my model of the threat which is probably wrong. Goes back to my first comment: is malware addons really a problem? Once you have the data, we can drive better results.

  12. Seems like Firefox uses a mix as well; AMO is preferred (and has advantages over non-AMO distribution, e.g. placement in the UI for searches), but largely trusts the user to be smart about things. There’s also a blacklist (updated every so often, sadly the commit-to-hg never actually says what addon is blocked, you just get a diff with a em:id…), which is sort-of-like 3) and probably mostly guards against out-of-band installs such as when the machine is already compromised.

    But really, since side-loading will (hopefully) continue to be supported, I think it’s important to distinguish installed-from-Firefox and installed-from-system – those are two different issues and reactions should be different though overlapping.

  13. You’ve got the basic options (which are not all equally effective, but you knew that), but you may have missed that it’s also possible to use a hybrid approach. Debian, for example, uses a sort of Apple-store-like (very loosely, but the principle of control is there) model for the official repositories. The user can of course install anything they want, but the _easy_ way to install things, the one that doesn’t require any real know-how, is to use the official repository. Installing from the official repository is dead simple: 1. Type the name of the thing you want, or a word related to what it does, in the search box. 2. In the search results, tick the checkbox for the one that you want to install. 3. Hit the apply button, and Bob is your uncle. That’s it. You don’t even have to log out and back in afterward.

    Users who want to use alternative repositories (e.g., the Opera one) have to be informed enough (or sufficiently willing to learn and follow complicated steps) to edit /etc/apt/sources.lst, which neatly excludes most of the people who would be easily enticed to install random malware. Users who want to install things that aren’t in repositories at all require even more know-how.

    The computer my family uses runs Debian. Sometimes they try to install unnecessary and undesirable things on their own, but they get as far as downloading it and then don’t know what to do and stop and wait for help. Double-clicking such a file in the download list doesn’t do anything.

    To some people that sounds user-unfriendly. Maybe we need a new term, then: system-administrator-friendly. Software installation is inherently a system administration function, after all.