bitcoin / bitcoin

Is your feature request related to a problem? Please describe.

-startupnotify and -shutdownnotify configuration parameter accept shell commands to be executed after Bitcoin Core starts/shutdown

One is still WIP and not merged: #23395

This provides options for attackers to target new users of Bitcoin Core and one example which involves some social engineering is explained in #23395 (comment)

Describe the solution you'd like

I am not sure how this is used currently by different users and projects however if reading notifications about start/shutdown is the goal maybe a file with name notifications.dat with below format can help:

lastshutdown=1635786273
lastrestart=SOMEUNIXTIME
currentstate=shutdown

Initially suggested this solution in #23395 (comment)

Describe alternatives you've considered

Educate users about misuse of *notify options

maybe a file with name notifications.dat

This won't fix the issue for block and tx notify.

Yes I missed blocknotify and walletnotify. Maybe notifications.dat file can have more information:

lastshutdown=1635786273
lastrestart=SOMEUNIXTIME
currentstate=shutdown

lasttx=txid
lastblock=blockhash

The goal of notifications is to avoid polling, so making them only usable via polling doesn't seem useful.

Users can check notifications.dat for any changes without polling:

https://stackoverflow.com/questions/5738442/detect-file-change-without-polling

https://stackoverflow.com/questions/182197/how-do-i-watch-a-file-for-changes

I did some research and other alternatives to solve this problem are:

Restrict runCommand used in

bitcoin/src/init.cpp

Line 182 in acb45ad

std::thread t(runCommand, cmd);

It should only use local resources and network.

Document a security recommendation somewhere that users should restrict scripts and commands in the shell/system used for bitcoind to avoid running potentially unsafe scripts.

It is possible in PowerShell using Set-ExecutionPolicy for scripts. Not sure about Linux and other OS so asked a question: https://superuser.com/questions/1685188/restrict-commands-in-linux-shell

It should only use local resources and network.

I think a use case of -alertnotify is to allow users to send notifications to their own mobile device when a long fork is detected. I am not sure if restricting runCommand entirely is the best approach.

Maybe creating a new doc with a list of security best practices?

How about this?

Use a new setting in settings.json file notifypolicy which is 0 by default (restricted) and can be set to 1 (unrestricted)

Maybe creating a new doc with a list of security best practices?

Until things are changed, we should document best practices. I am not sure which doc is best for this.

A proof of concept video how *notify option can be exploited for Windows users:

Since the shortcut for testnet that is created by default has a config parameter for -testnet it will be easy to convince victim that similar options can be used for mainnet
Which *notify will the attacker use? Depends on the victim or things attacker is trying to achieve. We are anyway providing different config params which can be used as required.
In this PoC I have used -startupnotify as an example which open mspaint when bitcoin-qt starts.

notify-bitcoin.mp4

Other ways to use these config params effectively:

Use combination of parameters. Example: -startupnotify will be used for sending an email about new victim and start reverse shell, -walletnotify sends an email so that attacker knows victim's wallet is doing some transactions and -shutdownnotify to send notification email that victim is no longer using bitcoin-qt
Use config parameter based on victim. Example: Alice (victim) is searching online for some help regarding notifications about her wallet transactions. In this case, Bob(attacker) can help him using -walletnotify config parameter
Use config parameter based on attack. Example: -walletnotify will be more helpful when trying to convince victims for an airdrop that requires wallet registration
Some websites already sell wallet.dat files to scam users. They can do more than just scamming by asking users to use one of the config parameter for using the wallet file.

Why is this different from just asking victims to run any random command?

We should not underestimate social engineering.
All the config parameters are documented in this repository and different websites with no security recommendations. Easier to convince victims that these are legit options.
A newbie can be convinced to run bitcoin-qt -*notify=X however he might not run just X or other ways to run multiple commands in different terminals.
Bitcoin has no official support or website so everyone learns things from different places
All options provided in Bitcoin Core or Knots are considered secure. If someone already has the software installed or downloads from legit source, it still makes them vulnerable to such attacks and attackers don't even need to use any malware.

This really isn't in the scope of being an issue; the functions designed to execute commands will very obviously be able to be used to execute commands. If users are able to be duped into adding backdoors on their computers through being guided to modifying their bitcoin.conf, they are vulnerable to much lower hanging social engineering fruit. To "fix" this would involve removing practically every option, fee rate could be used to destroy user funds, the RPC interface options could cause a user to bind a intentionally vulnerable RPC interface, etc.

This really isn't in the scope of being an issue; the functions designed to execute commands will very obviously be able to be used to execute commands. If users are able to be duped into adding backdoors on their computers through being guided to modifying their bitcoin.conf

What is the scope for creating issues?

Why do such functions exist in this repository in the first place?

This is not about editing a config file. This is about an option that gives you the freedom to run any code. Have you read about doc files and macros being used by attackers? Sure users are responsible for opening docs from untrusted sources. Is that feature helping users or attackers since years? Can you share some examples of financial applications that allow you to run any code with such config params?

Can we add this feature in few RPC commands as well?

What is the scope for creating issues?

Not in the scope of reasonable concern, the same way we aren't concerned that bash can result in arbitrary code execution, or that file system access might expose a wallet file. There's no expectation that a system which is willingly compromised by its user can be made secure by the software running on it.

Why do such functions exist in this repository in the first place?

Bitcoin has interfaces like -walletnotify and -blocknotify to allow for easy, reasonable interrupts for external processes that do not require polling. They're largely historical in their creation, but user scripts and systems rely on them. There has never been any reported situation of them being misused to my knowledge, and I doubt such a contrived situation has ever been envisioned.

Can we add this feature in few RPC commands as well?

RPC is polling, which would not be a suitable replacement.

Not in the scope of reasonable concern

Thanks for sharing your opinion

There has never been any reported situation of them being misused to my knowledge, and I doubt such a contrived situation has ever been envisioned.

I was not aware we fix issues related to security after few users are exploited.

Still looking for examples in other financial applications that allow you to run any external code to make things easier.

I agree that this is an interesting social engineering attack. Not sure if there's much to do besides a documentation approach. But we should be open to more discussion and ideas of course.

I agree that this is an interesting social engineering attack. Not sure if there's much to do besides a documentation approach. But we should be open to more discussion and ideas of course.

@Rspigler added documentation in #23850

Crossposting from #23850 (review)

I disagree with the premise here that -*notify commands are unsafe and we should be exploring alternatives. I also think it's misleading to imply via warnings that these options are somehow more unsafe than others. The real risk is users making any change to their configuration ignorantly or accepting changes from a malicious attacker. There is no additional risk introduced by the -*notify options.

@Rspigler: I agree that this is an interesting social engineering attack. Not sure if there's much to do besides a documentation approach.

This type of social engineering attack is not specific to -*notify options and could be executed on other combinations of config options. If we feel this is an unaddressed threat, I'd suggest a more general warning against making configuration changes ignorantly and against accepting configurations from other sources.

I also think it's misleading to imply via warnings that these options are somehow more unsafe than others.

It is not misleading. These are the only command line options that work with bitcoind and can be used to run any command/script based on some event.

Also this is a known issue according to: #23395 (comment)

Please do not call everything misleading just because we have different opinion. I have no incentives to mislead bitcoin users. I have tried my best to suggest alternative solutions which are secure but if people don't agree with them we at least need documentation.

There is no additional risk introduced by the -*notify options.

Not true.

If we feel this is an unaddressed threat, I'd suggest a more general warning against making configuration changes ignorantly and against accepting configurations from other sources.

Can you suggest a general warning? I asked in the pull request as well and think it is already a general warning with no details about the attacks.

Please do not call everything misleading just because we have different opinion.

It is being called misleading because it is in fact, misleading. There is no big vulnerability here, there's nothing specific about these commands which make them more dangerous than anything else a user can be convinced to do, a user that can be convinced to compromise their own system will always be able to regardless of the software they are running.

Code execution because -startupnotify can be added to a windows shortcut is just a ludicrous thing to be trying to describe as a cause for concern; the whole shortcut field is a command, you can already execute anything in there that you want if you can freely edit it without Bitcoin Core even being installed on the system.

there's nothing specific about these commands which make them more dangerous than anything else a user can be convinced to do, a user that can be convinced to compromise their own system will always be able to regardless of the software they are running.

Maybe read the documentation about how these command line options work

Code execution because -startupnotify can be added to a windows shortcut is just a ludicrous thing to be trying to describe as a cause for concern; the whole shortcut field is a command, you can already execute anything

I had requested you to share examples of financial applications that allow you to trigger scripts based on events like start, shutdown, transaction etc. You failed to do it and the only reason I can add something in bitcoin-qt shortcut and it works is because there exists a code for it.

the only reason I can add something in bitcoin-qt shortcut and it works is because there exists a code for it.

No, you could just as easily replace the shortcut command to run your script directly, and then have your script launch (and possibly wait for) the real program.

No, you could just as easily replace the shortcut command to run your script directly

Run XYZ
Run bitcoind -startupnotify=XYZ

I consider 1 and 2 different.

But they're not really.

bitcoind.exe & malware.exe is a valid shortcut in Windows, and looks much less suspicious too.

bitcoind.exe & malware.exe is a valid shortcut in Windows, and looks much less suspicious too.

This won't work in windows shortcut target
It is more suspicious compared to something wrapped in *notify options provided by bitcoin core
This will not provide me option to run a command based on events like received transaction in wallet

If Mallory is able to convince a user to write arbitrary commands in a Windows shortcut, their system is already owned by Mallory.

I appreciate that my tone here is not so forgiving, but I really do think that this is a complete non-issue.

It should only use local resources and network.

This doesn't work either because I own your system. I can just get you to write a script "ownme.sh" which rm's your harddrive and then -walletnotify ownme.sh. Hell, I can probably use runCommand to write the script for me and then execute it, are we considering 'echo' to be a local command?

If Mallory is able to convince a user to write arbitrary commands in a Windows shortcut, their system is already owned by Mallory.
I appreciate that my tone here is not so forgiving, but I really do think that this is a complete non-issue.

I appreciate you took few minutes to write this. You can take more time to read everything before writing more comments. This is a KNOWN ISSUE.

This doesn't work either because I own your system.

THIS WORKS for everyone trying some social engineering in their attacks as mentioned in OP.

I can just get you to write a script "ownme.sh" which rm's your harddrive and then -walletnotify ownme.sh.

You can do things what you are capable of based on options available and victims.

I've read the whole thread and disagree with the fundamental position that it is somehow "more suspicious" to write some equivalent of "rm -rf /" vs. "-walletnotify rm -rf /", whatever "suspicious" means in this context.

If anything I'd argue the opposite and say that most users would be more careful when writing arbitrary code or making modifications on things relating to their Bitcoin client (money! alarm bells!) vs the commandline or whatever.

But that's not the point. I personally derive benefit from these commands being usable and would not appreciate them being gimped for the sake of some contrived scenario of a feckless user downloading some random Bitcoin Core shortcut package or typing random stuff into their machine from a bad website.

Given that I'm just repeating the previous arguments I doubt we're going to get any further on this, so I'll leave it there and just say that I don't want this.

But that's not the point. I personally derive benefit from these commands being usable and would not appreciate them being gimped for the sake of some contrived scenario of a feckless user downloading some random Bitcoin Core shortcut package or typing random stuff into their machine from a bad website.

I can assure you based on my experience in this repository, these options are not going to be removed based on 1 post by me on mailing list.

And I still disagree with your opinion.

The options could have more explanatory names which tell the (hapless, clueless, obedient, foolish) user that it doesn't "just" notify but actually runs code. Perhaps instead of "[X]notify" the options should be named "ExecuteOn[X]" or "execute_on[X]".

The options could have more explanatory names which tell the (hapless, clueless, obedient, foolish) user that it doesn't "just" notify but actually runs code. Perhaps instead of "[X]notify" the options should be named "ExecuteOn[X]" or "execute_on[X]".

I agree, part of the problem lies with name but even if we change names without documentation it will not be helpful.

So documentation is more important which was NACKed by 2 in #23850

We all agree these options are not vulnerability by default, I never mentioned them as one but they can be abused which a few agreed to, lets at least document issues and see how things work.

Perhaps instead of "[X]notify" the options should be named "ExecuteOn[X]" or "execute_on[X]

This does not meaningfully change the ridiculous situation that a user is duped into changing their windows shortcut to somehow include malware using startupnotify, they aren't going to know what execute_on means either. Your suggestion breaks functionality which has been in the software since 0.6, and makes absolutely no improvement to the non-existent threat.

Users should never make config changes which they do not understand. Furthermore, users should always be wary of accepting any config changes provided to them by another source (even if they believe they understand them).

I agree with this. I would ACK a new PR to add this to bitcoin-conf.md; I don't think anything else is needed after reading all arguments.

Making changes in config file is different from requesting to restart with one more command line parameter.
In an ideal world we would not expect anyone to make changes based on suggestions from others, however they do it everyday on IRC, Reddit, Stackexchange, Twitter etc. Example: https://bitcoin.stackexchange.com/questions/111319/how-to-properly-monitor-incoming-transactions-for-a-specific-address-with-bitcoi/
Even if we ignore social engineering involved, this option can be used by malware as well.

Currently I am exploring using this in combination with other known issues so that no social engineering is required. If I find anything interesting I will report it to security@bitcoincore.org

As far as documentation is concerned, I tried it in #23850 and I can try rephrasing few things:

+### Command-line options and Security

+`-*notify` configuration parameters accept shell commands to be executed based on different events. These are useful +for notifying the user of certain events; however, they can be misused by malicious software or social engineering +attacks. Restrict scripts in the shell/system used for bitcoind or create alerts to avoid running potentially unsafe scripts.

Closing this for now.

Use notifications.dat for -*notify