libbacktrace crash and os::self_exe_name race condition

[semarie]

This issue is to report several problems linked:

• libbacktrace (embeded in every rust-compiled program) is fragile (a bad input could generate a crash, I don't have checked for code-execution at this moment)
• a race condition exists with os::self_exe_name that could permit to exploit the previous issue by replacing at runtime the binary by a specially crafted elf.

I will first speak about the race, and next about libbacktrace.

First, about os::self_exe_name: it is a function that return an Option about the running binary (the filepath to the binary used for launch the running processus).

The function is used in rustc:

• by librustc to infer the default sysroot directory (rustc and rustdoc use it)
• by libbacktrace under bsd system for gets the binary symbols
  (but note that for others platforms, libbacktrace obtain symbols by itself using similar method than os::self_exe_name, so there is the same problem)
• by severals tests

The implementation (sys::os::load_self) is platform dependant:

• freebsd: sysctl()
• dragonfly: readlink(/proc)
• linux, android: readlink(/proc)
• macos, ios: _NSGetExecutablePath()
• windows: GetModuleFileNameW()

Just returning a filepath is subject to race condition for many usages. The libbacktrace usage is one of them.

libbacktrace is initialized on sys::backtrace::print() call (so not at the beginning of the processus). This function is called by sys::backtrace::write(). And on panic, a backtrace is showed if RUST_BACKTRACE environment is setted.

So, when a panic occurs, libbacktrace will read the previously obtained filepath (from os::self_exe_name or by itself). It will open this filepath, parse the ELF structure, search for symbols and addresses... and do all the thing it need for print a pretty backtrace.

The problem is libbacktrace seems not robust enought for specially crafted ELF. I have started to test it with afl-fuzzer, and it reports severals crashs (that may or not be suceptible to produce code-execution).

As libbacktrace is embeded in (near to) every rust-compiled programs, it could be a dangerous thing.

To successfully exploit it, the following conditions are required:

• run libbacktrace code:
  • RUST_BACKTRACE environment variable to be setted
  • trigger a panic in running process
• have libbacktrace read a crafted-elf:
  • replace the file of the running program by another one after the start of the program, and before the panic

The conditions are relatively high for simple exploitation, but as it is a problem present in (near to) every rust-compiled code, some attention should be need.

[huonw]

The possibility of code-execution seems worth nominating, however, it seems to me that you're likely to be pwned already if an attacker can modify the binary being run (on the other hand, maybe the problem described here can be exploited in other ways).

[semarie]

It is heavily depending of the context, I am agreed. But it is a problem in every compiled program, not just in rustc.
And it is not possible to ensure the safetly of use of every rust-compiled-program.

As example, it could be possible to consider https://play.rust-lang.org/:

• it is possible to call os::setenv("RUST_BACKTRACE", "1")
• it is possible to trigger a panic
  As result, the backtrace code is runned, and the backtrace at the panic!() call will be displayed.

After, I don't known about detail of compilation and execution for this service, and if the race could be exploited to achieve code-execution.

[huonw]

Yes, but it seems that the only way to exploit this is to either cause self_exe_name to point to some new file (I imagine this isn't possible on most platforms?), or to actually modify the file pointed to by self_exe_name(). The latter is the case I was referring to: if the attacker can change the executable itself on disk, you've likely got deeper problems than unsafety in libbacktrace.

[semarie]

I'm not able to test every platform, and as said the exploitation possibility is dependent of the context.

A locally installed program will not be vulnerable to this kind of problem (or, as you said, without deeper problems).
I was more thinking about ephemerals binaries, that are more exposed.

Some notes about several implementations:

• Linux: basically a readlink("/proc/self/exe")
  They should be safe, the content seems to be valid or absent: it don't point to replaced binary and the system don't permit modification a a running binary.
• FreeBSD: use the value returned by sysctl()
  Same conclusion than for Linux.
• DragonFly: same method as Linux (but using "/proc/curproc/file")
  If the binary is moved, the link follow it. But if it is deleted, it seems the link could point to a new file.
• OpenBSD: it is the one I wrote, and as OpenBSD don't provide method for obtain the filepath of a running program, it use argv[0] as source of information.
  In a security perspective it is bad as argv[0] could be forged by the parent processus.
• MacOS or Windows : not tested.

[pnkfelix]

P-high, not 1.0.

[semarie]

Just a comment about "safety" in my previous comment: the race remains even if the platform is "safe".

For example for Linux, when reading the file /proc/self/exe, you know you read the good file. But here, you dereference the link to obtain a filename, and some time after that you read the file pointed by this filename.

[steveklabnik]

Triage: no change

[brson]

cause self_exe_name to point to some new file (I imagine this isn't possible on most platforms?)

This is easy to do on Unix, since files can be deleted or moved while they are running.

In thinking about how both rustc and rustup use current_exe, it seems like it would be easy to influence what code they run by changing file at that path, particularly with rustup, which will actually execute it during uninstallation.

At the same time, when I think of bugs that could lead attackers to cause a compiler like rustc to execute arbitrary code, I start to think of all the other ways people could influence rustc to execute arbitrary code, and it seems hopeless. If an attacker has local disk access there are unlimited things they could do to cause a compiler to execute anything.

[brson]

The libs team discussed this issue recently and agreed to do two things:

• Disable libbacktrace in configurations where we know it to be insecure.
• Update the current_exe docs to be more explicit about the its dangers.

[brson]

An aspect that the libs team didn't consider in the discussion is the behavior of current_exe following symlinks. @semarie suggests it is insecure to do so.