LWN: Comments on "Linux malware: an incident and some solutions"

Linux malware: an incident and some solutions

Felix_the_Mac — Thu, 07 Jan 2010 17:22:27 +0000

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)"

Linux malware: an incident and some solutions

dlang — Tue, 05 Jan 2010 05:47:54 +0000

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

zooko — Tue, 05 Jan 2010 00:10:21 +0000

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

dlang — Mon, 04 Jan 2010 23:19:38 +0000

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

zooko — Mon, 04 Jan 2010 23:13:59 +0000

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

hppnq — Mon, 04 Jan 2010 21:31:22 +0000

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

giraffedata — Mon, 04 Jan 2010 19:08:28 +0000

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

ccurtis — Thu, 31 Dec 2009 17:34:31 +0000

I wonder if package installation tools could help here. Dropping to the commandline is always an 'advanced' option, but for the unwashed masses: what if 'dpkg-gui' shipped with a set of heuristics that classified packages based on their contents and displayed this to the user at install.

In the gnome-look example, this 'dpkg-gui' could scan the file listing and display a dialog saying that (based on the various rules) the 'Waterfall' package contains:

* GTK Themes
* Desktop wallpapers
* Icons
! System configuration files
! Maintainer scripts

... with appropriate warnings about the items marked with a '!'.

The 'Maintainer scripts' type is (and always has been) a huge hole-in-the-waiting. You could scan each script looking for patterns ('/etc/', '/../') but the number of false positives (reading files versus writing) would be large - not to mention that any language could be used and the paths could be obfuscated easily.

One could argue that a user should know that a theme doesn't require these scripts, but that's really asking too much. People coming from Windows, rightly or wrongly, place some trust the installer because they can always "back out". This is not a completely unreasonable position. Given the innate "root-ness" of system packages, Linux may even be an even more vulnerable target.

Perhaps the 'Maintainer scripts' has a "Check..." option that creates a VM or a secure chroot/jail on top of a filesystem snapshot or overlay from which it can perform a delta analysis. It can then use this delta to amend the list of categories the package belongs to - perhaps highlighting new decisions in red, or disallowing them altogether.

This is an issue that will need to be addressed, and user education is not the answer. Like debugging clever code, this arms race has to be fought between the programmers themselves - not between the attackers and the "OMG Ponies" folks.

Linux malware: an incident and some solutions

paulj — Wed, 30 Dec 2009 14:02:31 +0000

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

rickmoen — Wed, 30 Dec 2009 06:38:44 +0000

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

zooko — Wed, 30 Dec 2009 04:45:32 +0000

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

rickmoen — Wed, 30 Dec 2009 04:25:11 +0000

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

dlang — Wed, 30 Dec 2009 01:56:19 +0000

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

zooko — Wed, 30 Dec 2009 01:43:42 +0000

"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.

Linux malware: an incident and some solutions

tzafrir — Sat, 26 Dec 2009 14:21:52 +0000

That's because you consider them as packagers.

NoScript and Adblock

rickmoen — Sat, 26 Dec 2009 07:48:42 +0000

Pete wrote:

http://lwn.net/Articles/332093/

{shrug} The best solution to upstream antics is the one Jake Edge mentions, distro packages, which I always strongly, strongly encourage Linux newcomers to favour over going to upstream (absent rare reasons to the contrary). But NoScript / Adblock even with upstream antics are better than lacking them. Fortunately, both extensions are open source -- as many extensions advertised on https://addons.mozilla.org/ are not.

(My view, yours for a small royalty fee and waiver of reverse-engineering rights).

Rick Moen
rick@linuxmafia.com

Linux malware: an incident and some solutions

smurf — Fri, 25 Dec 2009 18:15:43 +0000

>> It's easy for anyone with shell access to the svn server
>> to go back and change someone else's past commit

That's a SVN problem. With git, such a change would have to be propagated through the whole subsequent commit history. This would be immediately visible to anybody who re-syncs their git archive and then looks at the resulting merge tree. Not a perfect solution, but good enough; anyway, git also supports gpg-signed tags, which _are_ as perfect as one can get.

The other distributed VCSes offer similar integrity features. But then, SVN is no _distributed_ VCS.

Linux malware: an incident and some solutions

elanthis — Fri, 25 Dec 2009 06:51:13 +0000

An even better question is why screensavers are submitted as dpkgs at all. Of hmome-look
wants to use native packages for this, require them to be submitted as simplifed source balls
and build the binaries and packages themselves, using a properly jailed build environment
(or even a vm instance).

NoScript and Adblock

pflugstad — Fri, 25 Dec 2009 03:10:59 +0000

I completely agree with you. But then you went and mentioned NoScript and AdBlock:

http://lwn.net/Articles/332093/

Intentional?

Pete

Linux malware: an incident and some solutions

rickmoen — Thu, 24 Dec 2009 19:11:15 +0000

And, I forgot to mention: Firefox extensions. I note that the Mozilla Organization's https://addons.mozilla.org/ "portal" site contributes substantially to the problem of dangerous user attitudes, by having no entry about source code or licensing on any of the extension entries, but a large, prominent button marked "Download Now" on each. I've encountered Linux users who've been completely unaware that what they fetched via that site was proprietary software from nobody in particular, that they would not have trusted with their user-level security access if they'd been thinking more clearly.

I suggest we of the Linux community work harder to get out the message that, e.g., just because we recommend Adblock and NoScript, that doesn't mean we recommend downloading arbitrary extensions from any-old-where, and that, when we provide URLs to Adblock and NoScript's upstream Web sites, we don't mean you should get it from there: You should get maintained, audited packages from your distro maintainers, where available -- and assume code is dangerous unless you have reason to think it isn't.

Rick Moen
rick@linuxmafia.com

Linux malware: an incident and some solutions

cortana — Thu, 24 Dec 2009 16:34:33 +0000

dpkg --info blah.deb will display which of the preinst, postinst, prerm, postrm scripts the .deb has,
and whether they are shell scripts, perl scripts, etc.

The question I want to ask is: why on earth did gnome-look not strip out all the scripts that
submitted debs contained? There is no need for a package containing a screen saver to contain
such as script; all you have to do is drop an executable somewhere, and a .desktop file in
/usr/share/applications/screensavers!

Linux malware: an incident and some solutions

rickmoen — Thu, 24 Dec 2009 12:49:23 +0000

It's unfortunate that nearly all articles about Unix malware start by thrashing the same stupid straw man about "Linux users like to think that they are not vulnerable". Any operating system that permits the user to destroy his/her own system's security is "vulnerable" in that trivial and rather meaningless sense of the word, and Unix furnishes the rope to hang yourself, spare blocks and tackles, and a few rope factories and foundries in case you want to make more.

So, when has it ever not been the case that "they too should be careful"?

The .deb was "on gnome-look.org" in the technical sense that it was made available by its third-party author at some URL of the form http://gnome-look.org/CONTENT/content- files/[something].deb, but even a cursory look at the site should have revealed to any member of the public that the site maintainers do effectively zero quality control, that it's an automated "portal" where "Everyone can upload and download artwork, applications, documents and other files."

So, it should have been obvious that the downloaded file was from nobody in particular, for starters -- but then there's the fact that it's a .deb, which requires root/sudo to install, and inherently supports preinst/postinst scripts, run as root.

None of which in the least differs from Koen Vervloesem's point that "An incident like the WaterFall malware can only be avoided when users are trained not to trust third-party software blindly", which is well taken, but there's only so much that can be done to dissuade novice sysadmins from destroying their systems. If they're willing to install as the root user software from unknown parties on the Internet just so they can have "the newest screen savers, themes, and other software to spice up their desktop", the best you can do is gently point them to the CERT document on recovery from root compromise and say "Gosh, it hurts when you shoot at your own foot, doesn't it?"

Even with "more software than the official repositories have", if it's not alleged screensavers, it'll be alleged Internet poker games, alleged video codecs for porn, alleged "birthday cards", etc. -- or various and sundry add-on Web apps.

The only way out is to keep reminding users they're responsible for whom they trust and what processes they run, teach them not to aim that gun at their feet, and teach them how to recognise that type of foot wound and how it got there.

Rick Moen
rick@linuxmafia.com

Linux malware: an incident and some solutions

tzafrir — Thu, 24 Dec 2009 12:25:27 +0000

Just one comment regarding the dpkg command in the article: it lists the contents of a package. That, however, omits one very obvious place to hide malicious (or, well, buggy) code: the maintainer scripts.

I'm not aware of a simple dpkg equivalent of the command 'rpm -q --scripts foo.rpm', but it should be along the lines of:

dpkg --info foo.deb config preinst postinst prerm postrm