Background:
Redis was always vulnerable to remote code execution attacks if left unprotected (by password). Salvatore preferred to disregard that by telling people they must use passwords and even demonstrated how using CONFIG SET dir you can gain access to a host (http://antirez.com/news/96) Years later he added the protected-mode config that should prevent people from unintended exposure, but some people don't bother understanding what they're doing and still disable it. More recently there was another interesting attack using Modules and REPLICAOF: https://github.com/redis/redis/issues/6220, and the response was not to load modules if they lack the executable bit on the file system. Here's an example of someone being attacked by both methods (MODULE and CONFIG).
I assume that sensible users either learned to block CONFIG and DEBUG or password protect their servers, so this is not urgent, but maybe we need to add something similar to "protected-mode" for sensitive configs and DEBUG.
Resolution
Since the DEBUG command is only used for redis developers and the test suite, what we'd like to suggest is to add a non-mutable config such as debug-command [yes|no|unixsocket] which will be either no or unixsocket by default.
The next step is to declare some configs as "protected" (e.g. the dir config and many others), and add a non-mutable config such as allow-protected-config-changes [yes|no|unixsocket] (also default to either no or unixsocket).
p.s. even if the value is no we can use a gdb script on extreme cases to enable it at runtime if we wanna extract some debug info from a running server.
The next thing to consider is modules. AFAIK the vast majority of users aren't using modules (and it's likely that these are also where most of the careless uses are), so considering that modules increase the attack surface, maybe they should be also disabled by default and protected by some non-mutable or protected config.
Comment From: oranagra
Note, I think that when doing this, we may also want to hide the blocked commands from the COMMAND command and ACL CAT output, so that they won't be listed in Redis.io when it gets based on #9656 (in the spirit of #9684)
Comment From: oranagra
i wanna retract my last comment. I'm not certain we wanna hide the 2 blocked commands from COMMAND command output. i suppose it is valid to state that there is such command, but it's inaccessible (same as ACL user that doesn't have access to a certain command can still see it listed).