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.