[WIN32] DLL loading vulnerability

[Daniel Atallah]

On Tue, Aug 31, 2010 at 22:26, Elliott Sales de Andrade
<qulogic at pidgin.im> wrote:
> Hi,
>
> This issue seems to be making all the news now.
> http://www.h-online.com/security/news/item/Microsoft-warns-of-DLL-vulnerability-in-applications-1064584.html
>
> Since it exploits the default current-directory-in-DLL-search-path, I
> would assume the only possible problem is through the protocol
> handlers as I'd think Pidgin would normally have a sane current
> directory set otherwise.
>
> But we've had issues with aspell.dll in the PATH before, and I noticed
> Daniel made some changes to our LoadLibrary calls that might be
> related, so I'm bringing it up now to see if there's any need to make
> a release or something.

It is certainly true that (like anything else) we'd have issues if bad
DLLs are found instead of good ones; we're "vulnerable".

That said, I don't think we're vulnerable to this particular avenue of
exploit - Pidgin isn't the handler for any file types unless the user
manually registers it to open a file extension (which wouldn't make
much sense because we don't accept a file to open as a parameter).

You're right that the protocol handlers are a way that the pidgin.exe
process can be launched indirectly by user interaction, but in that
case no external DLLs are loaded at all, it simply tries to send a
message to the existing Pidgin process, if it can find one.  I
actually don't know if URL handlers are subject to this type of
vulnerability anyway - the current directory shouldn't be the location
of any arbitrary file.

The changes I recently made were the result of looking at our dynamic
loading more carefully as a result of the publicity this type of
exploit has had, but I'm not aware of any specific problems that are
exploitable unless the System %PATH% is already bad or a bad DLL has
been already put somewhere that Pidgin adds to the PATH (based on some
registry entries).

-D

-D