Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues

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:

#!/bin/bash

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

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.