[WIN32] DLL loading vulnerability
datallah at pidgin.im
Tue Aug 31 22:50:43 EDT 2010
On Tue, Aug 31, 2010 at 22:26, Elliott Sales de Andrade
<qulogic at pidgin.im> wrote:
> This issue seems to be making all the news now.
> 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
More information about the security