4 ms·

Doesn't one increase a system's attack surface area/privilege escalation risk by pre-installing tools such as these?

c0l0 3y ago
Usually (not by design, but by circumstance), if someone gains RCE on your systems, they can also find a way to bring the tools they need to do whatever they originally set out to do. It's the old "I don't want to have a compiler installed on my system, that's dangerous, unnecessary software!"-trope driven to a new extreme. Unless the executables installed are a means to somehow escalate privileges (via setuid, file-based capabilities, a too-open sudo policy, ...), having them installed might be a convenience for a successful attacker - but very rarely the singular inflection point at which their attempted attack became a successful one. The times I've been locked in an ill-equipped container image that was stripped bare by some "security" crapware and/or guidelines and that made debugging a problem MUCH harder than it should have been vastly outnumber the times where I've had to deal with a security incident because someone had coreutils (or w/e) "unnecessarily" installed. (The latter tally is at zero, for the record.)
- logifail 3y ago
  > It's the old "I don't want to have a compiler installed on my system, that's dangerous, unnecessary software!"-trope (This is a genuine question). In what circumstances would you need to install/run dev tools in prod? Of course having a compiler installed isn't necessarily an issue... but it might well be a sign that there is an underlying problem! (FWIW, I used to build everything from source. Yes, also in prod. That was a while ago...)
citrin_ru 3y ago
How do you see an escalation using one of listed in the article tool (unless a binary has suid bit which you shouldn’t set if worried about security). Many of these tools provide convenient access to /proc - if an attacker needs something there they can read/write directly to /proc. Though in case of eBPF - disabled kernel support would reduce attack surface and if it disabled in the kernel’s user mode tools are useless.

c0l0 3y ago

Usually (not by design, but by circumstance), if someone gains RCE on your systems, they can also find a way to bring the tools they need to do whatever they originally set out to do. It's the old "I don't want to have a compiler installed on my system, that's dangerous, unnecessary software!"-trope driven to a new extreme. Unless the executables installed are a means to somehow escalate privileges (via setuid, file-based capabilities, a too-open sudo policy, ...), having them installed might be a convenience for a successful attacker - but very rarely the singular inflection point at which their attempted attack became a successful one. The times I've been locked in an ill-equipped container image that was stripped bare by some "security" crapware and/or guidelines and that made debugging a problem MUCH harder than it should have been vastly outnumber the times where I've had to deal with a security incident because someone had coreutils (or w/e) "unnecessarily" installed. (The latter tally is at zero, for the record.)

logifail 3y ago
> It's the old "I don't want to have a compiler installed on my system, that's dangerous, unnecessary software!"-trope (This is a genuine question). In what circumstances would you need to install/run dev tools in prod? Of course having a compiler installed isn't necessarily an issue... but it might well be a sign that there is an underlying problem! (FWIW, I used to build everything from source. Yes, also in prod. That was a while ago...)

citrin_ru 3y ago

How do you see an escalation using one of listed in the article tool (unless a binary has suid bit which you shouldn’t set if worried about security). Many of these tools provide convenient access to /proc - if an attacker needs something there they can read/write directly to /proc. Though in case of eBPF - disabled kernel support would reduce attack surface and if it disabled in the kernel’s user mode tools are useless.