Closed ghost closed 4 years ago
That's a great observation, botb definitely needs more checks pre-exploitation.
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.... ;)
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.
The original issue here should be addressed in the latest release https://github.com/brompwnie/botb/releases/tag/1.6.0
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.