Quote from: wanatu on January 21, 2018, 02:03:40 AM

Quote from: Claymore on January 20, 2018, 12:38:59 PM

1. CVE-2017-16929 works only if you specified -mport > 0 and don't use password (-mpsw). Also it can crash miner:

From History.txt:

...
v10.2
- fixed critical issues in remote management feature (attacker could crash miner even in read-only mode).
...

That was the last known security issue and it was fixed in v10.2 and above.

Here is my opinon:
Yes my miners have "remote management" feature that allows administrators to upload files, restart miners etc. It's not a vulnerability itself. Also I know that this feature can be used by attackers, therefore by default miner uses "read-only" mode which ignores all commands except "miner_getstat1" (I mean recent versions of my miners, very old versions have no "read-only mode"). User must specify "-mport" option and positive port manually to enable potentially dangerous commands. Also I added "-mpsw" option that allows users to set a password for remote management. Also miner shows warning during startup if "read-only" mode is disabled and -mpsw is missed. Also I added necessary information to Readme file. And, of course, it's bad idea to make these ports public, they must be used in local network only, "-mport" option can expose the port to specified network interface only.
To make this feature dangerous, user must do the following:
1. Disable "read-mode", ignore miner warning.
2. Ignore "-mpsw", i.e. don't set a password, again ignore miner warning.
3. Expose the port(s) to internet.
So, in my opinion, I did everything to make this feature safe as much as possible, but some users have no idea/knowledge what they do when they change default settings.

cve-2017-16929 - authenticated directory traversal - as statet in the advisory (link) requires remote mgmt enabled (write) and you need the password if set
cve-2017-16930 - unauthenticated buffer overflow - as statet in the advisory (link) requires remote mgmt enabled; read-only is also affected; attacker does not need to have a password; This case "could cause a crash" (best case) whereas one would likely aim for remote code execution to hijack the process (shellcode -> exploit; worst case; consider your machine compromised if your vulnerable version was reachable from the internet).

Yep, it would be easier to reason about the security of the code if it were open source, or at least had a formal code audit.