Security Vulnerabilities with pod-sweper

[tmas-definitive]

Helm Chart Version

1.3.1

What step the error happened?

None

Relevant information

Our internal security scans have detected to critical vulnerabilities with airbyte-pod-sweeper. This has been active in versions 1.1.0, 1.2.0, 1.3.0, 1.3.1. I have been unable to upgrade further due to issues introduced by the helm releases completely breaking airbytes usability. The vulnerabilities were assessed by GCP SCC. I've emailed security @ airbyte but this is a fairly urgent issue that needs to be addressed if it isn't already fixed in 1.5.1. I will keep trying to upgrade my deployment to see if it resolves the issue

Relevant log output

[CRITICAL] Vulnerability: gke_runtime_os_vulnerability
Project <project> container Cluster <cluster>
Deployment airbyte-pod-sweeper in ns airbyte
An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINT_MAX equals SIZE_MAX).


[CRITICAL] Vulnerability: gke_runtime_os_vulnerability
Project <project> container Cluster <cluster>
Deployment airbyte-pod-sweeper in ns airbyte
An issue was discovered in libexpat before 2.6.3. nextScaffoldPart in xmlparse.c can have an integer overflow for m_groupSize on 32-bit platforms (where UINT_MAX equals SIZE_MAX).

[marcosmarxm]

@wennergr cc

[tmas-definitive]

Managed to get 1.5.1 deployed in our dev environment, seeing the same error but not longer on the sweeper pod

[CRITICAL] Vulnerability: gke_runtime_os_vulnerability
Project container Cluster []
An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINT_MAX equals SIZE_MAX).

[CRITICAL] Vulnerability: gke_runtime_os_vulnerability
Project container Cluster []
An issue was discovered in libexpat before 2.6.3. nextScaffoldPart in xmlparse.c can have an integer overflow for m_groupSize on 32-bit platforms (where UINT_MAX equals SIZE_MAX).

Unsure if this is because the sweeper pod is spun up, runs, then spins down OR if the processes of sweeper are tied behind another pod in 1.5.1. In any case, where this process lives still seems to have the vulnerability.

Seems like it may be an issue in the underlying OS base image if that helps figure out what's going on