2

I was surprised I was able to back up my wallet over JSON RPC without requiring the wallet password (or even without a secondary backup-only password)

I'm concerned that this could create a DOS attack if the following were to occur

  1. A read-only wallet service is created to perform low-risk operations with the wallet
  2. That low risk service is somehow exploited via a web front end, etc.
  3. The background process (now in control of the attacker) issues the backupwallet command

I think that can be a risk depending on a number of scenarios:

  • The user can save the file with many different random names and fill up the drive (DOS attack)
  • The user can overwrite system files with a copy of the wallet (DOS again)
  • If previous files aren't overridden, and an error is returned, (due to duplicate file, locked file, etc) the attacker can infer information about the remote file system
  • If the system supports pipes, perhaps the wallet can be piped to another remote system (/dev/???)

So I'm wondering if a separate, backup-only password should be created to address this issue. Namely I don't want to use the "decrypt wallet" password.

  • Also I'd like to force that all backups go to a specific directory (and not any other drive/path)

  • Is this a good idea and if so, how should it be incorporated into the network?

Improve this question
2
  • Come to think of it, the Stop() method should also have a password (separate from the JSONRPC account) IMHO
    – makerofthings7
    Commented Dec 16, 2012 at 3:52
  • There are probably a hundred attack vectors if you are letting unfiltered access to submit JSON-RPC commands. "backupwallet" is probably just the quickest. Like you could cause degradation/denial-of-service by doing nonstop getnewaddress RPC command, for instance.
    – Stephen Gornick
    Commented Dec 16, 2012 at 7:27

1 Answer 1

Reset to default
1

The JSON-RPC was never intended to be open to the public, hence the required rpcuser and rpcpassword. For added security it should also be configured to either listen only to the loopback interface or the allowed IPs limited to a few trusted sources.

The wallet password is used to access the encrypted private keys, that's the reason everything involving either adding new private keys or signing with the private keys requires the wallet to be unlocked.

backupwallet exports the keys in their encrypted form and therefore does not require the passphrase.

If you have to allow JSON-RPC access to untrusted users, put a filter in front of it.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.