Responsible Disclosure
As you may be aware, Bitcoin Gold has a Responsible Disclosure policy listed on the website, which is basically a (bug) bounty program for reporting security vulnerabilities in our stable software versions or infrastructure.
It allows people to safely report an issue to us, and if they follow the rules set out in the Responsible Disclosure policy, we will not take any legal action against them in regard to the report (hacking is still illegal).
The Report
Through the end of March, we received only false reports of “non-existing” issues, which we rejected. However, we recently received the first report which our SYSOPS and CERT team could accept. Although the security issue was very minor, we acted on it directly.
It was a DLL vulnerability that affects Bitcoin and all coins that use Bitcoin’s installer methods (including BTG.) We used the fix in our recent Network Upgrade and shared it for the rest of the community’s benefit.
Timeline:
| Date | |
|---|---|
| 27 March | Initial Report by Kushal Arvind Shah from Fortinet’s FortiGuard Labs |
| 28 March | Initial assessment from SYSOPS/CERT |
| 28 March | Started incident team with SYSOPS, CERT, Board and lead developer |
| 01 April | Classified the issue as LOW on usability and MEDIUM on impact |
| 02 April | Cause of issue identified and started work on fix |
| 11 April | Sent reward from the RD program to the Reporter |
| 27 April | Committed the code into master branch |
| 29 April | Added the code onto initial builds |
| 24 May | Reported the official fix of the issue |
| 04 Jun | Received confirmation from Reporter that the issue was resolved |
You might have noticed there was a sizable time span between the report and the fix. That is correct: it takes time to build a fix, especially if the issue stems from a third party module and your entire build process is wrapped around it. It took a long time to test, build, and test again before we could implement the fix as a replacement for our current build process.
The Fix
The specific issue addressed by the bug was as follows: Bitcoin Gold uses the NSIS Installer module, which basically wraps our code into a nice install package for people. Our code uses the v2.46 NSIS installer module, the same as in the Bitcoin source. This outdated code had a bug in LoadLibrary: by default, it looks in the current directory of the process and into the Folder of the Executable. This is bad (especially in common use case when users execute our installer from the downloads folder) because an attacker is able to drop a DLL into the Folder of the Executable and give themselves high privileges. To try it out, just place a fake shfolder.dll (which brings up a message box in its DllMain) in the same directory as an NSIS installer and run the installer to see the message box appear. This bug has recently been found in many products and is called ‘.DLL sideloading’ or ‘.DLL hijacking’. Only Windows 7 and very old builds of Windows 8 are vulnerable. An updated Windows 8.1 or any Windows 10 system is not vulnerable.
Although the fix may appear easy (just install the new version 3.03 NSIS installer module!), it is, unfortunately, not that simple. With deterministic builds, we have to make sure the installer matches our code, which involves a lot of trial and error. Also, with our upcoming Upgrade hardfork and another update in the code, all updates needed to be added into the latest releases (as they are mandatory upgrades.)
Our developers did the careful work necessary to implement the new module into the existing build process before our next release. Any developer that is interested in how we resolved the issue can find our fix on our GitHub repo code commit, Switch to NSIS 3.03 (borrowed some code from TOR project).
The (low) Risk
To be clear, your system had to be compromised in advance for the attacker to have used this vulnerability. The installer software was not compromised, nor was our code modified or hacked. An attacker had to download a malicious .DLL file and put it in the same folder where you downloaded and run the installer. The Bitcoin Gold code, daemon and cli are not affected, nor is any Linux or Windows system (8/10) that is up-to-date. Even if you are running Windows 7, it’s unlikely that an attacker would have been able to download a malicious .DLL file into the right folder at the same moment as you launched the installer. And users would only install a (new) version once on their system.
Our recommendation: remove any and all previously downloaded installers and only use the latest version from our website or Git repository.
Because this fix was implemented well before our recent Network Upgrade on July 3rd, everyone who downloaded our software or code in preparation for the Upgrade was safe from this vulnerability.
It’s important to note that this issue is not specific to Bitcoin Gold: it can affect any coin that uses Bitcoin’s code as a basis. Some repositories, including Bitcoin itself, are currently vulnerable to this issue.
To ensure awareness of the issues and the fix, we submitted our work to the Bitcoin code repository in this Pull Request: Switch to NSIS 3.03 to avoid DLL hijacking.
Credits
The BTG team would like to thank the original Reporter (Shah from FortiGuard Labs), the TOR Project (where helpful code was sourced), and we’d like to call out the efforts of our SYSOPS and DEV teams, who managed the issue and the resolution for us. We’re happy to be able to contribute back to the Bitcoin project and provide a fix which can potentially be used by multiple projects which rely on the Bitcoin codebase.
Supporting the ecosystem,
The Bitcoin Gold Organization
#1CPU1VOTE