Re: [Boost-users] [serialization] boost::serialization adds huge amounts of exports to resultant Windows PE file

Subject: Re: [Boost-users] [serialization] boost::serialization adds huge amounts of exports to resultant Windows PE file
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-10-03 02:09:18

Marsh Ray wrote:
> On 10/02/2010 12:56 AM, Lars Viklund wrote:
>> On Wed, Sep 29, 2010 at 06:48:55PM -0800, Robert Ramey wrote:
>>> Chris Yuen wrote:
>>>> Hey guys,
>>>>
>>>> I am using boost::serialization from 1.44.0. One thing that I
>>>> noticed is that linking statically to the serialization libs will
>>>> add several hundred exports in the final exe file that I get.
>>>> Using `dumpbin /exports my_program.exe`
>>>
>>> These functions are not explicity called from the library.
>>> But they ARE called as part of the serialization process.  Its
>>> just that MSVC doesn't see them.  So when you compile
>>> for release, The MSVC Linker strips them out and the
>>> program won't work anymore.   In order to work around
>>> this, these functions are explicitly exported.  This prevents
>>> MSVC from stripping them out.  For more information
>>> see force_include.hpp
>
> The problem with exporting is that it adds a semantic meaning which is
> unwanted.

I'm not seeing this.

> I think the /include linker option is supposed to do what you want:
>
> http://msdn.microsoft.com/en-US/library/2s3hwbhs%28v=VS.80%29.aspx
> "Specifying a symbol with this option overrides the removal of that
> symbol by /OPT:REF."
>
> You can even specify it in the source:
>
>     #pragma comment(linker, "/include:__mySymbol")
>
> http://msdn.microsoft.com/en-us/library/7f0aews7%28VS.80%29.aspx

I don't see how one could pass a symbol generated by template to to
a linker switch or to a pragma.

>> These exported symbols are excellent for provoking bugs in software
>> that makes assumptions about the maximum reasonable length a symbol
>> should be able to have.

I'm no seeing this either. I don't see how that this symbol information
is accessible.  Even if it is, I don't see how it could be used.

>> I had a quite fun hair-tearing experience with a task manager
>> replacement that overran some buffer due to Boost.S11n, resulting in
>> instability, bogus output and program crashes.

I don't see how exported symbols could cause this.

> Sounds like that app may have an exploitable security hole. There are
> a variety of techniques to load modules remotely into Windows,
> especially if the attack doesn't need be executed directly.

I don't see this either.

Someone else has reported that msvc no longer strips these symbols
but has been unable to test this.  I don't see how it's possible for
the compiler/linker to know which unreferred to symbols can be
stripped and which cannot be.  GCC has some attributes which
one can attach to flag function which shouldn't be stripped so it's not
a problem there.  The IBM compiler recently added attributes handle
this as well.  As I noted above, I see anyway that linker switches
or pragmas can be generated with template code.

Robert Ramey