Audits check CLI arguments, not actual settings #2
Comments
|
Also, |
|
@rnelson0, see #48 regarding #2 (comment). |
|
@konstruktoid Some huge changes here. Looks like much has been improved, thanks to you and others! I think there are still some minor gaps, take a gander and see if I'm on track. It looks like #14 helps with the reduction of PATH exploits (I think it's reasonable to assume that if someone injects a new binary in those directories, you cannot protect against it without a higher level framework). In #48, get_command_line_args looks like a slight improvement but still misses positional checks. First, the -x option should be used to ensure it matches a command called docker, not one that includes docker. The grep patterns could be surrounded with better markers, perhaps For options leading off with hyphens, that should prevent an issue. It's still possible that these arguments could be following a --pidfile argument which would now be on the previous line.I don't know each argument in depth to determine how this could be best addressed. It looks like the search for |
|
Sounds good, thanks. |
Lots of the tests (particularly in 2) look at CLI args to commands, like docker, i.e. https://github.com/diogomonica/docker-bench-security/blob/master/tests/2_docker_daemon_configuration.sh#L72 looks for
-Hviaps -ef | grep docker | grep "\-H".It appears you could easily fake this out with liberal toying with the docker arguments. Reviewing them at https://docs.docker.com/reference/commandline/cli/, the pidfile stands out as an arbitrary string that could be abused. You could pass tests by creating the following pidfile:
/var/tmp/lxcicc\=falselog-level\=\\\"debug\\\"iptables\=falseinsecure-registryregistry-mirror\\-Hdefault-ulimit(you cannot insert / even when escaped, so thetcp://check would have to be faked with another argument.Also, you're not looking at positions in the ps output. I believe you could exploit the lack of positional testing with something simple like a grep command that isn't given a 3rd argument:
I think if there are ways to test for the present of a listening network socket, for instance, rather than looking for
tcp://, that would more accurately and consistently determine the state.The text was updated successfully, but these errors were encountered: