| |||||||||||||
Linux malware: an incident and some solutionsLinux malware: an incident and some solutionsPosted Dec 30, 2009 4:25 UTC (Wed) by rickmoen (subscriber, #6943)In reply to: Linux malware: an incident and some solutions by zooko Parent article: Linux malware: an incident and some solutions
Zooko, consider the mechanics of what happened at gnome-look.org: A nameless author contributed an alleged screensaver-module file in (at least) .deb format, and the site's automated scripts accepted and listed it. His/her listing either stated or implied that the user should download and "dpkg -i" it. Putting user-system-level ACLs on what an eye-candy display for xlock is allowed to do doesn't address that particular threat model, because the attack was a social-engineering one against the user, to get him/her to install a distro package with root authority when no such access should be rationally needed just to install a screensaver. (An ACL approach such as you might discuss could help with actual screensaver files.) The author's sentence "An incident like the WaterFall malware can only be avoided when users are trained not to trust third-party software blindly" strikes me as directed towards pondering how to make social-engineering threats less likely to succeed, and I agree with the author that those are a much larger threat than lack of a capabilities-enforcement mechanism for screensavers, wallpaper, themes, etc. Rick Moen
(Log in to post comments)
Linux malware: an incident and some solutions Posted Dec 30, 2009 4:45 UTC (Wed) by zooko (subscriber, #2589) [Link]
Dear Rick Moen: that's a good point, but capability access control could appropriately constrain the installation of packages just as it could constrain the display of eye-candy. In fact, we Linux-users are actually probably much closer to Principle-Of-Least-Authority package management than to Principle-Of-Least-Authority screen savers because of the NixOS project! http://nixos.org/nixos/
Linux malware: an incident and some solutions Posted Dec 30, 2009 6:38 UTC (Wed) by rickmoen (subscriber, #6943) [Link]
I'm not sure, offhand, how capability controls on package installers would prevent granting of powers to undesired scripts within some packages while permitting them to others. E.g. it might even be the case that screensaver modules can legitimately be expected to be delivered within .deb archives sometimes, and legitimately include scripts.
Rick Moen
Linux malware: an incident and some solutions Posted Jan 4, 2010 19:08 UTC (Mon) by giraffedata (subscriber, #1954) [Link] I'm not sure, offhand, how capability controls on package installers would prevent granting of powers to undesired scripts within some packages while permitting them to others. I can see it. It's a higher level of capability control than you're thinking of. Maybe implemented in dpkg itself. You request to install a package, but say, "This installation has no business setting up something that runs every time anyone logs in." In the case at hand, I believe if dpkg failed with a message saying, "you need to give me permission to install a login script," the user wouldn't have proceeded. Indeed, that kind of constrainability of installs would help with inadvertent over-installation as well. Many times, I've had an installer helpfully configure something on my system for me -- something outside the scope of what I thought I was modifying by installing -- and later I had a devil of a time figuring out who changed it and how to change it back.
Linux malware: an incident and some solutions Posted Jan 4, 2010 21:31 UTC (Mon) by hppnq (guest, #14462) [Link] 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. ;-)
Linux malware: an incident and some solutions Posted Jan 4, 2010 23:13 UTC (Mon) by zooko (subscriber, #2589) [Link]
Suppose for example that http://gnome-look.org/ offered packages in some format where it was trivial to verify that installing the package wouldn't write any files into system script directories such as /etc/profile.d . (It is not easy -- perhaps not even possible -- to verify such things about .deb packages. Perhaps if they were Nix packages http://nixos.org/nix/ instead then it would be easy.)
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.
Linux malware: an incident and some solutions Posted Jan 4, 2010 23:19 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
the problem is in your first statement.
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.
Linux malware: an incident and some solutions Posted Jan 5, 2010 0:10 UTC (Tue) by zooko (subscriber, #2589) [Link]
That's the part that is (at least partially) solved by techniques like Nix. It is also partially solved by GNU stow. You can't give me a package which will sneakily install a script into my /etc/profile.d when I install your package using GNU stow.
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/ .)
Linux malware: an incident and some solutions Posted Jan 5, 2010 5:47 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
but it is possible to install a script that when run by root after installation will modify /etc/profile.d
|
|||||||||||||