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: Lars Viklund (zao_at_[hidden])
Date: 2010-10-03 23:15:49

On Sat, Oct 02, 2010 at 10:09:18PM -0800, Robert Ramey wrote:
> Marsh Ray wrote:
> > On 10/02/2010 12:56 AM, Lars Viklund wrote:
> >> 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.

The symbols exported by a module can be enumerated together with debug
information to resolve a module and offset into a function name and
offset, through use of dbghelp.dll's API.

> >> 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.

In this case, the application had an UI feature to for a process display
list of threads with resolved function names+offsets where the threads
were currently executing.

> > 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.

There might very well have been a security hole. I reported it upstream
and a fixed version was released shortly after. I leave threat analysis
to people who are competent in the field.

The risk would be somewhat low in this particular case as it relies on
explicit UI actions to view the data.

And of course, it's triggerable completely without the help of S11n, as
all you needed was an overly long symbol name.

-- 
Lars Viklund | zao_at_[hidden]