indy-plenum running on Ubuntu 20.04 is running a vulnerable version of sha3_256, issue is CVE-2022-37454
pruneau628 opened this issue · 5 comments
This problem was flagged by Quebec MCN security team.
OS release:
Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal
Indy release:
hi indy-node 1.13.2~rc5 amd64 Indy node
hi indy-plenum 1.13.1~rc3 amd64 Plenum Byzantine Fault Tolerant Protocol
Given the code loading the sha3_256 function in [utils.py](https://github.com/hyperledger/indy-plenum/blob/698b9500ad3a7a15993af72a1c35a406c5673262/state/util/utils.py], line 5-12, we tried this, to check which underlying OS library was used:
$ python3 -v
(...)
>>> import sha3 as _sha3
# /usr/lib/python3/dist-packages/__pycache__/sha3.cpython-38.pyc matches /usr/lib/python3/dist-packages/sha3.py
# code object from '/usr/lib/python3/dist-packages/__pycache__/sha3.cpython-38.pyc'
# /usr/lib/python3.8/__pycache__/hashlib.cpython-38.pyc matches /usr/lib/python3.8/hashlib.py
# code object from '/usr/lib/python3.8/__pycache__/hashlib.cpython-38.pyc'
# extension module '_hashlib' loaded from '/usr/lib/python3.8/lib-dynload/_hashlib.cpython-38-x86_64-linux-gnu.so'
# extension module '_hashlib' executed from '/usr/lib/python3.8/lib-dynload/_hashlib.cpython-38-x86_64-linux-gnu.so'
import '_hashlib' # <_frozen_importlib_external.ExtensionFileLoader object at 0x7f8a833e2430>
import '_blake2' # <class '_frozen_importlib.BuiltinImporter'>
import '_sha3' # <class '_frozen_importlib.BuiltinImporter'>
import 'hashlib' # <_frozen_importlib_external.SourceFileLoader object at 0x7f8a833e2190>
# extension module '_pysha3' loaded from '/usr/lib/python3/dist-packages/_pysha3.cpython-38-x86_64-linux-gnu.so'
# extension module '_pysha3' executed from '/usr/lib/python3/dist-packages/_pysha3.cpython-38-x86_64-linux-gnu.so'
import '_pysha3' # <_frozen_importlib_external.ExtensionFileLoader object at 0x7f8a833e2250>
import 'sha3' # <_frozen_importlib_external.SourceFileLoader object at 0x7f8a8342ceb0>
The last part of those traces clearly show that the underlying c objects are coming from '/usr/lib/python3/dist-packages/_pysha3.cpython-38-x86_64-linux-gnu.so
And this shows that this was installed through an official ubuntu package:
$ dpkg -S /usr/lib/python3/dist-packages/_pysha3.cpython-38-x86_64-linux-gnu.so
python3-sha3: /usr/lib/python3/dist-packages/_pysha3.cpython-38-x86_64-linux-gnu.so
Knowing this, and that the fix is available in ubuntu https://changelogs.ubuntu.com/changelogs/pool/universe/p/pysha3/pysha3_1.0.2-4ubuntu0.1/changelog
We are planning to test this procedure on an ubuntu node:
# apt-mark unhold python3-sha3
# apt update && apt upgrade
## Verify that the last step upgrade at least the faulty package to 1.0.2-4ubuntu0.1
Then for starters, see if the upgraded node manage to reach consensus once restarted.
We will inform this issue of the developments, but any advice on better regression tests methods are welcome.
We did some test on a recently installed indy / ubuntu 20.04 system.
This was more a downgrade scenario, since the upgraded package was in the base image.
The indy system was thus started from scratch, with no transaction but the genesis one.
First good news: with all 4 nodes running with the upgraded package, the cluster started without problem.
Then, the python3-sha3 was downgraded to the vulnerable version on one of the node, and this node reintegrated the cluster with no consesus problem.
This is good news, but we want to do a bit more tests with non-empty ledgers.
Thanks to @lynnbendixsen lending his test system, I did run a few test cases, and consider that we should be safe upgrading the 22.04-based ubuntu indy systems.
Vulnerable system have the 1.0.2-4 python3-sha3 installed, while the non-vulnerable ones are updated to at least version 1.0.2-4ubuntu0.1.
To run the following tests I provisionned a 100K domain nym transactions, to make sure that catch-up would happen, and also kept adding new NYMs while doing the various test cases:
- Have 3 downgraded nodes, and one upgraded one, and do a restart with the upgraded one
- Have 3 downgraded nodes, and one upgraded one, and do a restart with full catch-up (with the data directory wiped)
Repeat the previous test case, but by upgrading one more node.
Repeat until all nodes have been upgraded.
I'm happy to announce that the 4-nodes indy cluster recovered in all the situations I put it through.
So @lynnbendixsen and @WadeBarnes, unless someone comes up with more pertinent test case, I recommend that all the indy nodes running ubuntu 20.04 be upgraded to the latest release.
Here is a (pseudo) script:
apt-mark unhold python3-sha3
apt update && apt upgrade -y
apt-mark hold python3-sha3
systemctl restart indy-node
Thanks @pruneau628 and @lynnbendixsen
Yes, thanks @pruneau628 and @lynnbendixsen. I verified on a test cluster as well, the only change I made to the script was to run apt install python3-sha3 instead to only update the python3-sha3 package and avoid upgrading other Ubuntu packages outside of our patch/update cycle.
@pruneau628 I've addressed this through #1679. Are you ok if we close this issue?