#![debugger_visualizer] arbitrary file access & storing of file in debug binary

[bf]

I tried this code:

#![debugger_visualizer(gdb_script_file = "/etc/passwd")]
#![debugger_visualizer(gdb_script_file = "/proc/self/environ")]

I expected to see this happen: Error: Invalid GDB Python Script

Instead, this happened:

Both files /etc/passwd and /proc/self/environ were added to the rust debug binary file.

$ objdump  target/debug/myapp -j .debug_gdb_scripts -s

target/debug/myapp:     file format elf64-x86-64

Contents of section .debug_gdb_scripts:
 4914b 01676462 5f6c6f61 645f7275 73745f70  .gdb_load_rust_p
 4915b 72657474 795f7072 696e7465 72732e70  retty_printers.p
 4916b 79000470 72657474 792d7072 696e7465  y..pretty-printe
 4917b 722d6d79 6170702d 300a726f 6f743a78  r-myapp-0.root:x
 4918b 3a303a30 3a3a2f72 6f6f743a 2f62696e  :0:0::/root:/bin
 4919b 2f626173 680a6269 6e3a783a 313a313a  /bash.bin:x:1:1:
 491ab 3a2f3a2f 7573722f 62696e2f 6e6f6c6f  :/:/usr/bin/nolo
 491bb 67696e0a 6461656d 6f6e3a78 3a323a32  gin.daemon:x:2:2
 491cb 3a3a2f3a 2f757372 2f62696e 2f6e6f6c  ::/:/usr/bin/nol
 491db 6f67696e 0a6d6169 6c3a783a 383a3132  ogin.mail:x:8:12
 491eb 3a3a2f76 61722f73 706f6f6c 2f6d6169  ::/var/spool/mai
 491fb 6c3a2f75 73722f62 696e2f6e 6f6c6f67  l:/usr/bin/nolog
 4920b 696e0a66 74703a78 3a31343a 31313a3a  in.ftp:x:14:11::
 4921b 2f737276 2f667470 3a2f7573 722f6269  /srv/ftp:/usr/bi
 4922b 6e2f6e6f 6c6f6769 6e0a6874 74703a78  n/nologin.http:x
 4923b 3a33333a 33333a3a 2f737276 2f687474  :33:33::/srv/htt
 4924b 703a2f75 73722f62 696e2f6e 6f6c6f67  p:/usr/bin/nolog
 4925b 696e0a6e 6f626f64 793a783a 36353533  in.nobody:x:6553
 [..]

Meta

rustc --version --verbose:

rustc 1.83.0 (90b35a623 2024-11-26) (Arch Linux rust 1:1.83.0-1)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: x86_64-unknown-linux-gnu
release: 1.83.0
LLVM version: 18.1.8

originally reported in https://github.com/bf/rust-security-problems

[jieyouxu]

Triage: compiler side I don't think we really care at all about where the debug visualizer logic is trying to find the script, delegating to @rust-lang/security to determine if this is something that we should address. Retagging as C-discussion for now, can change to C-bug if this is something that compiler side we need to be address.
@rustbot label -C-bug +C-discussion

[workingjubilee]

Can you explain why you have this expectation, @bf?

Whatever we put inside will be, if the program is actually debugged, executed by running the script, using a Python version we don't know about, at which point it will have file and network access anyways (and could e.g. access files and read/write data). Of course, since programs are generally debugged by starting their execution under the debugger (or a core dump, which is usually obtained by running the program) so could the program?

[bjorn3]

You can also include arbitrary files in the binary using include_str!() and include_bytes!() (and using include!() or #[mod] if it is a valid rust source file). And when using build scripts or proc macros you can also trivially ready any file you want from the build script or proc macro (and more). And you can write arbitrary sections using #[section_name = "foo"] static FOO: [u8; N] = [...].

If you are worried about arbitrary code execution on the debugger side, at least GDB ignores .debug_gdb_scripts unless you explicitly tell it to respect this section. If there is another debugger which doesn't have this security measure, then the fault lies with that debugger. There is nothing rustc can do to mitigate that as an attacker could just compile their object files with another compiler that does allow embedding arbitrary section contents.