Restricting access to and stripping down default installed compilers and debuggers

As per the advice on pg 26 the researcher recommends restricting access to compilers/debuggers and interpreters that can assist an attacker in reversing/probing vulnerable binaries . Lets see which ones ship in Debian and see if we can do without them (I assume attacker doesn’t have sufficient privileges to re-install and if they do then it’s game over anyhow). Meanwhile apparmor can restrict access to interpreters on a need to work basis.

https://web.archive.org/web/20180212122001/https://pen-testing.sans.org/resources/papers/gcih/discovering-local-suid-exploit-105447

Related ticket:
https://phabricator.whonix.org/T941

@madaidan

Can such packages just be uninstalled? In gateway VM there is no need to compile or debug anything and in workstation VM probably also not needed, but maybe somebody does write code in it.

That’s not how it works. These packages aren’t installed by “choice” (as in “desire”). These are dependency packages.

This wouldn’t really work. The attacker can compile their own binaries and they don’t need to use a debugger present on the system. Nothing forces them to use e.g. gdb for debugging; the attacker can include the necessary code in their own program. It’s better to prevent the methods used to debug binaries in the first place which we do where possible e.g. we use YAMA to restrict ptrace.

Interpreters are different however since they allow bypassing file execution restrictions.

2 Likes

This depends on unspoken, undocumented highly sophisticated threat models.

If all (or most?) of the following was already implemented:

And parts of:

was implemented… Then yes, then:

https://phabricator.whonix.org/T941

might be of benefit.