Re: A deb package claiming to be a screensaver is malicious
Posted: Sun Jan 03, 2010 4:06 am
I'm reasonably well-informed that in this case it wasn't a virus but a trojan, fortunately - it didn't seem to have any way of self-replicating. It was an example of social engineering in that the kiddie used a well-known and reasonably trusted site to spread the malware. I have seen at least one other (legitimate) screen saver distributed as a .deb on that site, and even where sources are provided afaik you still need root permissions to "make install" or copy the contents of the package to wherever in /usr/share/ (I'm sure it can be worked around to avoid system-wide installs but most of the time the instructions for any screensaver offered there involve "becoming root" at some point).
Bottom line is that too much of the time sudo is skipped as a sort of chore rather than a warning from the system - who here actually does check what gDebi has to say or opens a package to look at it before entering the passphrase? I also know that on occasion I've thought for all of three seconds before deciding that importing a GPG key was too much of a chore, for example. Shame on me.
Unfortunately I agree with posters above who point out that the bug lies behind the keyboard in this case. Make sudo more restrictive (e.g. make your default user not a sudoer) and making system changes, even regular updates, becomes tiresome; keep it as it is and less experienced / more lazy users will fall victim to giving their root password to what amounts to a perfect stranger without checking what they are doing first. Same goes with putting in code found in forums or blogs. One doesn't even need root privileges to hose ones data. rm -rf tilde is a really scary set of characters - ideally users would chmod their data to make it read-only by default but I don't know of anyone who actually does this (except me very recently). I don't know much about SE Linux or hardened kernels, but I wonder if as time goes on the whole reliance on permissions as the primary defence against accidents or malicious acts will fade away and predefined security contexts will take over.
What I'm wondering is why does a user need to enter a root password to update their system? The PGP-key check is relied on to check the source is kosher anyway, the user has already defined what to update and what to leave alone (in theory ), or left it to the skilled developers. So why this final check? Who actually doesn't just enter their root password, perhaps scroll through the list and click "OK get on with it", and why should they do any more? And yet, it's this kind of routine work which reinforces the bad notion that entering the root password is just part of a chore rather than a warning to be taken seriously. Thus, permissions should be more context specific - updates should require root password to reconfigure them (change sources or whatnot), but to simply keep the system up to date the process shouldn't need the user's constant reassurance. And so on. Why does one need root permissions to pop some pixmaps in /usr/share ? That's crazy. The root - user dichotomy is far too strong, there needs to be a gradation in permissions so that users can make safe changes, say installing a bunch of new pixmaps for a screensaver (ahem), but get a warning and a requirement for doing anything that could be a threat, like chmod +x as root on a file headed for /sbin, or putting something new in /etc/profile.d instead of the user's own profile...
I'm not a security expert or anything and I'm sure there're significant problems about implementing something along the lines of the above, but either users stop getting bugged about their password for routine tasks or they will on occasion hand it out to the wrong person (i.e. their malicious software). I seem to recall, a while back, a problem in Vista where users en masse disabled its equivalent of su because it was constantly in their face. That way lies baldness and poverty.
The encouraging thing about the incident in question was how quickly it was discovered, communicated and fixes were distributed, although this was facilitated in part because the perpetrator, script kiddie that they are, omitted to actually supply a screensaver with the trojan which sort of gave it away a bit
Nevertheless I suspect that if and as attacks on Linux desktops begin to appear more frequently, it will be the strength of the community that will be a new challenge for the malicious. Where in proprietary software there must be PR, code secrecy and perhaps even legal concerns, communities using free software like GNU/Linux may go ahead and pounce all over anything that's discovered, to the extent that I believe Ubuntu forum users in the original post even launched a small investigation on the person who released the trojan. In this particular instance the community had the advantage simply knowing Linux a lot better than the kiddie who didn't seem to have a fantastic understanding of permissions or scripting. Nevertheless as a community our collective understanding of our operating system should always outstrip that of a given individual, and that shared hacker know-how will perhaps stand as a better defence than the reliance in other communities on proprietary and automated software tools which, on day zero, inevitably fall behind the enemy.
It sounds vigilante and I suppose it is, but there was an agility about the response to this threat which was eye opening and encouraging.
Bottom line is that too much of the time sudo is skipped as a sort of chore rather than a warning from the system - who here actually does check what gDebi has to say or opens a package to look at it before entering the passphrase? I also know that on occasion I've thought for all of three seconds before deciding that importing a GPG key was too much of a chore, for example. Shame on me.
Unfortunately I agree with posters above who point out that the bug lies behind the keyboard in this case. Make sudo more restrictive (e.g. make your default user not a sudoer) and making system changes, even regular updates, becomes tiresome; keep it as it is and less experienced / more lazy users will fall victim to giving their root password to what amounts to a perfect stranger without checking what they are doing first. Same goes with putting in code found in forums or blogs. One doesn't even need root privileges to hose ones data. rm -rf tilde is a really scary set of characters - ideally users would chmod their data to make it read-only by default but I don't know of anyone who actually does this (except me very recently). I don't know much about SE Linux or hardened kernels, but I wonder if as time goes on the whole reliance on permissions as the primary defence against accidents or malicious acts will fade away and predefined security contexts will take over.
What I'm wondering is why does a user need to enter a root password to update their system? The PGP-key check is relied on to check the source is kosher anyway, the user has already defined what to update and what to leave alone (in theory ), or left it to the skilled developers. So why this final check? Who actually doesn't just enter their root password, perhaps scroll through the list and click "OK get on with it", and why should they do any more? And yet, it's this kind of routine work which reinforces the bad notion that entering the root password is just part of a chore rather than a warning to be taken seriously. Thus, permissions should be more context specific - updates should require root password to reconfigure them (change sources or whatnot), but to simply keep the system up to date the process shouldn't need the user's constant reassurance. And so on. Why does one need root permissions to pop some pixmaps in /usr/share ? That's crazy. The root - user dichotomy is far too strong, there needs to be a gradation in permissions so that users can make safe changes, say installing a bunch of new pixmaps for a screensaver (ahem), but get a warning and a requirement for doing anything that could be a threat, like chmod +x as root on a file headed for /sbin, or putting something new in /etc/profile.d instead of the user's own profile...
I'm not a security expert or anything and I'm sure there're significant problems about implementing something along the lines of the above, but either users stop getting bugged about their password for routine tasks or they will on occasion hand it out to the wrong person (i.e. their malicious software). I seem to recall, a while back, a problem in Vista where users en masse disabled its equivalent of su because it was constantly in their face. That way lies baldness and poverty.
The encouraging thing about the incident in question was how quickly it was discovered, communicated and fixes were distributed, although this was facilitated in part because the perpetrator, script kiddie that they are, omitted to actually supply a screensaver with the trojan which sort of gave it away a bit
Nevertheless I suspect that if and as attacks on Linux desktops begin to appear more frequently, it will be the strength of the community that will be a new challenge for the malicious. Where in proprietary software there must be PR, code secrecy and perhaps even legal concerns, communities using free software like GNU/Linux may go ahead and pounce all over anything that's discovered, to the extent that I believe Ubuntu forum users in the original post even launched a small investigation on the person who released the trojan. In this particular instance the community had the advantage simply knowing Linux a lot better than the kiddie who didn't seem to have a fantastic understanding of permissions or scripting. Nevertheless as a community our collective understanding of our operating system should always outstrip that of a given individual, and that shared hacker know-how will perhaps stand as a better defence than the reliance in other communities on proprietary and automated software tools which, on day zero, inevitably fall behind the enemy.
It sounds vigilante and I suppose it is, but there was an agility about the response to this threat which was eye opening and encouraging.