User: Password:
|
|
Subscribe / Log in / New account

Linux malware: an incident and some solutions

Linux malware: an incident and some solutions

Posted Dec 30, 2009 1:43 UTC (Wed) by zooko (guest, #2589)
Parent article: Linux malware: an incident and some solutions

"An incident like the WaterFall malware can only be avoided when users are trained not to trust
third-party software blindly."

Argh. This is not the only possible solution! It makes me sad that the linux community assumes
that discriminating among sources of software is the only solution. That solution doesn't scale,
nor does it work even at the scale of software production and software use that we already have.

The "other solution" -- the one that most people seem to find inconceivable -- is *don't give it
permission to do things that it doesn't need to do*. An eye-candy display for xlock doesn't need
to do anything other than generate pretty patterns on the screen. If that is all that it is able to
do, then it doesn't matter if you download your eye-candy from http://eyecandy.suspicious.ru or
if you receive it in email from linus@kernel.org.

Now implementing an access control mechanism that could enforce this while being usable is a
hard job (it would require capability access control instead of the access control lists that we
have now). But at least it is possible to solve the problem that way, unlike the "discriminate
among sources of software" way, which will never work unless we cut down the number of
contributors of open source software to a couple of hundred total programmers world-wide.


(Log in to post comments)

Linux malware: an incident and some solutions

Posted Dec 30, 2009 1:56 UTC (Wed) by dlang (subscriber, #313) [Link]

does a screensaver need to be able to accept (or detect) input from the keyboard and/or mouse?

if so, then it is no longer good enough to lock things down as you describe, because the screensaver could pop up a image that looks like your desktop. with no other access it becomes a simple DOS (as opposed to a full trojan) but it would still be a nasty issue to troubleshoot.

and if it isn't allowed to accept input, how can you have a locking screensaver?

back in the c64 days I would do something similar. I could walk up to a machine on display in the store and a minute or so later walk away with the display looking the same (complete with the cursor moving), but anything you typed just responded with 'OK'

on a display machine that just needed a (fast) power cycle to get back to normal, this was a prank. as a 1% of the time I cause you to loose all open files because the the screensaver takes over and makes it look like your box is dead it becomes more significant.

Linux malware: an incident and some solutions

Posted Dec 30, 2009 14:02 UTC (Wed) by paulj (subscriber, #341) [Link]

The screensaver framework can handle keyboard input and locking. The only thing the
untrusted part needs access to is a drawing API to the window on which the screensaver
should appear.

Linux malware: an incident and some solutions

Posted Dec 30, 2009 4:25 UTC (Wed) by rickmoen (subscriber, #6943) [Link]

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
rick@linuxmafia.com

Linux malware: an incident and some solutions

Posted Dec 30, 2009 4:45 UTC (Wed) by zooko (guest, #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
rick@linuxmafia.com

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 (guest, #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 (subscriber, #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 (guest, #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 (subscriber, #313) [Link]

but it is possible to install a script that when run by root after installation will modify /etc/profile.d

Linux malware: an incident and some solutions

Posted Jan 7, 2010 17:22 UTC (Thu) by Felix_the_Mac (guest, #32242) [Link]

It should also be possible to say when installing a package:

Allow NO network access
Allow only local subnet
Allow Internet access

And the required level could be 'hinted' in the installer so that the user would be prompted

"OpenOffice requests full network access? Is this OK? (Remember most programs do not need full network access)"


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds