Skip to content

Conversation

@laanwj
Copy link
Member

@laanwj laanwj commented Mar 7, 2017

Prevent arbitrary files from being overwritten by dumpwallet. There have been reports that users have overwritten wallet files this way. It may also avoid other security issues.

Fixes #9934. Adds mention to release notes and adds a test.

@sipa
Copy link
Member

sipa commented Mar 7, 2017

concept ACK

@jonasschnelli
Copy link
Contributor

Important fix.
utACK 1307cd79b859f01a35d68dea9a674e56451f75f5.
IMO this is a backport candidate.

@laanwj laanwj added this to the 0.14.1 milestone Mar 7, 2017
@maflcko
Copy link
Member

maflcko commented Mar 7, 2017

utACK 1307cd79b859f01a35d68dea9a674e56451f75f5

@paveljanik
Copy link
Contributor

The change as written now allows to test the existence of any file.

@gmaxwell
Copy link
Contributor

gmaxwell commented Mar 7, 2017

only downside I see to this is an in automated backup that leaves files behind, your backup will stop and you might not notice. (I think that is a preferable failure mode to what we have now)

@laanwj
Copy link
Member Author

laanwj commented Mar 7, 2017

The change as written now allows to test the existence of any file.

That seems preferable to overwriting any file, right? I tend to agree that being able to write arbitrary non-existing files is still a security risk, but it is tons better than what we have now.

Do you have a suggestion that would avoid this usage but still offers the same functionality?

only downside I see to this is an in automated backup that leaves files behind, your backup will stop and you might not notice. (I think that is a preferable failure mode to what we have now)

Suggestion: simply append a counter, or a date, or uniq-id. This is safer, too.

Note that it throws an exception when the attempt fails, so if you don't notice you're not handling errors at all, which is dangerous for a ton of other reasons too.

@laanwj
Copy link
Member Author

laanwj commented Mar 7, 2017

Updated the RPC help, too.

@laanwj
Copy link
Member Author

laanwj commented Mar 7, 2017

Do you have a suggestion that would avoid this usage but still offers the same functionality?

We could make the check even stricter, only allowing writing of files within the data directory, or even better a dumpwallet directory within the data directory. It could even come up with its own unique filename and return that (e.g. #9740). But that has a much larger impact to the API. Could do that for 0.15 but certainly not for backporting.

@paveljanik
Copy link
Contributor

What about this: if there is a file already present, add a timestamp to the file name and save.

@laanwj
Copy link
Member Author

laanwj commented Mar 7, 2017

Yeah that could work...

@laanwj
Copy link
Member Author

laanwj commented Mar 7, 2017

Closing this, feel free to implement a different solution, have no time for this at the moment.

@laanwj
Copy link
Member Author

laanwj commented Sep 22, 2017

Reopening this and rebasing, I think this is basically a good fix, and was closed for unimportant concerns (compared to the problem it solves), and no one picked it up subsequently.

@laanwj laanwj reopened this Sep 22, 2017
@laanwj laanwj force-pushed the 2017_03_walletdump_nooverwrite branch from 47d8fc5 to cc928c5 Compare September 22, 2017 11:51
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if a dumpwallet is executed after this check with the same filename, or the filename is created by other means? IMO we should use fopen with wx mode where x stands for:

File access mode flag "x" can optionally be appended to "w" or "w+" specifiers. This flag forces the function to fail if the file exists, instead of overwriting it. (C11)

and drop exists() test.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not terribly worried about race conditions here, just about overwriting existing files such as the wallet.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the comment should have paranoia label..

@sdaftuar
Copy link
Member

Concept ACK

@promag
Copy link
Contributor

promag commented Sep 22, 2017

And there is also the option to make the filename optional, where the default value is /some/base/path/ + wallet-name + some-timestamp + .extension and return the filename.

Copy link
Contributor

@jnewbery jnewbery left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK, but currently fails to build :(

A few comments inline.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This help text is misleading. The relative path is relative to the directory from where bitcoind was started.

(really I think we should disallow relative paths entirely unless they're relative to some fixed point like the datadir)

Copy link
Member Author

@laanwj laanwj Sep 26, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree relative paths should ideally be relative to the datadir (or refused altogether - at the least we should be consistent about them). However I am not changing that functionality here, and am also not touching this comment here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I don't think this needs such a long comment. Just say we don't allow files to be overwritten for safety.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Meh, better too long than too short.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

filename should be filepath?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that'd make sense.

@laanwj
Copy link
Member Author

laanwj commented Sep 26, 2017

And there is also the option to make the filename optional, where the default value is /some/base/path/ + wallet-name + some-timestamp + .extension and return the filename.

Yes, many other things are possible. I'm not going to do that here. That's the reason I closed this before. However I only want to solve the overwrite problem here, which is not solved by making up filenames, only by refusing to overwrite files.

Prevent arbitrary files from being overwritten. There have been reports
that users have overwritten wallet files this way. It may also avoid
other security issues.

Fixes bitcoin#9934. Adds mention to release notes and adds a test.
@laanwj laanwj force-pushed the 2017_03_walletdump_nooverwrite branch from cc928c5 to 0cd9273 Compare September 26, 2017 14:12
@jnewbery
Copy link
Contributor

Tested ACK 0cd9273

@jnewbery
Copy link
Contributor

Requires release notes (although this is fixing up undefined behaviour, there may be users who currently rely on that behaviour)

@laanwj
Copy link
Member Author

laanwj commented Oct 4, 2017

Requires release notes (although this is fixing up undefined behaviour, there may be users who currently rely on that behaviour)

A release notes change is already part of the PR.

@laanwj laanwj merged commit 0cd9273 into bitcoin:master Oct 4, 2017
laanwj added a commit that referenced this pull request Oct 4, 2017
0cd9273 rpc: Prevent `dumpwallet` from overwriting files (Wladimir J. van der Laan)

Pull request description:

  Prevent arbitrary files from being overwritten by `dumpwallet`. There have been reports that users have overwritten wallet files this way. It may also avoid other security issues.

  Fixes #9934. Adds mention to release notes and adds a test.

Tree-SHA512: 268c98636d40924d793b55a685a0b419bafd834ad369edaec08227ebe26ed4470ddea73008d1c4beb10ea445db1b0bb8e3546ba8fc2d1a411ebd4a0de8ce9120
maflcko pushed a commit to maflcko/bitcoin-core that referenced this pull request Oct 4, 2017
Prevent arbitrary files from being overwritten. There have been reports
that users have overwritten wallet files this way. It may also avoid
other security issues.

Fixes bitcoin#9934. Adds mention to release notes and adds a test.

Github-Pull: bitcoin#9937
Rebased-From: 0cd9273
@maflcko
Copy link
Member

maflcko commented Oct 4, 2017

@laanwj I also pushed this to the backports pull for 0.15.1

@maflcko maflcko added this to the 0.15.1 milestone Oct 4, 2017
codablock pushed a commit to codablock/dash that referenced this pull request Sep 25, 2019
0cd9273 rpc: Prevent `dumpwallet` from overwriting files (Wladimir J. van der Laan)

Pull request description:

  Prevent arbitrary files from being overwritten by `dumpwallet`. There have been reports that users have overwritten wallet files this way. It may also avoid other security issues.

  Fixes bitcoin#9934. Adds mention to release notes and adds a test.

Tree-SHA512: 268c98636d40924d793b55a685a0b419bafd834ad369edaec08227ebe26ed4470ddea73008d1c4beb10ea445db1b0bb8e3546ba8fc2d1a411ebd4a0de8ce9120
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

dumpwallet walletfile overwrite footgun

9 participants