Slashdot

There were two options:
1. Release it anonymously and take no credit
2. Write about it and get some credit (but then you can't actually release it due to legal issues)

You can't (and won't) release it now. If somebody gets attacked with your code, guess who they're going to prosecute and/or sue.

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

Malware can exist for any platform.
However, real actual malware in the wild requires an eco-system to support it. Providing you can compromise a machine proves nothing. Proving that an ecosystem can actually exist on Linux machines would require completely releasing it into the wild, and subjecting innocent people to it.

I don't know about you, but I know where that falls when it comes to ethics and it ain't on the right side of it.

Why not treat this code like you would any other proof of concept of a security exploit? if the goal to to prove that security vulnerabilities exist and should be fixed then show this code to whomever it will help actually fix those holes but try not to release it to the public at large while it still represents a real threat. Show it to package and distribution maintainers and make recommendations on how they can improve their security configurations to prevent it from running but don't release it as a build your own rootkit tool if it has served its purpose and people are making a serious effort to address the issues it highlights.

This question is posed as if this is new ground. As if this hasn't been done before - without questions of morality and with distinctly less noble intent. All this worry about inserting a malicious payload is wasted. The script kiddies already have better options at their disposal.

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.

I'm fed up with the general consensus that people are able to walk around outside without being punched in the face. After all, anyone can be punched in the face at any time, so I've been thinking about going up to random people on the street and punching them in the face. People need to learn to take reasonable steps to protect themselves from being punched in the face, such as wearing full-face motorcycle helmets at all times, and how are they going to learn that if I don't show them? But now I'm having second thoughts about whether or not it would be ethical to go around randomly punching people in the face. Does anyone have any advice?

Any programmer worth a grain of salt could write the same thing at the drop of a hat. I don't
understand where it would be all that interesting.

the way it persists itself in autostart is really nasty,

Which simply shows that the lack of Linux malware isn't because Linux is somehow magically superior, but simply because nobody has taken the time to write any.

Even better, pretty soon we'll have clueless noobs with their new netbooks running Google's ChromeOS (which they don't know is really Linux because Google is doing everything they can to avoid the "L" word). Now they can get pwned too!!

The claim is that a PHP injection on a web server is going to also infect user-owned tarballs and wine executables and root-owned shell scripts without exploiting a privilege escalation hole? Either his webserver is configured to run as root, or this claim doesn't pass the smell test.

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.

I have a strong suspicion that this whole "question" is merely an attempt by Windows marketdroids to spread one of their favorite FUD formulas: "Linux is not really secure, it's just too unpopular to be targeted by malware writers". Please note how often it is mentioned in otherwise content-free comments.

There is no actual "malware". All author claims is that he wrote something that demonstrates the fact that a program executed on a Linux box by a user has that user's access privileges and can do stuff that the user does not expect or like. That's at best a trojan horse -- without capability to gain superuser privileges or compromise other users or hosts, such "malware" is firmly in the range of stupid pranks -- slightly below changing someone's wallpaper to goatse and slightly above asking someone to check out the Last Measure web site. It has nothing to do with millions-strong botnets and hours-to-worldwide-pandemic worms that make Windows such a great platform for crooks and vandals.

I say release the ideas, or at least document the concepts with pseudocode so that the average skript kiddie can't just download and modify - they'd at least need to spend the time implementing it in some language.

This way, people qualified to fix the problem can review your proof of concept and fix the problem, but you're limiting the exposure to the average bored 15 year old who's skillset doesn't extend too far beyond downloading a .c file and running gcc.