Updated metadata

[nicholasdille]

No description provided.

[github-actions]

🔍 Vulnerabilities of ghcr.io/uniget-org/tools/dragonfly:2.3.4

📦 Image Reference ghcr.io/uniget-org/tools/dragonfly:2.3.4

digest	sha256:85a80ccb53ca6d44eb30decfd8e36d92ac424bd030db48606426ec7ea271e758
vulnerabilities
platform	linux/amd64
size	163 MB
packages	240

stdlib 1.23.8 (golang) pkg:golang/stdlib@1.23.8 Affected range <1.24.11 Fixed version 1.24.11 Description Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption. Affected range <1.24.8 Fixed version 1.24.8 Description The ParseAddress function constructs domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption. Affected range <1.24.8 Fixed version 1.24.8 Description The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input. This affects programs which parse untrusted PEM inputs. Affected range <1.24.8 Fixed version 1.24.8 Description Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method. This affects programs which validate arbitrary certificate chains. Affected range <1.24.9 Fixed version 1.24.9 Description Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate. This affects programs which validate arbitrary certificate chains. Affected range <1.23.10 Fixed version 1.23.10 Description Proxy-Authorization and Proxy-Authenticate headers persisted on cross-origin redirects potentially leaking sensitive information. Affected range <1.24.11 Fixed version 1.24.11 Description An excluded subdomain constraint in a certificate chain does not restrict the usage of wildcard SANs in the leaf certificate. For example a constraint that excludes the subdomain test.example.com does not prevent a leaf certificate from claiming the SAN *.example.com. Affected range <1.23.12 Fixed version 1.23.12 Description If the PATH environment variable contains paths which are executables (rather than just directories), passing certain strings to LookPath ("", ".", and ".."), can result in the binaries listed in the PATH being unexpectedly returned. Affected range <1.23.10 Fixed version 1.23.10 Description os.OpenFile(path, os.O_CREATE|O_EXCL) behaved differently on Unix and Windows systems when the target path was a dangling symlink. On Unix systems, OpenFile with O_CREATE and O_EXCL flags never follows symlinks. On Windows, when the target path was a symlink to a nonexistent location, OpenFile would create a file in that location. OpenFile now always returns an error when the O_CREATE and O_EXCL flags are both set and the target path is a symlink. Affected range <1.24.8 Fixed version 1.24.8 Description The Reader.ReadResponse function constructs a response string through repeated string concatenation of lines. When the number of lines in a response is large, this can cause excessive CPU consumption. Affected range <1.24.8 Fixed version 1.24.8 Description When Conn.Handshake fails during ALPN negotiation the error contains attacker controlled information (the ALPN protocols sent by the client) which is not escaped. Affected range <1.24.8 Fixed version 1.24.8 Description Despite HTTP headers having a default limit of 1MB, the number of cookies that can be parsed does not have a limit. By sending a lot of very small cookies such as "a=;", an attacker can make an HTTP server allocate a large amount of structs, causing large memory consumption. Affected range <1.24.8 Fixed version 1.24.8 Description Parsing a maliciously crafted DER payload could allocate large amounts of memory, causing memory exhaustion. Affected range <1.24.8 Fixed version 1.24.8 Description The Parse function permits values other than IPv6 addresses to be included in square brackets within the host component of a URL. RFC 3986 permits IPv6 addresses to be included within the host component, enclosed within square brackets. For example: "http://[::1]/". IPv4 addresses and hostnames must not appear within square brackets. Parse did not enforce this requirement. Affected range <1.24.8 Fixed version 1.24.8 Description tar.Reader does not set a maximum size on the number of sparse region data blocks in GNU tar pax 1.0 sparse files. A maliciously-crafted archive containing a large number of sparse regions can cause a Reader to read an unbounded amount of data from the archive into memory. When reading from a compressed source, a small compressed input can result in large allocations.

golang.org/x/crypto 0.41.0 (golang) pkg:golang/golang.org/x/crypto@0.41.0 Affected range <0.43.0 Fixed version 0.43.0 Description SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process. Allocation of Resources Without Limits or Throttling Affected range <0.45.0 Fixed version 0.45.0 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L Description SSH servers parsing GSSAPI authentication requests do not validate the number of mechanisms specified in the request, allowing an attacker to cause unbounded memory consumption. Out-of-bounds Read Affected range <0.45.0 Fixed version 0.45.0 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L Description SSH Agent servers do not validate the size of messages when processing new identity requests, which may cause the program to panic if the message is malformed due to an out of bounds read.

github.com/containerd/containerd 1.6.38 (golang) pkg:golang/github.com/containerd/containerd@1.6.38 Incorrect Execution-Assigned Permissions Affected range <1.7.29 Fixed version 1.7.29 CVSS Score 7.3 CVSS Vector CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H Description Impact An overly broad default permission vulnerability was found in containerd. /var/lib/containerd was created with the permission bits 0o711, while it should be created with 0o700 Allowed local users on the host to potentially access the metadata store and the content store /run/containerd/io.containerd.grpc.v1.cri was created with 0o755, while it should be created with 0o700 Allowed local users on the host to potentially access the contents of Kubernetes local volumes. The contents of volumes might include setuid binaries, which could allow a local user on the host to elevate privileges on the host. /run/containerd/io.containerd.sandbox.controller.v1.shim was created with 0o711, while it should be created with 0o700 The directory paths may differ depending on the daemon configuration. When the temp directory path is specified in the daemon configuration, that directory was also created with 0o711, while it should be created with 0o700. Patches This bug has been fixed in the following containerd versions: 2.2.0 2.1.5 2.0.7 1.7.29 Users should update to these versions to resolve the issue. These updates automatically change the permissions of the existing directories. [!NOTE] /run/containerd and /run/containerd/io.containerd.runtime.v2.task are still created with 0o711. This is an expected behavior for supporting userns-remapped containers. Workarounds The system administrator on the host can manually chmod the directories to not have group or world accessible permisisons: chmod 700 /var/lib/containerd chmod 700 /run/containerd/io.containerd.grpc.v1.cri chmod 700 /run/containerd/io.containerd.sandbox.controller.v1.shim An alternative mitigation would be to run containerd in rootless mode. Credits The containerd project would like to thank David Leadbeater for responsibly disclosing this issue in accordance with the containerd security policy. For more information If you have any questions or comments about this advisory: Open an issue in containerd Email us at security@containerd.io To report a security issue in containerd: Report a new vulnerability Missing Release of Memory after Effective Lifetime Affected range <1.7.29 Fixed version 1.7.29 CVSS Score 6.9 CVSS Vector CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N Description Impact A bug was found in containerd's CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. Repetitive calls of CRI Attach (e.g., kubectl attach) could increase the memory usage of containerd. Patches This bug has been fixed in the following containerd versions: 2.2.0 2.1.5 2.0.7 1.7.29 Users should update to these versions to resolve the issue. Workarounds Set up an admission controller to control accesses to pods/attach resources. e.g., Validating Admission Policy. Credits The containerd project would like to thank @Wheat2018 for responsibly disclosing this issue in accordance with the containerd security policy. References https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-64329 For more information If you have any questions or comments about this advisory: Open an issue in containerd Email us at security@containerd.io To report a security issue in containerd: Report a new vulnerability

github.com/quic-go/quic-go 0.54.0 (golang) pkg:golang/github.com/quic-go/quic-go@0.54.0 Reachable Assertion Affected range >=0.50.0 <0.54.1 Fixed version 0.54.1 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Description Summary A misbehaving or malicious server can trigger an assertion in a quic-go client (and crash the process) by sending a premature HANDSHAKE_DONE frame during the handshake. Impact A misbehaving or malicious server can cause a denial-of-service (DoS) attack on the quic-go client by triggering an assertion failure, leading to a process crash. This requires no authentication and can be exploited during the handshake phase. Observed in the wild with certain server implementations (e.g. Solana's Firedancer QUIC). Affected Versions All versions prior to v0.49.1 (for the 0.49 branch) Versions v0.50.0 to v0.54.0 (inclusive) Fixed in v0.49.1, v0.54.1, and v0.55.0 onward Users are recommended to upgrade to the latest patched version in their respective maintenance branch or to v0.55.0 or later. Details For a regular 1-RTT handshake, QUIC uses three sets of keys to encrypt / decrypt QUIC packets: Initial keys (derived from a static key and the connection ID) Handshake keys (derived from the client's and server's key shares in the TLS handshake) 1-RTT keys (derived when the TLS handshake finishes) On the client side, Initial keys are discarded when the first Handshake packet is sent. Handshake keys are discarded when the server's HANDSHAKE_DONE frame is received, as specified in section 4.9.2 of RFC 9001. Crucially, Initial keys are always dropped before Handshake keys in a standard handshake. Due to packet reordering, it is possible to receive a packet with a higher encryption level before the key for that encryption level has been derived. For example, the server's Handshake packets (containing, among others, the TLS certificate) might arrive before the server's Initial packet (which contains the TLS ServerHello). In that case, the client queues the Handshake packets and decrypts them as soon as it has processed the ServerHello and derived Handshake keys. After completion of the handshake, Initial and Handshake packets are not needed anymore and will be dropped. quic-go implements an assertion that no packets are queued after completion of the handshake. A misbehaving or malicious server can trigger this assertion, and thereby cause a panic, by sending a HANDSHAKE_DONE frame before actually completing the handshake. In that case, Handshake keys would be dropped before Initial keys. This can only happen if the server implementation is misbehaving: the server can only complete the handshake after receiving the client's TLS Finished message (which is sent in Handshake packets). The Fix quic-go needs to be able to handle misbehaving server implementations, including those that prematurely send a HANDSHAKE_DONE frame. We now discard Initial keys when receiving a HANDSHAKE_DONE frame, thereby correctly handling premature HANDSHAKE_DONE frames. The fix was implemented in quic-go/quic-go#5354. Allocation of Resources Without Limits or Throttling Affected range <=0.56.0 Fixed version 0.57.0 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L Description Summary An attacker can cause excessive memory allocation in quic-go's HTTP/3 client and server implementations by sending a QPACK-encoded HEADERS frame that decodes into a large header field section (many unique header names and/or large values). The implementation builds an http.Header (used on the http.Request and http.Response, respectively), while only enforcing limits on the size of the (QPACK-compressed) HEADERS frame, but not on the decoded header, leading to memory exhaustion. Impact A misbehaving or malicious peer can cause a denial-of-service (DoS) attack on quic-go's HTTP/3 servers or clients by triggering excessive memory allocation, potentially leading to crashes or exhaustion. It affects both servers and clients due to symmetric header construction. Details In HTTP/3, headers are compressed using QPACK (RFC 9204). quic-go's HTTP/3 server (and client) decodes the QPACK-encoded HEADERS frame into header fields, then constructs an http.Request (or response). http3.Server.MaxHeaderBytes and http3.Transport.MaxResponseHeaderBytes, respectively, limit encoded HEADERS frame size (default: 1 MB server, 10 MB client), but not decoded size. A maliciously crafted HEADERS frame can expand to ~50x the encoded size using QPACK static table entries with long names / values. RFC 9114 requires enforcing decoded field section size limits via SETTINGS, which quic-go did not do. The Fix quic-go now enforces RFC 9114 decoded field section size limits, sending SETTINGS_MAX_FIELD_SECTION_SIZE and using incremental QPACK decoding to check the header size after each entry, aborting early on violations with HTTP 431 (on the server side) and stream reset (on the client side).

github.com/aws/aws-sdk-go 1.55.8 (golang) pkg:golang/github.com/aws/aws-sdk-go@1.55.8 Affected range >=0 Fixed version Not Fixed Description A padding oracle vulnerability exists in the AWS S3 Crypto SDK for GoLang versions prior to V2. The SDK allows users to encrypt files with AES-CBC without computing a Message Authentication Code (MAC), which then allows an attacker who has write access to the target's S3 bucket and can observe whether or not an endpoint with access to the key can decrypt a file, they can reconstruct the plaintext with (on average) 128*length (plaintext) queries to the endpoint, by exploiting CBC's ability to manipulate the bytes of the next block and PKCS5 padding errors. It is recommended to update your SDK to V2 or later, and re-encrypt your files. Affected range >=0 Fixed version Not Fixed Description A vulnerability in the in-band key negotiation exists in the AWS S3 Crypto SDK for GoLang versions prior to V2. An attacker with write access to the targeted bucket can change the encryption algorithm of an object in the bucket, which can then allow them to change AES-GCM to AES-CTR. Using this in combination with a decryption oracle can reveal the authentication key used by AES-GCM as decrypting the GMAC tag leaves the authentication key recoverable as an algebraic equation. It is recommended to update your SDK to V2 or later, and re-encrypt your files.