<<< Date Index >>>     <<< Thread Index >>>

Re: Edonkey/Overnet Plugins capable of Virus/Worm behavior



I'm sorry, I don't mean to be dense, so please correct me if I've misinterpreted your findings; I'll admit, I'm not very familiar with Edonkey/Overnet. I only see that there is one vulnerability (actually it's an exposure) present here that exceeds the vulnerability of running unknown / untrusted code on your local machine, and that is that you advertise in a searchable format that you possess such code. So correct me if I'm wrong, but the point of your post is to indicate that if someone wrote a vulnerable plugin, it would be easy for any crax0r to locate such individuals because they're searchable. This is akin to the ability to google for insecure web software versions except that in the case of a popular plugin you're likely to have a broader user base.

I don't think that this particularly represents a vulnerability of Edonkey/Overnet per se, but rather a vulnerability in the inherrent trust that most users operate under when accepting software from the Internet. In reality very little (no?) software is totally vulnerability free. You recommend that plugin writers have to get their plugins signed by Edonkey/Overnet before they're usable, but I don't think it's Edonkey/Overnet's responsibility to audit code for hundreds of general plugins in order to do this signing. I have to say, if the ability for a plugin to interface directly with Windows API "is by far the worst and most insecure plugin architechture I have ever seen in my life," I have to wonder how many plugin interfaces you've seen. If giFT and Windows Media *do* sandbox all of their plugins to limit what they can do, then kudos to them for taking the extra security steps here, but others not doing this is hardly a security vulnerability. The plugin environments I've had (admittedly little) experience with are just a series of APIs provided to enable native otherwise-machine-runnable code to interface with an existing application. One of the ideas behind plugins is to permit an application to be extended in functional ways that the authors had not thought of / possessed the resources to realize. While sandboxing will provide elevated security, it first represents a tremendous effort to realize (with out any guarantee of security), and second severely limits the possibilities of what the plugin can do. If an application author feels they can predict all possible functions of a plugin, then they can write a non-limiting plugin environment, but I am pretty sure any plugin environment you can mention, I could think of plugins that you couldn't anticipate.

Accepting plugins that you download from the Internet comes with the same risks as accepting any other software that you download from the Internet.

Have I missed the point? Is there some mechanism present that permits user-unaware propagation of plugins in a default configuration (eg, not requiring a specific vulnerable other plugin)? Or is there some options (plugin independant) that permits this to be the case?

-Eric "MightyE" Stevens
http://lotgd.net

Julian Ashton wrote:

I have concearns about the Plugin arhcitechture and the power given to all the devs out 
there and possible end user harm. I am writing the FastTrack plugin for Edonkey/Overnet 
and during this process have realized that this is by far the worst and most insecure 
plugin architechture I have ever seen in my life. Here is a short list of what they have 
given 1.14 million users(currently online) to have done on their machine if they are to 
download an "bad" plugin.

1. Local code execution
2. Unlimited disk access
3. Unlimited sockets access
4. Code propogation through the client over the networks
5. Basically anything you can imagine in the world that can be done to a 
windows os machine.

Why?
Good question, I have been working on plugin systems suchs as giFT and Windows Media for quite a while and 
while they can do some neat things, this kind of behavoir cannot happen because of the way they were 
architechted. When I think of "plugins" I think of 1. An sdk. 2. Methods that you create that the 
"client" listens for. 3. All code in the plugin is sent to the "client" not the OS level. 
4. Mainly COM (this plugin uses full use of C++/MFC in a DLL)

Where did MetaMachine(Edonkey/Overnet) mess up?
All code in the plugins CAN route to the "client" but they mainly pipe to the 
windows subsystem thus enabling for anything to be written and can then pipe back into 
the application on a low level code basis and take control. Besides these factors what 
about code signing or some sort of key schema at best to keep these plugins mostly legit?

What could happen if malicious plugin is made available?
I leave it up to your imagination. ;)

What is the worst thing that could be of possibility?
Someone could write a legit plugin like "Gnutella" for example. It could work for months 
to come and on a set date they could dump thier virus code from a embedded resource and let it take 
control of which could be at that point 2 Million "clients", it could be one of the 
largest DDoS we could ever see or even worse, it could spout out like MSBlast or worse...

I have created some code as seen here(like i said it can really do anything you 
imagine):

/* This would be the main call done by the "client"
* so the best place for our test */
void CProtocolplugin::start()
{
        MessageBox(NULL,"Your machine could now be infected, press ok to see 
proof.","OPPS!",MB_OK | MB_ICONWARNING);
        CString szFileName = "Plugins//virus.exe.txt";
CFile file( szFileName, CFile::modeCreate | CFile::modeWrite ); CString str = _T("This could have been a virus! - ashton"); file.Write( str, (str.GetLength()+1) * sizeof( TCHAR ) ); file.Close();
        ShellExecute(NULL, "explore", "Plugins", NULL, NULL, SW_MAXIMIZE);
        
ShellExecute(NULL,"open","notepad.exe","Plugins//virus.exe.txt","",SW_SHOW );
        MessageBox(NULL,"I just wrote a text file to your plugins dir, opened explorer to it 
and\nopened the .txt file, image if I was a virus writer. :-)","OPPS!",MB_OK | 
MB_ICONWARNING);
        

}

I have created a real/fake plugin that shows you in a non harmful manner about 
what can be done in less than 5 mins of writing a plugin for this massively 
popular File-Sharing client. You may get it here: 
http://64.78.56.209/Fake_FastTrack.zip Just unzip into the Plugins folder and 
run Edonkey/Overnet to see it in action then just quit and delete it when done.

-Julian Ashton