Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Twistlock scanner detected security vulnerabilities in opm v1.28.0 #1126

Closed
venkataramanam opened this issue Jul 18, 2023 · 1 comment
Closed

Comments

@venkataramanam
Copy link

There are quite a lot of security vulnerabilities detected in opm version 1.28.0 binary. Could we have the following fixed please ?

severity cve link hasfix status packageType packageName packageVersion packagePath description
M PRISMA-2023-0056 sirupsen/logrus#1370 Y fixed in v1.9.3 go github.com/sirupsen/logrus v1.8.1 /usr/bin/opm The github.com/sirupsen/logrus module of all versions is vulnerable to denial of service. Logging more than 64kb of data in a single entry without newlines causes the log writer function to hang indefinitely.
C CVE-2023-29405 https://nvd.nist.gov/vuln/detail/CVE-2023-29405 Y fixed in 1.20.5, 1.19.10 app go 1.19.9 /usr/bin/opm The go command may execute arbitrary code at build time when using cgo. This may occur when running 'go get' on a malicious module, or when running any other command which builds untrusted code. This is can by triggered by linker flags, specified via a '#cgo LDFLAGS' directive. Flags containing embedded spaces are mishandled, allowing disallowed flags to be smuggled through the LDFLAGS sanitization by including them in the argument of another flag. This only affects usage of the gccgo compiler.
C CVE-2023-29402 https://nvd.nist.gov/vuln/detail/CVE-2023-29402 Y fixed in 1.20.5, 1.19.10 app go 1.19.9 /usr/bin/opm The go command may generate unexpected code at build time when using cgo. This may result in unexpected behavior when running a go program which uses cgo. This may occur when running an untrusted module which contains directories with newline characters in their names. Modules which are retrieved using the go command, i.e. via 'go get', are not affected (modules retrieved using GOPATH-mode, i.e. GO111MODULE=off, may be affected).
C CVE-2023-29404 https://nvd.nist.gov/vuln/detail/CVE-2023-29404 Y fixed in 1.20.5, 1.19.10 app go 1.19.9 /usr/bin/opm The go command may execute arbitrary code at build time when using cgo. This may occur when running 'go get' on a malicious module, or when running any other command which builds untrusted code. This is can by triggered by linker flags, specified via a '#cgo LDFLAGS' directive. The arguments for a number of flags which are non-optional are incorrectly considered optional, allowing disallowed flags to be smuggled through the LDFLAGS sanitization. This affects usage of both the gc and gccgo compilers.
H CVE-2023-29403 https://nvd.nist.gov/vuln/detail/CVE-2023-29403 Y fixed in 1.20.5, 1.19.10 app go 1.19.9 /usr/bin/opm On Unix platforms, the Go runtime does not behave differently when a binary is run with the setuid/setgid bits. This can be dangerous in certain cases, such as when dumping memory state, or assuming the status of standard i/o file descriptors. If a setuid/setgid binary is executed with standard I/O file descriptors closed, opening any files can result in unexpected content being read or written with elevated privileges. Similarly, if a setuid/setgid program is terminated, either via panic or signal, it may leak the contents of its registers.
H CVE-2022-41723 https://nvd.nist.gov/vuln/detail/CVE-2022-41723 Y fixed in 0.7.0 go golang.org/x/net v0.4.0 /usr/bin/opm A maliciously crafted HTTP/2 stream could cause excessive CPU consumption in the HPACK decoder, sufficient to cause a denial of service from a small number of small requests.
H PRISMA-2022-0227 emicklei/go-restful#497 Y fixed in v3.10.0 go github.com/emicklei/go-restful/v3 v3.8.0 /usr/bin/opm github.com/emicklei/go-restful/v3 module prior to v3.10.0 is vulnerable to Authentication Bypass by Primary Weakness. There is an inconsistency in how go-restful parses URL paths. This inconsistency could lead to several security check bypass in a complex system.
M CVE-2023-28842 https://nvd.nist.gov/vuln/detail/CVE-2023-28842 Y fixed in 23.0.3, 20.10.24 go github.com/docker/docker v20.10.14 /usr/bin/opm Moby
M CVE-2023-28841 https://nvd.nist.gov/vuln/detail/CVE-2023-28841 Y fixed in 23.0.3, 20.10.24 go github.com/docker/docker v20.10.14 /usr/bin/opm Moby is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (dockerd), which is developed as moby/moby is commonly referred to as Docker. Swarm Mode, which is compiled in and delivered by default in dockerd and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code. The overlay network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes. Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authen
H CVE-2023-28840 https://nvd.nist.gov/vuln/detail/CVE-2023-28840 Y fixed in 23.0.3, 20.10.24 go github.com/docker/docker v20.10.14 /usr/bin/opm Moby is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (dockerd), which is developed as moby/moby, is commonly referred to as Docker. Swarm Mode, which is compiled in and delivered by default in dockerd and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code. The overlay network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes. Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic pr
H CVE-2023-2253 https://nvd.nist.gov/vuln/detail/CVE-2023-2253 Y fixed in 2.8.2-beta.1 go github.com/docker/distribution v2.8.1 /usr/bin/opm A flaw was found in the /v2/_catalog endpoint in distribution/distribution, which accepts a parameter to control the maximum number of records returned (query string: n). This vulnerability allows a malicious user to submit an unreasonably large value for n, causing the allocation of a massive string array, possibly causing a denial of service through excessive use of memory.
M CVE-2022-23471 https://nvd.nist.gov/vuln/detail/CVE-2022-23471 Y fixed in 1.6.12, 1.5.16 go github.com/containerd/containerd v1.6.3 /usr/bin/opm containerd is an open source container runtime. A bug was found in containerd's CRI implementation where a user can exhaust memory on the host. In the CRI stream server, a goroutine is launched to handle terminal resize events if a TTY is requested. If the user's process fails to launch due to, for example, a faulty command, the goroutine will be stuck waiting to send without a receiver, resulting in a memory leak. Kubernetes and crictl can both be configured to use containerd's CRI implementation and the stream server is used for handling container IO. This bug has been fixed in containerd 1.6.12 and 1.5.16. Users should update to these versions to resolve the issue. Users unable to upgrade should ensure that only trusted images and commands are used and that only trusted users have permissions to execute commands in running containers.
M CVE-2022-31030 https://nvd.nist.gov/vuln/detail/CVE-2022-31030 Y fixed in 1.6.6, 1.5.13 go github.com/containerd/containerd v1.6.3 /usr/bin/opm containerd is an open source container runtime. A bug was found in the containerd's CRI implementation where programs inside a container can cause the containerd daemon to consume memory without bound during invocation of the ExecSync API. This can cause containerd to consume all available memory on the computer, denying service to other legitimate workloads. Kubernetes and crictl can both be configured to use containerd's CRI implementation; ExecSync may be used when running probes or when executing processes via an 'exec' facility. This bug has been fixed in containerd 1.6.6 and 1.5.13. Users should update to these versions to resolve the issue. Users unable to upgrade should ensure that only trusted images and commands are used.
M CVE-2023-25173 https://nvd.nist.gov/vuln/detail/CVE-2023-25173 Y fixed in 1.5.18, 1.6.18 go github.com/containerd/containerd v1.6.3 /usr/bin/opm containerd is an open source container runtime. A bug was found in containerd prior to versions 1.6.18 and 1.5.18 where supplementary groups are not set up properly inside a container. If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container. Downstream applications that use the containerd client library may be affected as well. This bug has been fixed in containerd v1.6.18 and v.1.5.18. Users should update to these versions and recreate containers to resolve this issue. Users who rely on a downstream application that uses containerd's client library should check that application for a separate advisory and instructions. As a workaround, ensure that the 'USER $USERNAME' Dockerfile instruction is not used. Instead, set the container entrypoint to a value similar to ENTRYPOINT ['su', '-', 'user'] to allow su to properly set up supplementary groups.
M CVE-2023-25153 https://nvd.nist.gov/vuln/detail/CVE-2023-25153 Y fixed in 1.5.18, 1.6.18 go github.com/containerd/containerd v1.6.3 /usr/bin/opm containerd is an open source container runtime. Before versions 1.6.18 and 1.5.18, when importing an OCI image, there was no limit on the number of bytes read for certain files. A maliciously crafted image with a large file where a limit was not applied could cause a denial of service. This bug has been fixed in containerd 1.6.18 and 1.5.18. Users should update to these versions to resolve the issue. As a workaround, ensure that only trusted images are used and that only trusted users have permissions to import images.
@grokspawn
Copy link
Contributor

Hi @venkataramanam. Please try out our later opm releases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants