[DRAFT] split into codec and server into their own dependencies.

[MortadhaTeffaha]

No description provided.

[datadog-datadog-prod-us1]

🟠 Library Vulnerability

github.com/Azure/azure-sdk-for-go/sdk/azidentity → 1.3.0

View all suggested fixes

Suggested change

	github.com/Azure/azure-sdk-for-go/sdk/azidentity v1.3.0 // indirect
	github.com/Azure/azure-sdk-for-go/sdk/azidentity vv1.8.1-0.20250103011558-52b9e5fa8c78// indirect

Suggested change

	github.com/Azure/azure-sdk-for-go/sdk/azidentity v1.3.0 // indirect
	github.com/Azure/azure-sdk-for-go/sdk/azidentity vv1.6.0// indirect

Azure Identity Libraries and Microsoft Authentication Library Elevation of Privilege Vulnerability (...read more)

Azure Identity Libraries and Microsoft Authentication Library Elevation of Privilege Vulnerability.

    

[datadog-datadog-prod-us1]

🔴 Library Vulnerability

github.com/apache/thrift → 0.0.0-20161221203622-b2a4d4ae21c7

View all suggested fixes

Suggested change

	github.com/apache/thrift v0.0.0-20161221203622-b2a4d4ae21c7 // indirect
	github.com/apache/thrift vv0.21.1-0.20250106213936-947ad66940cf// indirect

Suggested change

	github.com/apache/thrift v0.0.0-20161221203622-b2a4d4ae21c7 // indirect
	github.com/apache/thrift vv0.13.0// indirect

Suggested change

	github.com/apache/thrift v0.0.0-20161221203622-b2a4d4ae21c7 // indirect
	github.com/apache/thrift vv0.12.0// indirect

Apache Thrift Go Library Command Injection (...read more)

The Apache Thrift Go client library exposed the potential during code generation for command injection due to using an external formatting tool. Affected Apache Thrift 0.9.3 and older, Fixed in Apache Thrift 0.10.0.

    

[datadog-datadog-prod-us1]

🔴 Library Vulnerability

github.com/docker/distribution → 2.8.0+incompatible

View all suggested fixes

Suggested change

	github.com/docker/distribution v2.8.0+incompatible // indirect
	github.com/docker/distribution vv2.8.3+incompatible// indirect

Suggested change

	github.com/docker/distribution v2.8.0+incompatible // indirect
	github.com/docker/distribution vv2.8.2+incompatible// indirect

distribution catalog API endpoint can lead to OOM via malicious user input (...read more)

Impact

Systems that run distribution built after a specific commit running on memory-restricted environments can suffer from denial of service by a crafted malicious /v2/_catalog API endpoint request.

Patches

Upgrade to at least 2.8.2-beta.1 if you are running v2.8.x release. If you use the code from the main branch, update at least to the commit after f55a6552b006a381d9167e328808565dd2bf77dc.

Workarounds

There is no way to work around this issue without patching. Restrict access to the affected API endpoint: see the recommendations section.

References

/v2/_catalog endpoint accepts a parameter to control the maximum amount of records returned (query string: n).

When not given the default n=100 is used. The server trusts that n has an acceptable value, however when using a
maliciously large value, it allocates an array/slice of n of strings before filling the slice with data.

This behaviour was introduced ~7yrs ago [1].

Recommendation

The /v2/_catalog endpoint was designed specifically to do registry syncs with search or other API systems. Such an endpoint would create a lot of load on the backend system, due to overfetch required to serve a request in certain implementations.

Because of this, we strongly recommend keeping this API endpoint behind heightened privilege and avoiding leaving it exposed to the internet.

For more information

If you have any questions or comments about this advisory:

• Open an issue in distribution repository
• Email us at [email protected]

[1] faulty commit

    

[datadog-datadog-prod-us1]

⚫ Library Vulnerability

github.com/docker/docker → 20.10.17+incompatible

View all suggested fixes

Suggested change

	github.com/docker/docker v20.10.17+incompatible // indirect
	github.com/docker/docker vv299999999.0.0-20200612211812-aaf470eca7b5+incompatible// indirect

Suggested change

	github.com/docker/docker v20.10.17+incompatible // indirect
	github.com/docker/docker vv25.0.6+incompatible// indirect

Suggested change

	github.com/docker/docker v20.10.17+incompatible // indirect
	github.com/docker/docker vv23.0.15+incompatible// indirect

Authz zero length regression (...read more)

A security vulnerability has been detected in certain versions of Docker Engine, which could allow an attacker to bypass authorization plugins (AuthZ) under specific circumstances. The base likelihood of this being exploited is low. This advisory outlines the issue, identifies the affected versions, and provides remediation steps for impacted users.

Impact

Using a specially-crafted API request, an Engine API client could make the daemon forward the request or response to an authorization plugin without the body. In certain circumstances, the authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it.

A security issue was discovered In 2018, where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. Although this issue was fixed in Docker Engine v18.09.1 in January 2019, the fix was not carried forward to later major versions, resulting in a regression. Anyone who depends on authorization plugins that introspect the request and/or response body to make access control decisions is potentially impacted.

Docker EE v19.03.x and all versions of Mirantis Container Runtime are not vulnerable.

Vulnerability details

• AuthZ bypass and privilege escalation: An attacker could exploit a bypass using an API request with Content-Length set to 0, causing the Docker daemon to forward the request without the body to the AuthZ plugin, which might approve the request incorrectly.
• Initial fix: The issue was fixed in Docker Engine v18.09.1 January 2019..
• Regression: The fix was not included in Docker Engine v19.03 or newer versions. This was identified in April 2024 and patches were released for the affected versions on July 23, 2024. The issue was assigned CVE-2024-41110.

Patches

• docker-ce v27.1.1 containes patches to fix the vulnerability.
• Patches have also been merged into the master, 19.0, 20.0, 23.0, 24.0, 25.0, 26.0, and 26.1 release branches.

Remediation steps

• If you are running an affected version, update to the most recent patched version.
• Mitigation if unable to update immediately:
  • Avoid using AuthZ plugins.
  • Restrict access to the Docker API to trusted parties, following the principle of least privilege.

References

• moby/moby@fc274cd
• moby/moby@a79fabb
• https://www.docker.com/blog/docker-security-advisory-docker-engine-authz-plugin/

    

[datadog-datadog-prod-us1]

🟡 Library Vulnerability

github.com/golang-jwt/jwt/v4 → 4.5.0

Suggested change

	github.com/golang-jwt/jwt/v4 v4.5.0 // indirect
	github.com/golang-jwt/jwt/v4 vv4.5.1// indirect

Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations (...read more)

Summary

Unclear documentation of the error behavior in ParseWithClaims can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by ParseWithClaims return both error codes. If users only check for the jwt.ErrTokenExpired using error.Is, they will ignore the embedded jwt.ErrTokenSignatureInvalid and thus potentially accept invalid tokens.

Fix

We have back-ported the error handling logic from the v5 branch to the v4 branch. In this logic, the ParseWithClaims function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release.

Workaround

We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above.

token, err := /* jwt.Parse or similar */
if token.Valid {
	fmt.Println("You look nice today")
} else if errors.Is(err, jwt.ErrTokenMalformed) {
	fmt.Println("That's not even a token")
} else if errors.Is(err, jwt.ErrTokenUnverifiable) {
	fmt.Println("We could not verify this token")
} else if errors.Is(err, jwt.ErrTokenSignatureInvalid) {
	fmt.Println("This token has an invalid signature")
} else if errors.Is(err, jwt.ErrTokenExpired) || errors.Is(err, jwt.ErrTokenNotValidYet) {
	// Token is either expired or not active yet
	fmt.Println("Timing is everything")
} else {
	fmt.Println("Couldn't handle this token:", err)
}

    

[datadog-datadog-prod-us1]

🔴 Library Vulnerability

google.golang.org/grpc → 1.48.0

View all suggested fixes

Suggested change

	google.golang.org/grpc v1.48.0 // indirect
	google.golang.org/grpc vv1.70.0-dev.0.20241224124116-724f450f77a0// indirect

Suggested change

	google.golang.org/grpc v1.48.0 // indirect
	google.golang.org/grpc vv1.56.3// indirect

gRPC-Go HTTP/2 Rapid Reset vulnerability (...read more)

Impact

In affected releases of gRPC-Go, it is possible for an attacker to send HTTP/2 requests, cancel them, and send subsequent requests, which is valid by the HTTP/2 protocol, but would cause the gRPC-Go server to launch more concurrent method handlers than the configured maximum stream limit.

Patches

This vulnerability was addressed by #6703 and has been included in patch releases: 1.56.3, 1.57.1, 1.58.3. It is also included in the latest release, 1.59.0.

Along with applying the patch, users should also ensure they are using the grpc.MaxConcurrentStreams server option to apply a limit to the server's resources used for any single connection.

Workarounds

None.

References

#6703

    

[datadog-datadog-prod-us1]

🔴 Library Vulnerability

google.golang.org/grpc → 1.48.0

View all suggested fixes

Suggested change

	google.golang.org/grpc v1.48.0 // indirect
	google.golang.org/grpc vv1.70.0-dev.0.20241224124116-724f450f77a0// indirect

Suggested change

	google.golang.org/grpc v1.48.0 // indirect
	google.golang.org/grpc vv1.56.3// indirect

gRPC-Go HTTP/2 Rapid Reset vulnerability (...read more)

Impact

In affected releases of gRPC-Go, it is possible for an attacker to send HTTP/2 requests, cancel them, and send subsequent requests, which is valid by the HTTP/2 protocol, but would cause the gRPC-Go server to launch more concurrent method handlers than the configured maximum stream limit.

Patches

This vulnerability was addressed by #6703 and has been included in patch releases: 1.56.3, 1.57.1, 1.58.3. It is also included in the latest release, 1.59.0.

Along with applying the patch, users should also ensure they are using the grpc.MaxConcurrentStreams server option to apply a limit to the server's resources used for any single connection.

Workarounds

None.

References

#6703

    

[datadog-datadog-prod-us1]

🔴 Library Vulnerability

google.golang.org/protobuf → 1.28.0

View all suggested fixes

Suggested change

	google.golang.org/protobuf v1.28.0 // indirect
	google.golang.org/protobuf vv1.36.2-0.20241223133329-8878926ea790// indirect

Suggested change

	google.golang.org/protobuf v1.28.0 // indirect
	google.golang.org/protobuf vv1.33.0// indirect

Golang protojson.Unmarshal function infinite loop when unmarshaling certain forms of invalid JSON (...read more)

The protojson.Unmarshal function can enter an infinite loop when unmarshaling certain forms of invalid JSON. This condition can occur when unmarshaling into a message which contains a google.protobuf.Any value, or when the UnmarshalOptions.DiscardUnknown option is set.

    

[datadog-datadog-prod-us1]

🔴 Library Vulnerability

google.golang.org/protobuf → 1.28.1

View all suggested fixes

Suggested change

	google.golang.org/protobuf v1.28.1 // indirect
	google.golang.org/protobuf vv1.36.2-0.20241223133329-8878926ea790// indirect

Suggested change

	google.golang.org/protobuf v1.28.1 // indirect
	google.golang.org/protobuf vv1.33.0// indirect

Golang protojson.Unmarshal function infinite loop when unmarshaling certain forms of invalid JSON (...read more)

The protojson.Unmarshal function can enter an infinite loop when unmarshaling certain forms of invalid JSON. This condition can occur when unmarshaling into a message which contains a google.protobuf.Any value, or when the UnmarshalOptions.DiscardUnknown option is set.

    

[datadog-datadog-prod-us1]

🟠 Library Vulnerability

gopkg.in/square/go-jose.v2 → 2.6.0

Go JOSE vulnerable to Improper Handling of Highly Compressed Data (Data Amplification) (...read more)

Impact

An attacker could send a JWE containing compressed data that used large amounts of memory and CPU when decompressed by Decrypt or DecryptMulti. Those functions now return an error if the decompressed data would exceed 250kB or 10x the compressed size (whichever is larger). Thanks to Enze Wang@Alioth and Jianjun Chen@Zhongguancun Lab (@zer0yu and @chenjj) for reporting.

Patches

The problem is fixed in the following packages and versions:

• github.com/go-jose/go-jose/v4 version 4.0.1
• github.com/go-jose/go-jose/v3 version 3.0.3
• gopkg.in/go-jose/go-jose.v2 version 2.6.3

The problem will not be fixed in the following package because the package is archived:

• gopkg.in/square/go-jose.v2

    

[hferentschik]

@MortadhaTeffaha, mind opening an issue as well?