brompwnie / botb

A container analysis and exploitation tool for pentesters and engineers.
GNU General Public License v3.0
632 stars 59 forks source link

-pwn-privileged doesn't work when cgroup is already mounted #9

Closed ghost closed 4 years ago

ghost commented 5 years ago

In utils.go:66 the mount of the cpu cgroup controller is being executed.

botb fails, if the mount fails (which is the case, when the cgroup is already mounted).

After removing the error check / cgroup mount, the privileged pwn works again.

The abuseCgroupPriv function should check if the mount already exists before. I'll try to build a patch for that.

brompwnie commented 5 years ago

That's a great observation, botb definitely needs more checks pre-exploitation.

ghost commented 5 years ago

Additionally (maybe good for the debug output): the default-docker apparmor policy blocks writes to the cgroups fs, --privileged disables the apparmor restrictions by default. Thats the reason why simply using existing cgroup mounts doesn't work anymore with apparmor enabled and a non privileged container.. (took me a while to find echo -n noquiet > /sys/module/apparmor/parameters/audit to see the apparmor denies which confirmed my assumptions)

Maybe the scope of this bug should be to implement using existing cgroup mounts first before trying to remount a new cgroup. On the other hand it would be really useful to figure out, why mounting an own cgroup doesn't work anymore in my environment, because apparmor is path based.... ;)

brompwnie commented 5 years ago

Those are valid points, I think a good approach going forward is to have the option for both, (1) create a new cgroup mount (2) use an existing cgroup mount. I'm gonna mark this ticket as a feature enhancement as well.

brompwnie commented 4 years ago

The original issue here should be addressed in the latest release https://github.com/brompwnie/botb/releases/tag/1.6.0