full-disclosure - Edonkey/Overnet Plugins Could Pose Harm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20031217154741.JLQU25110.mta10.adelphia.net@toto>
From: ashton at joltmedia.com (ashton)
Subject: Edonkey/Overnet Plugins Could Pose Harm

My attempt is to get MetaMachine to make them all be SIGNED before they can
be loaded, it's a P2P app and would have 1.2 million+ times the effects of
an WMP plugin, perhaps you took it wrong. My COM statement was that any
dumbarse can write something in MFC to be harmful but when it is pure C++
and COM it's not as easy, MFC gives virus writers or n00bs an easy route at
creating these plugins. So my goal is what I first stated, you cannot
compare WMP or PS to Overnet w/ Plugins because Overnet has 1.2 million
online users at your disposal instantly. You must look at it as a whole.

-ashton

-----Original Message-----
From: petard [mailto:petard@...eshell.org] 
Sent: Wednesday, December 17, 2003 10:04 AM
To: ashton
Cc: full-disclosure@...ts.netsys.com
Subject: Re: [Full-Disclosure] Edonkey/Overnet Plugins Could Pose Harm

On Wed, Dec 17, 2003 at 12:11:38AM -0500, ashton wrote:
<gross misunderstanding/ranting about plugins snipped>
I don't get it. You wrote a long message about how running arbitrary
code from an untrusted source on your PC is insecure. How is this
different from any other common plugin architecture?

You site the Windows Media SDK as an example that gets it write because
it uses "COM" instead of what you refer to as "full c++ access", but you
never differentiate between the two. COM objects can certainly be
written in C++, and there is absolutely no sandbox to keep that code
from doing malicious things. It simply must conform to a COM interface.
If you believe that a malicious (for instance) Windows Media
visualization plugin or a malicious photoshop plugin cannot do every
nasty thing an edonkey plugin can, you are delusional.

Here's a hypothetical example for Windows Media, your example of a safe
SDK:

STDMETHODIMP CMyVisualizer::Render(TimedLevel *pLevels, HDC hdc, RECT *prc)
{
    //Check for our malicious process
    if( !isHelperRunning() ) {
        launchEvilHelperProcess();
    }
    // Proceed to draw pretty pictures so that the moron who downloaded
    // and executed this arbitrary code while thinking it was safe since
    // it exported a COM interface suspects nothing
    doRender( pLevels, hdc, prc );
}
I'll leave the implementation of isHelperRunning() and
launchEvilHelperProcess() to your imagination, but suffice to say code
that's running here is in no way restricted by the fact that the
interface used to invoke it is defined by a particular IDL file and
conforms to the COM specification.

To have a reasonable shot at "safe" plugins, you'd really need some sort
of sandboxing system akin to java's. Even then, as we've all seen, it's
hard to get right. No common app that I can think of attempts this.

In short, it doesn't matter what application starts your arbitrary
code. You could write a malicious plugin for netscape, photoshop, quark,
WMP, anything that takes true executable code for plugins. Most plugin
systems do. Furthermore, few if any provide some sort of clearinghouse
to vet plugins and declare them safe. Don't run it unless you trust it.
It is, for all (good and evil) purposes nothing more then executable
code that is launched and communicates in a specified way.

So my question remains: How is eDonkey worse than these others?

Regards,

petard