Slashdot Mirror
Ethics of Releasing Non-Malicious Linux Malware?
buchner.johannes writes "I was fed up with the general consensus that Linux is oh-so-secure and has no malware. After a week of work, I finished a package of malware for Unix/Linux. Its whole purpose is to help white-hat hackers point out that a Linux system can be turned into a botnet client by simply downloading BOINC and attaching it to a user account to help scientific projects. The malware does not exploit any security holes, only loose security configurations and mindless execution of unverified downloads. I tested it to be injected by a PHP script (even circumventing safe mode), so that the Web server runs it; I even got a proxy server that injects it into shell scripts and makefiles in tarballs on the fly, and adds onto Windows executables for execution in Wine. If executed by the user, the malware can persist itself in cron, bashrc and other files. The aim of the exercise was to provide a payload so security people can 'pwn' systems to show security holes, without doing harm (such as deleting files or disrupting normal operation). But now I am unsure of whether it is ethically OK to release this toolkit, which, by ripping out the BOINC payload and putting in something really evil, could be turned into proper Linux malware. On the one hand, the way it persists itself in autostart is really nasty, and that is not really a security hole that can be fixed. On the other hand, such a script can be written by anyone else too, and it would be useful to show people why you need SELinux on a server, and why verifying the source of downloads (checksums through trusted channels) is necessary. Technically, it is a nice piece, but should I release it? I don't want to turn the Linux desktop into Windows, hence I'm slightly leaning towards not releasing it. What does your ethics say about releasing such grayware?"
.. but sounds like a lot of work to prove a relatively straight foward point.
It's actually been my opinion that Linux in the hands of someone who doesn't know how to use it can in some situations be less secure than windows.
My reasoning for this is that:
1) Newbie Linux users who are having problems with their systems will rpetty much run anything as any user you tell them to in a desperate hope to get Xorg working again
2) Linux commands on their own can look very cryptic to the uninitiated.. add into that the scripting abilities of most shells.. and a new Linux user won't be able to differentiate a malicious command from one that will get their nvidia driver working again
3) The out-of-box remote admin abilities of Linux are excellent.
4) Standard tools like nc can easily be used to establish out-connecting remote shell sessions
5) OR you can just get them to wget and execute your favourite piece of malware.
Show it to distro developers and repository maintainers, people who do security work, etc. Let them look at it and see if they can defend against it. Don't release it on unsuspecting users, publish the directions to remove it, and defend against it so no one else can do it either. Putting malware in the wild is not the way to get white-hats attention, but it is the way to get black hat's attention. The white hats are usually well behind the black hats with malware that's been released in the wild. Give this to white hats and not black hats.
Post it as security bug against all the distros you've confirmed it works against. That'll attract the attention you want and not the attention you don't.
Its whole purpose is to help white-hat hackers point out that a Linux system can be turned into a botnet client
It would be nice to see the code. As it stands, I am surprised that this "news" made it this far, with no links of any kind.
No one credible claims that malware is impossible in GNU/Linux or *BSD. In fact, since UNIX is a much more robust networking OS, maintaining a botnet should be helluva lot easier than on Windows. What we have with a free OS, though, is something that proprietary OS users will never have: a complete and total control over our security policy and every other aspect of our software environment. When and if a vector is identified, our security policy will promptly change to nip it in the bud.
A Speculative Example
Lately I've been thinking about one major vector: the human-assisted privilege escalation. Take the latest Ubuntu and imagine a piece of software which runs with user privileges and does the following: it tricks the user into thinking that it is the automatic updater. Lacking in both expertise and time, I am not going to do a proof of concept, but how hard can it be? You just need to draw a window named "Update Manager" using the standard Gnome API, list a few bogus updates anyone would find legit, with version number irrelevant to their day-to-day life (e.g. binutils), wait for the user to click [Install Updates], and then "gksu pwn_you.sh". The user will enter the password, and your work is done. Then, of course, you still need to draw some progress bars to lull the user into believing that an update is going on, but that's all just an icing on the cake.
If anyone can see why this won't work, I would like to hear it.
Looks scary, right? Wrong. Because the solution is as simple as changing the default policy. Make it so that the default behavior is to notify only. On every system update the user should be told: "Go start the updater via the system menu. By the way, if you EVER see an "updater" you didn't start yourself, you are being pwned." Make sure that the system menu is strictly read-only, and even the dimmest user will be safe.
This won't be implemented in Windows. Why? I really cannot guess why Microsoft's security policy seems to be designed from ground up to fuck the user, but it is. The usual excuse seems to be: "it's easy to use". But whatever is the reason, you just cannot make a proprietary platform secure because you cannot pop the hood open. With a free OS, you can.