xz-utils vulnerability in ADAravis support module

[subinsaji]

Following up from the EPICS collaboration meeting, Ralph Lange and others from the community talked about the security of ibek-support and some reservations about using it.

Ralph pointed out the xz-utils backdoor that was recently discovered. Would the K8s CVE scanning know about this vulnerability and what about ibek-support picking this up or other vulnerabilities?

[gilesknap]

In response to this I intend to add some documentation for epics containers that discusses supply chain security.

• if you use Kubernetes then you can install a CVE monitor. At DLS we have stackrox which creates reports on vulnerabilities and generates alerts for critical issues.
• xz-utils has not been flagged because it is not used at runtime stage, only during container build stage. Therefore it does not appear in the running containers on the cluster.
• if the backdoor did insert malicious code and it got copied into runtime then stackrox would pick that up.
• in general containers' attack surface is very much smaller than an os because they are only running a single process
• if you are not using Kubernetes you could choose to use your own container registry and have a CVE monitor scan that

[gilesknap]

@subinsaji I don't think we can close this.

Even if there is no vulnerability any more, I need to address the question of how this is mitigated in the world of containers and document it so that we can reassure potential users.

[gilesknap]

@subinsaji however I'm interested in why you closed it - have you looked at the CVE?

[subinsaji]

Hi @gilesknap. I have not looked at the CVE and my mistake as I should not have closed this issue.

[gilesknap]

Here is a trascript of the demo I intend to run at the epics-containers workshops that goes into this issue.

StacksRox scans all of the running containers in the cluster for Common Vunerabilities and Exposures (CVEs.)​

It can be set up to alert users when significant problems are detected.​

I thought we'd take a look at a specific example to illustrate how security in containers looks.​

In our ioc-adaravis container that we use for GigE Cameras there is a bit of suspect script – lets take a look at the reasons why this is not in fact an issue.​

• Open ioc-adaravis look in ibek-support/ADAravis/install.sh​
• This is the script that is run when we install the adaravis support module into our container​
• It uses xz-utils which recently was found to be adding a back door to ssh – a really significant issue​
• First notice that we are only using it in the developer target – what we run on the cluster is typically the runtime stage and you can see that we don't install xz-utils there, it is just used to help compile the aravis library ​
• For the purpose of this demo I did use the developer version of the container for p47s overview camera – we would sometimes do this if we are trying to debug an issue that only occurs in cluster.​
• Therefore I can take a look in stacksrox and see if the container is flagged – and yes it is!​
• But when I drill into that it is only moderate issues I'm seeing ​
• Let's look up the CVE in question https://www.uptycs.com/blog/threat-research-report-team/xz-utils-backdoor-vulnerability-cve-2024-3094 ​
• Apparently it is affecting 5.5.1alpha-0.1 to 5.6.1-1 version of xz-utils – so lets get a shell inside our container and see if it is affected​ (I can do this from the kubernetes dashboard - or using kubectl command line)
• OK we are running 5.2.5-2ubuntu1 which should be fine and that is why stacksrox has not flagged it​
• In fact if we scroll down the page we see that released ubuntu versions are unaffected we base epics-containers on ubuntu LTS versions​
• But, even if stacksrox had flagged it and the compromised version was in our container we would still be safe.​
• That is because although a container may have a image of an OS it does not run an OS – it is just running the one IOC process. Therefore there is no ssh-server to be compromised here.​
• Even If we were running an ssh server we would only be vunerable if the ssh port were open to the host and or the attack came from inside the cluster itself. ​
• Looking around stacksrox I do see that one of the containers I have deployed is flagged with a critical denial of service vunerability​
• epics-opis which serves bob files to phoebus is using a special version of nginx that works in a low privilege container and it is based on an old version​
• We have fixed the issue that required use of this old version – so I'll update the container version soon.​

If you did not have Kubernetes but were using containerized IOCs you could scan your container registry or cache in a similar fashion with one of these tools:​ https://www.practical-devsecops.com/top-container-security-tools/​