[Pidgin] #15290: Compile everything with secure flags

[Pidgin]

#15290: Compile everything with secure flags
-------------------------------------+------------------------------
 Reporter:  DrWhax                   |       Owner:  datallah
     Type:  defect                   |      Status:  closed
Milestone:  2.10.7                   |   Component:  winpidgin (gtk)
  Version:  2.10.6                   |  Resolution:  fixed
 Keywords:  security aslr dep build  |
-------------------------------------+------------------------------

Comment (by datallah):

 Replying to [comment:15 noloader]:
 > I think exchndl.dll is doing too much in DllMain (via OnStartup), and I
 would expect Pidgin to see some intermittent problems. I don't see where
 its safe to call SetUnhandledExceptionFilter in DllMain. "DllMain : a
 horror story,"
 http://blogs.msdn.com/b/oleglv/archive/2003/10/28/56142.aspx; "DllMain and
 life before birth,"
 http://blogs.msdn.com/b/oleglv/archive/2003/10/24/56141.aspx.
 >
 > By calling SetUnhandledExceptionFilter on the thread that calls DllMain,
 the library is actually installing the exception handler on a thread
 created by the loader. The thread dies after loading.
 http://www.oldschoolhack.de/tutorials/seh.pdf.

 Thanks for the interesting links, there's certainly some information there
 that I wasn't aware of.  I think we may have been fortunate in how we use
 exchndl.dll so that we're not impacted by some of these (or maybe this is
 the reason that the upstream instructions are to use it the way we're
 doing it).  We don't actually link to exchndl - instead it is loaded
 dynamically using !LoadLibrary by
 [http://hg.pidgin.im/pidgin/main/file/release-2.x.y/pidgin/win32/winpidgin.c#l693
 pidgin.exe].  I think this prevents the threading initialization problems
 as well as the ambituity about load order because it ends up being invoked
 in our thread instead of the loader's thread.

 There may still be issues with calling [http://msdn.microsoft.com/en-
 us/library/windows/desktop/ms680634%28v=vs.85%29.aspx
 SetUnhandledExceptionFilter] in !DllMain, but it is a kernel32 function,
 so it may be ok according the "!DllMain and life before birth" article.
 At any rate, it would be relatively trivial to change that so that we call
 an initialization function explicitly, so perhaps I'll do that (on the
 other hand we've been using this a long time and I'm not aware of any
 weird issues).


 > exchndl.dll is also manually duplicating a lot of functionality offered
 in Debug Help. Debug Help is written by the folks who write WinDebug (and
 they are they folks who write the OS). I've had a lot of success over the
 years with Debug Help and its fully redistributable (the only drag is you
 have to download the entered SDK to get the library).
 http://msdn.microsoft.com/en-
 us/library/windows/desktop/ms679309(v=vs.85).aspx.

 Are you referring to the IMGHELP.DLL stuff or other functionality that bfd
 is being used for?
 I had briefly looked at dbghelp when cleaning up exchndl and found that
 apparently
 [https://code.google.com/p/jrfonseca/wiki/DrMingw#The_IMAGEHLP.DLL_Saga
 modern IMGHELP.DLLs use dbghelp.  I didn't look too much at it because I
 didn't have the include files handy without using the Platform SDK.

 We actually couldn't redistribute it (or anything else that's not GPL
 compatible) - it would be ok to use it if it were a system library (which
 it actually appears to be), but if it isn't, it would be a violation of
 our license to use it.


 > > If there were something better, we'd be happy to use it.
 > You are in a sticky situation. As a project maintainer, you are bringing
 in components that you are responsible for (the project is responsible for
 its Supply Chain and outside code falls within those bounds). You can file
 bug reports upstream, but its no consolation when Pidgin takes a bug
 because upstream does not suffer Pidgin bugs. Personally, I have aversions
 to the "let's use library X" because I don't want to be responsible for
 library X (the Boost fan club is especially loud).

 Well, unless you write everything from scratch, which I don't think is
 reasonable, there aren't other options than to use other people's code :).
 I'm not really into reinventing the wheel and I'm certainly already deeper
 into exchndl.dll already than I'd prefer to be.


 > With that said, have you considered google-breakpad
 (http://code.google.com/p/google-breakpad/). It claims to be an open-
 source multi-platform crash reporting system. Its under a BSD style
 license, which is fairly permissive. I know the code has a few issues from
 a quick scan of some of the sources (for example, DLL Hijacking or Binary
 Planting), but the issues should be fixed soon.

 Breakpad has been on my radar for a while and I have briefly looked at it.
 The licensing appears to be ok.  Unfortunately, it doesn't seem to work
 with gcc debug symbols on windows - there are a number of tickets about
 mingw issues.

 >
 > You also have Windows Error Reporting (WER) on the Windows platform
 (http://msdn.microsoft.com/en-us/library/windows/hardware/gg487440.aspx).

 Again, this isn't going to be able to handle gcc debug symbols :(

-- 
Ticket URL: <https://developer.pidgin.im/ticket/15290#comment:16>
Pidgin <http://pidgin.im>
Pidgin