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

["Eric \"MightyE\" Stevens" <trash () mightye org>]

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