@guardian said in CVE-2019-16701:
Unless you have the WebGUI accessable from the WAN, then no one can access the RPC from the WAN -- Therefore it is not a REMOTE exploit.
Technically if it's possible from any system other than the firewall itself, it can be considered "remote" since it's not a "local" exploit, and it can happen across the network. Though you are correct in that there is no danger unless you have (foolishly) opened your GUI to the world.
Unless you have the admin password or the password for a specially configured user, then this can not be used -- If an attacker has the admin password, it's game over anyway!
Exactly. If you grant a user permission to run remote commands, don't be surprised when they can run remote commands.
Other than the default admin user, it would take deliberate action to configure a user that could execute the RPC, and there are warnings on the page so that a noob didn't do it without some awareness that it was happening.
There are more warnings now about the permission in general, but yes. And there are a number of permissions that could also give someone access to perform admin-level operations (such as granting permission to access diag_command.php). That said, some people do select-all on the permissions list not knowing what they are doing. There is no more danger from this specific page than others they would also grant access for when making that mistake, however.
Only thing might be a good thing to rate limit bad password attempts to prevent brute force attacks.... but again, if it's only on the LAN, the risk is limited to an already compromised network.
That is already done via sshguard, though there are improvements there on the current development code to ensure the XMLRPC auth failures get caught along with other bad auth attempts.
