Boost logo

Boost :

Subject: Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-12-19 11:44:30

On 12/19/16 19:09, Peter Dimov wrote:
> Andrey Semashev wrote:
>> > Why is spawning a process to do the decoding unacceptable?
>> I pointed out this in my review. One reason is because of security
>> considerations. If the library executes a foreign executable with path
>> lookup, it is possible to put a malicious executable with the parent
>> process permissions. The parent process can be a daemon, running with
>> elevated permissions, so this could potentially be devastating. This
>> is more so a problem if the user of Boost.Stacktrace is not suspecting
>> that the library executes a process under the hood.
> OK... but can you give some specific examples, on Linux and Windows, as
> to how such an attack would work? Complete with actual directory and
> file names.

Suppose someone placed $HOME/bin/addr2line of the following content:


if [ $UID -eq 0 ]
   echo Hello, root!
   /usr/bin/addr2line "$@"

And then there is your application that is linked with Boost.Stacktrace
and at some point it executes `frame::source_file()` or
`frame::source_line()` (for example, while processing an exception with
attached stacktrace). It would work seemingly fine when executed under
your user, but it will execute malicious code when executed under
`sudo`. And there may be valid reasons to want to run your program under
`sudo` at times.

I'm less knowledgeable about Windows innerworkings, but I think
something similar is possible there as well. Also, I'm not a security
expert, so maybe there are other exploits.

Bottom line: I just don't want a potential security issue where none is
required. No fork+exec = no problem.

Boost list run by bdawes at, gregod at, cpdaniel at, john at