-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't use env::current_exe with libbacktrace #33554
Conversation
// down that executable this is. We can't use env::current_exe because | ||
// libbacktrace will break in unboundedly horrible ways if the file at that | ||
// path doesn't actually correspond to this process at the time we look at | ||
// it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you elaborate here and indicate that it's a security concern for not reading an arbitrary executable? Basically emphasize the facts of:
- You can probably trick
current_exe
to point at any file, or rather that's the worst case. - There's been at least one bug reported in libbacktrace for corrupt dwarf info
- We don't know of any other vulnerabilities, but at worse we assume that arbitrary code execution is possible with corrupt dwarf info to libbacktrace (until we find evidence to the contrary)
And thus we don't pass a pathname to libbacktrace
I agree with the comment of @alexcrichton. I expect also some tests should be marked ignored for some platforms (like |
Updated. I fixed run-pass/backtrace-debuginfo.rs - I guess we'll let the builders find out what other tests need to be fixed. |
…hton Don't use env::current_exe with libbacktrace If the path we give to libbacktrace doesn't actually correspond to the current process, libbacktrace will segfault *at best*. cc rust-lang#21889 r? @alexcrichton cc @semarie
This is probably the cause for http://buildbot.rust-lang.org/builders/auto-win-gnu-64-nopt-t/builds/4202/steps/test/logs/stdio. (rollup #33589) |
If the path we give to libbacktrace doesn't actually correspond to the current process, libbacktrace will segfault *at best*. cc rust-lang#21889
Thanks, fixed. @bors r=alexcrichton |
📌 Commit 9393e52 has been approved by |
…hton Don't use env::current_exe with libbacktrace If the path we give to libbacktrace doesn't actually correspond to the current process, libbacktrace will segfault *at best*. cc rust-lang#21889 r? @alexcrichton cc @semarie
…hton Don't use env::current_exe with libbacktrace If the path we give to libbacktrace doesn't actually correspond to the current process, libbacktrace will segfault *at best*. cc rust-lang#21889 r? @alexcrichton cc @semarie
Accepted for backport at libs triage |
// be in "permanent memory", so we copy it to a static and then use the | ||
// static as the pointer. | ||
// Things don't work so well on not-Linux since libbacktrace can't track | ||
// down that executable this is. We at one point used env::current_exe but |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this meant to say: "down what executable this is. ..." ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, yeah.
If the path we give to libbacktrace doesn't actually correspond to the
current process, libbacktrace will segfault at best.
cc #21889
r? @alexcrichton
cc @semarie