build CVE-susceptible images

[willcl-ark]

• [x] v0.21.1: link
• [x] v0.20.0: link
• [x] v0.19.2: link
• [x] v0.17.0: link
• [x] v0.16.1: link
• [ ] v0.14.3

[pinheadmz]

duplicate? https://github.com/bitcoin-dev-project/warnet/issues/356

[willcl-ark]

Kind of, I'd prefer to keep this as it's own issue though as I plan on adding it to a project page

[willcl-ark]

CVE-2018-17144: critical inflation and crash bug

https://bitcoincore.org/en/2018/09/20/notice/

In Bitcoin Core 0.15.X, 0.16.0, 0.16.1, and 0.16.2, any attempts to double-spend a transaction output within a single transaction inside of a block where the output being spent was created in the same block, the same assertion failure will occur (as exists in the test case which was included in the 0.16.3 patch).

However, if the output being double-spent was created in a previous block, an entry will still remain in the CCoin map with the DIRTY flag set and having been marked as spent, resulting in no such assertion. This could allow a miner to inflate the supply of Bitcoin as they would be then able to claim the value being spent twice.

Affected versions:

https://bitcoincore.org/bin/insecure-CVE-2018-17144/

• 0.15.X
• 0.16.0
• 0.16.1
• 0.16.2

CVE-2017-18350: buffer overflow vulnerability in SOCKS proxy server

https://bitcoincore.org/en/2019/11/08/CVE-2017-18350/

allows a malicious SOCKS proxy server to overwrite the program stack on systems with a signed char type (including common 32-bit and 64-bit x86 PCs).

To be vulnerable, the node must be configured to use such a malicious proxy in the first place. Note that using any proxy over an insecure network (such as the Internet) is potentially a vulnerability since the connection could be intercepted for such a purpose.

Upon a connection request from the node, the malicious proxy would respond with an acknowledgement of a different target domain name than the one requested. Normally this acknowledgement is entirely ignored, but if the length uses the high bit (ie, a length 128-255 inclusive), it will be interpreted by vulnerable versions as a negative number instead. When the negative number is passed to the recv() system call to read the domain name, it is converted back to an unsigned/positive number, but at a much wider size (typically 32-bit), resulting in an effectively infinite read into and beyond the 256-byte dummy stack buffer.

Versions

• 0.7.0

• < 0.15.1

CVE-2015-6031: MiniUPnP Internet Gateway Device Protocol XML Parser Buffer Overflow

https://bitcoincore.org/bin/insecure-CVE-2015-6031/README.txt

and

https://bitcoin.org/en/alert/2015-10-12-upnp-vulnerability

Versions before 1.9.20151008 of the miniupnpc library are vulnerable to a buffer overflow in the XML parser during initial network discovery. The vulnerable code triggers at startup of Bitcoin Core if UPnP is enabled.

It has been verified that the vulnerability can be used to crash the application at startup by running a malicious UPnP server on the local network.

To have more connectable nodes, the Bitcoin Core executables distributed by bitcoin.org include the miniupnpc library and have always had UPnP functionality enabled by default, to forward the P2P port.

This applies to the distributed executables only, not those built from source or from distribution provided packages. Self-built executables have UPnP disabled by default, unless --enable-upnp-default was provided to the configure script.

Versions

https://bitcoincore.org/bin/insecure-CVE-2015-6031/

• 0.8.6
• 0.9.0
• 0.9.1
• 0.9.2
• 0.9.2.1
• 0.9.3
• 0.9.5
• 0.10.0
• 0.10.1
• 0.10.2
• 0.11.0

[willcl-ark]

More versions now available:

https://bitcoincore.org/en/blog/

So looks like v0.20.0, v0.19.2, v0.17.2 and v0.14.3 should start off as the prime targets (in that order of difficulty, I guess)

[mplsgrant]

I updated the 12 node graph using the v0.19.2 images and got the following results:

$ warcli network start test/data/12_node_bitcoin_19_02.graphml --force

$ kubectl logs pod/warnet-tank-000000
/entrypoint.sh: setting data directory to /root/.bitcoin

Error loading shared library libboost_chrono.so.1.72.0: No such file or directory (needed by /usr/local/bin/bitcoind)
Error relocating /usr/local/bin/bitcoind: _ZN5boost6chrono12system_clock3nowEv: symbol not found
Error relocating /usr/local/bin/bitcoind: _ZN5boost6chrono12steady_clock3nowEv: symbol not found

[willcl-ark]

I updated the 12 node graph using the v0.19.2 images and got the following results:

$ warcli network start test/data/12_node_bitcoin_19_02.graphml --force

$ kubectl logs pod/warnet-tank-000000
/entrypoint.sh: setting data directory to /root/.bitcoin

Error loading shared library libboost_chrono.so.1.72.0: No such file or directory (needed by /usr/local/bin/bitcoind)
Error relocating /usr/local/bin/bitcoind: _ZN5boost6chrono12system_clock3nowEv: symbol not found
Error relocating /usr/local/bin/bitcoind: _ZN5boost6chrono12steady_clock3nowEv: symbol not found

This should be fixed now

[willcl-ark]

This is done in #498

[willcl-ark]

Closing as complete