Linux malware: an incident and some solutions
Linux malware: an incident and some solutions
Posted Jan 4, 2010 21:31 UTC (Mon) by hppnq (guest, #14462)In reply to: Linux malware: an incident and some solutions by giraffedata
Parent article: Linux malware: an incident and some solutions
The kind of attack you need to worry about is the one that is able to fool you, not so much the system. In the case of a screensaver that asks permission to run a script, some users may be able to answer correctly: no, of course not. But for a Firefox extension that rewrites a trusted link in a trusted webpage to a malicious one or opens a connection to a remote server? You are the weak link.
I think no amount of capability control will help decide, with acceptable confidence, what is trusted and what not -- not even if this would involve detection of normal usage and trust patterns -- unless the software was downloaded from a trusted site to begin with.
(I guess the problem of properly configuring a system that is exposed to uncontrolled outside input to perform a specific task is exactly as difficult as configuring it to prevent it. ;-)
Posted Jan 4, 2010 23:13 UTC (Mon)
by zooko (guest, #2589)
[Link] (3 responses)
Suppose then that the administrators of http://gnome-look.org/ ran a script which confirmed that the eye-candy packages didn't install anything other than the appropriate eye-candy plugin code. (Note that they don't need to inspect any source code themselves -- they just have a script which inspects each new package when it is uploaded to confirm that nothing gets written outside of the appropriate location for eye-candy plugins.)
Now here is my point: nobody needs to make judgments about the moral character of the authors of the plugins! This hypothetical Principle-Of-Least-Authority package management system (of which Nix may be an example or at least an ancestor), plus this hypothetical script that the owners of http://gnome-look.org/ execute automatically on all new uploads, plus this hypothetical Principle-of-Least-Authority eye-candy plugin mechanism (of which Google Native Client is an example), combine so that you can happily invite the author of this malware to go ahead and submit a whole bunch more eye-candy plugins to http://gnome-look.org/ , and millions of users can safely download his latest creations and stare at the pretty pictures.
So the point that I'm trying to emphasize here is that discerning between good guys and bad guys among the authors of the software that you rely on is *not* the only way to defend against malware.
And a good thing too, because that strategy is utterly hopeless for a large-scale software ecosystem. It is an appropriate strategy for Dunbar's-number-scaled ecosystems in which you basically know everyone involved personally and can form coherent opinions about each person's character. In other words, it was probably a great strategy for our ancestors ten thousand years ago, and that's probably why we continue to think of it as the right and natural thing to do today, even though it is utterly useless for today's situation.
Posted Jan 4, 2010 23:19 UTC (Mon)
by dlang (guest, #313)
[Link] (2 responses)
Given an arbitrary script, it is not trivial to verify that it does or doesn't access files in any particular place. In any language it is fairly easy to obfuscate the actual path that's accessed by having that path be the result of some calculation
I's not feasible to say "don't allow variables in a command" because for maintainability and readability there are a lot of very good reasons to do so.
Posted Jan 5, 2010 0:10 UTC (Tue)
by zooko (guest, #2589)
[Link] (1 responses)
The basic idea is that you don't try to figure out what the code is going to do, you instead have a separate layer that has some (simple, easily verified) policy about the consequences of what the code does when you run it. In the case of GNU stow, that simple policy is that nothing gets written to outside of /usr/local . I don't understand Nix as well, but it seems like it enforces that nothing gets written outside of "/nix/store/22bharrqlcisnwa11a5qr0xazgvv64hk-firefox-3.5b4" where the big long random string is the secure hash of the actual contents of this particular version. (I'm copying this from http://lwn.net/Articles/337677/ .)
Posted Jan 5, 2010 5:47 UTC (Tue)
by dlang (guest, #313)
[Link]
Linux malware: an incident and some solutions
Linux malware: an incident and some solutions
Linux malware: an incident and some solutions
Linux malware: an incident and some solutions