[Pidgin] #15209: Pidgin for Windows (2.10.6) - Missing DEP and ASLR

[Pidgin]

#15209: Pidgin for Windows (2.10.6) - Missing DEP and ASLR
----------------------+-----------------------------------------------------
 Reporter:  noloader  |        Owner:  rekkanoryo  
     Type:  defect    |       Status:  new         
Milestone:            |    Component:  unclassified
  Version:  2.10.6    |   Resolution:              
 Keywords:            |  
----------------------+-----------------------------------------------------
Description changed by noloader:

Old description:

> Running BinScope on the latest Pidgin for Windows shows pidgin.exe is
> missing some platform security features, such as DEP and ASLR.
>
> Failed checks
> C:\Program Files (x86)\Pidgin\pidgin.exe - NXCheck ( FAIL )
> Information :
> Image is not marked as NX compatible
> C:\Program Files (x86)\Pidgin\pidgin.exe - SafeSEHCheck ( FAIL )
> Information :
> No SAFESEH (LOAD_CONFIG absent)
> C:\Program Files (x86)\Pidgin\pidgin.exe - DBCheck ( FAIL )
>
> To resolve the failed issues, the switches of interest for Visual Studio
> are: /GS, /SafeSEH, /NXCOMPAT, /dynamicbase. High risk source files, such
> as those which parse messages from unknown sources and the internet,
> should add "#pragma strict_gs_check(on)" to the source file.
>
> For completeness, here are the switches for GCC: -fPIE and -pie (or -fPIC
> and -shared), -fstack-protector-all, -Wl,-z,noexecstack,
> -Wl,-z,noexecheap, -Wl,-z,relro, -Wl,-z,now. If Glibc is being used, the
> -DFORTIFY_SOURCES=2 should be used.
>
> Buffer overflows and other programming defects happen on occasssion, and
> things like ASLR and DEP will help mitigate the failure for folks using
> the program. The platform security measures can take a critical bug (for
> example, that results in remote code execution) and turn it into a non-
> critical defect (for example, a call to abort() due to a stack smash).

New description:

 Running BinScope on the latest Pidgin for Windows shows pidgin.exe is
 missing some platform security features, such as DEP and ASLR.

 ** Failed checks **
 C:\Program Files (x86)\Pidgin\pidgin.exe - NXCheck ( FAIL )
     Information : Image is not marked as NX compatible
 C:\Program Files (x86)\Pidgin\pidgin.exe - SafeSEHCheck ( FAIL )
     Information : No SAFESEH (LOAD_CONFIG absent)
 C:\Program Files (x86)\Pidgin\pidgin.exe - DBCheck ( FAIL )
     Information: Image is not marked as Dynamic Base compatible

 Running the image with full defenses via EMET
 (http://support.microsoft.com/kb/2458544) produced no errors. I'm not a
 hardcore IM'er, and I did not try any of the available plugins.

 To resolve the failed issues, the switches of interest for Visual Studio
 are: /GS, /SafeSEH, /NXCOMPAT, /dynamicbase. High risk source files, such
 as those which parse messages from unknown sources and the internet,
 should add "#pragma strict_gs_check(on)" to the source file.

 For completeness, here are the switches for GCC: -fPIE and -pie (or -fPIC
 and -shared), -fstack-protector-all, -Wl,-z,noexecstack,
 -Wl,-z,noexecheap, -Wl,-z,relro, -Wl,-z,now. If Glibc is being used, the
 -DFORTIFY_SOURCES=2 should be used.

 Buffer overflows and other security defects happen on occasssion, and
 things like ASLR and DEP will help mitigate the failure for folks using
 the program. The platform security measures can take a critical bug (for
 example, a message that results in remote code execution) and turn it into
 a non-critical defect (for example, a call to abort() due to a stack
 smash).

--

-- 
Ticket URL: <http://developer.pidgin.im/ticket/15209#comment:1>
Pidgin <http://pidgin.im>
Pidgin