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

Comments

consult with a real security professional

[ChipMonk]

Contact someone at SANS, or Bruce Schneier, or some such. Maybe even someone on the SELinux project; if this non-malicious malware is indeed as capable without SELinux as you claim, and SELinux mitigates/eliminates the danger, this could be good PR for them.

Re:SELinux on a a server?

[eparis]

SELinux was not the cause of any of the recent kernel exploits making use of NULL pointer dereference. For this class of bugs SELinux systems were stronger than non-SELinux systems when the attack was coming from a network facing daemon, but were weaker for logged in authenticated users. So for the purposes of this discussion (logged in users clicking things they shouldn't) Yes, older SELinux systems might be weaker than non-selinux systems. But SELinux was never the actual problem, just made the real problems harder or easier to exploit (in current kernels SELinux is believed to be stronger against both classes of attacks for these types of bugs)

Consult with an attorney about the CFAA too.

[Valdrax]

You might also really want to talk to a lawyer who knows the Computer Fraud and Abuse Act. At a minimum, you may need to worry about 18 USC 1030(a)(5). Pay attention to the definition of "damage" and "loss" in 18 USC 1030(e)(8),(11).

Re:It does harm!!!!

[nhytefall]

Negative. Unless I specifically give permission then you still cannot enter. What is so effing hard about that concept for people to grasp?

Re:I think you've already decided...

[WuphonsReach]

browsing some porn sites

(sigh) That's a fallacy that needs to die. Yes, drive-by exploits are more common in the dark corners of the internet (warez, porn, etc. sites). But you're also quite likely to find regular websites that have been hacked to serve up exploits and infections. Not to mention the constant problems where ad networks serve up malicious content.

You can no longer assume that just because you don't go visit the dark corners of the internet that you're safe.

The last infection that I tracked down by reviewing our squid transparent proxy logs came from a hobby site. I don't remember if it was sewing, cooking, or some other benign type hobby. But it was nothing that would get you fired if someone saw you browsing it. The site's pages had been all altered to serve up a Javascript exploit which would infect the machine.

Re:SELinux on a a server?

[WuphonsReach]

SELinux, in a lot of cases, is basically file system permissions on steroids. Daemons run inside a domain, files and ports get labeled with SELinux labels. Then you define what and how the domain is allowed to touch. (And it's more fine grained then just "read / write".)

Sorta like how you define what a user is allowed to touch on the file system by assigning group membership and file permissions.

If the SELinux policies are very tight and the service is well behaved and you can easily define the allowed actions, things work well. It just gets trickier when daemons are not well defined and tend to talk to random ports and touch random files. Just like coming up with a reasonable set of permissions and group membership for a user that allows them to get their job done without constantly pestering you, it can be a bit of an art form to define SELinux policies.

(There's probably more to it then describing it as file permissions on steroids, but it gets the general idea across. The system is only as secure as the labeling and policies.)

Re:It does harm!!!!

[budgenator]

It doesn't matter what you do now, some asshat is going to read the description of the "linux malware" reproduce it without bragging about what a l33t script kiddie he is and your going to take the burn for it. As for it being a linux malware

I was fed up with the general consensus that Linux is oh-so-secure and has no malware.

I can understand that

a Linux system can be turned into a botnet client by simply downloading BOINC and attaching it to a user account.

I'm not sure that having the user specifically install a software package that specifically runs downloaded programs is the same class of malware as windose user are typically plagued by anyways. This is more social engineering than a linux security hole and more of a boinc security problem than a linux problem

The malware does not exploit any security holes, only loose security configurations and mindless execution of unverified downloads.

So basically your saying is Linux is oh-so-secure that you have to trick users into installing your malware.

If executed by the user, the malware can persist itself in cron, bashrc and other files.

you may be able to install into .bashrc but it's not going to work in cron without privilege escalation or a security hole; usually only widosers mindlessly type in privelged account passwords to install software to run in limited accounts. In fact I'm calling BS on this, you don't have this malware, you just have a plausible idea for it that you've not bothered to implement.