<p>The chaincode image and container are created automatically when the chaincode is installed and instantiated on a channel in Hyperledger Fabric v1.4. When the Hyperledger Fabric network is constructed and deployed using Kubernetes, normally, the existence of the chaincode container is not known to Kubernetes. The chaincode container does not have any resource restriction imposed by Kubernetes and runs natively on Docker. In such a scenario, what are the possible types of attacks that be executed using the User defined chaincode and what will their impact be on the Host System, the Kubernetes Cluster and the Hyperledger Fabric v1.4 Network as a whole?</p>
<p>So far, I have been able to create memory leaks using the chaincode which has been able to hog up the memory of the host system on which the chaincode container is running and successfully hanged the system for a while till the linux kernel detected this issue and killed the chaincode process. In some cases, the node also crashed, and the peer was scheduled on another node in the cluster causing the other node also to crash.</p>
<p>I have also tried performing complex calculations in an infinite loop. This resulted in higher CPU requirements by the chaincode process which basically brought down the CPU time available for other processes thereby reducing the throughput/efficiency of the host system.</p>
<p>I am looking for more such issues that can be introduced using User defined chaincode in Hyperledger Fabric v1.4 so that I can explicitly handle these issues to boost the performance and security of my Hyperledger Fabric v1.4 Network.</p>

<p>As far as the problems you've described, these are standard denial of service sorts of attacks, which can usually be mitigated by putting <a href="https://docs.docker.com/config/containers/resource_constraints/" rel="nofollow noreferrer">resource constraints</a> onto the container.</p>
<p>However, the primary problem with running docker containers in Kubernetes is that running a docker daemon in a pod requires that the pod be a <a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy/#:%7E:text=Privileged%20%2D%20determines%20if%20any%20container,processes%20running%20on%20the%20host." rel="nofollow noreferrer">privileged pod</a>.  If an attacker has access inside of a privileged pod, the pod can access resources of the host for the pod, and potentially interfere with other pods executing on the host.</p>
<p>Of course, Docker endeavors to isolate containers from the host, but <a href="https://unit42.paloaltonetworks.com/breaking-docker-via-runc-explaining-cve-2019-5736/" rel="nofollow noreferrer">vulnerabilities have been discovered</a> and hence it is possible, that a user chaincode executing in the docker daemon could escape, and gain access to the pod.  From there, because the pod is privileged, general privileged pod attacks apply.</p>
<p>Starting in Fabric v2.0.0, there are <a href="https://hyperledger-fabric.readthedocs.io/en/release-2.0/cc_launcher.html" rel="nofollow noreferrer">external builders</a> which allow you to build your chaincode in userspace, rather than depending on a docker daemon.  You could use a number of tools for building a container image in userspace, then deploy it as a pod into your k8s cluster, you could run the process locally, or a use another deployment scheme.  The key being, that because the builder does not need to depend on docker, the pod does not need to be privileged, and most security concerns disappear.</p>
