Module-wide flag bypass via PATH hijacking

[code-wolf-byte]

Several Linux Luminarium challenges can be completed without performing the intended task by placing attacker-controlled binaries earlier on PATH. The root-owned checker (e.g., /challenge/run) executes helper programs by bare name (ps, fold, cat, etc.). Because the checker runs with elevated privileges (setuid interpreter / root), those helpers are resolved through PATH, allowing a student to execute arbitrary code as the checker and directly read /flag. This bypasses the intended learning objectives and lets flags be obtained immediately.

[zardus]

Honestly, I think this is too many changes. For example, we actually don't want -e, as it breaks the [ test ] && blah shorthand we often use. We might not want -u. We also don't necessarily want pipefail. It's probably the better route to go, but it's definitely not clear that chals won't break. Finally, if we're fixing the path, there's no need to hardcode the path for all the binaries :-)

Unfortunately, these fixes also don't prevent a bypass. bash will source BASH_ENV immediately upon starting up, so unsetting it later doesn't actually prevent the bypass. Give it a try: BASH_ENV=<(echo cat /flag) bash

In general, what we should move toward is either using the more correct shebang (e.g., https://github.com/pwncollege/shell-lin-do/blob/main/first/30/run#L1) or move over the the right way of doing this via exec-suid and bash -p or whatnot. With the environment wiped, the other things (alias fixes, unsetting sensitive variables, etc) also becomes unnecessary.

For now, can you change this PR to just update the shebangs with #!/usr/bin/env -iS /opt/pwn.college/bash? One caveat here is that some challenges require users to pass in environment variables. In those cases, we can't wipe the env, so those will realistically just have to remain bypassible. Should be only a few of them.