Version: 1.32.1-1 Severity: critical Tags: security Justification: causes serious data loss X-Debbugs-Cc: sebastien.copin@etik.com Dear Maintainer, I was investigating the behavior of fakeroot and I found there are shared library and command injections security risks. This aspect is not well documented. There is a shared library injection "by design" through the argument -l / --lib (example: fakeroot -l /tmp/revshell.so [http://revshell.so], where the .so file can be malicious; a reverse shell here). The shared library is positionned in LD_PRELOAD environment variable. There is also a command injection in the same argument. Example: fakeroot -l ";id" where id is the injected command. It is because of a direct "eval" of the user input in fakeroot main script (line 67): while test "X$1" != "X--"; do case "$1" in -l|--lib) shift FAKEROOT_LIB=`eval echo "$1"` PATHS= ;; The real exploitation of the --lib argument is not really easy. Here some scenarios: - Exploitation of an OS misconfiguration by editing the original libfakeroot*.so (default path: /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so [http://libfakeroot-sysv.so]) - Influence / injection on this argument in an automatized build (example: fakeroot is often used in CI/CD for package building). - Usage of fakeroot to evade a restricted environment. The injection payload can be the shared library (so, it needs to be built and present on the local system), or a command (could be launched remotely under specific conditions). The other following arguments are also subjects to command injections: - -f/--faked - -s Example : fakeroot -f "touch /tmp/pwnd". I think fakeroot should be more secured, by removing / deprecating vulnerable arguments, or be enhancing documentation about security risks.