Hey, I would like to track the following golang.org/x/crypto CVEs here since a scanner raised them in our project:
The findings are valid at dependency level, but most likely has no practical impact in simple/common AWS Lambda setups, as described below.
Context
The reported CVEs affect golang.org/x/crypto, mainly SSH-related packages such as ssh, ssh/agent, and ssh/knownhosts.
Official Go vulnerability reports:
The issues are fixed in golang.org/x/crypto version v0.52.0 (https://groups.google.com/g/golang-announce/c/a082jnz-LvI).
The current collector Lambda module references golang.org/x/crypto v0.50.0 (https://github.com/open-telemetry/opentelemetry-lambda/blob/main/collector/lambdacomponents/go.mod#L242), which is below the fixed version.
Exposure in a simple/common setup
For this assessment, the assumed simple setup is: deployment-controlled local collector configuration, static deployment-controlled exporter endpoints, no user- or tenant-controlled collector configuration, no SSH/SFTP/SCP/Git-over-SSH usage, no SSH agent forwarding, and no custom collector components using golang.org/x/crypto/ssh.
In a simple/common OpenTelemetry Lambda layer setup, the relevant place where this dependency exists is:
opentelemetry-collector-arm64-0_22_0:1
The listed CVEs are SSH-related. In the standard Lambda collector setup, the collector is not expected to act as an SSH client, SSH server, SSH agent, SSH known-hosts verifier, or SSH certificate/public-key authorization component.
Therefore, the SSH-related code paths described in the Go vulnerability reports do not appear exploitable in a standard/simple OpenTelemetry Lambda layer setup.
Configurations increasing exposure risk
This could become relevant if the setup was changed to use:
- custom collector components using
golang.org/x/crypto/ssh
- SSH/SFTP/SCP/Git-over-SSH based exporters, receivers, extensions, or config providers
- SSH tunnels inside the collector process
- SSH agent forwarding
- user- or tenant-controlled SSH hostnames, keys, certificates, known-hosts data, or authorization callbacks
- another bundled Go binary or Lambda layer using
golang.org/x/crypto < v0.52.0
Simple setup assessment
So the assessment for the simple/common setup, as described above, is:
Affected dependency present, but no exploitable path identified in the current standard/simple OpenTelemetry Lambda layer configuration. Practical risk is assessed as low pending upgrade.
We are documenting this here for visibility, as automated tooling may flag it without evaluating runtime context.
If your assessment of this issue in a comparable setup differs, please comment.
Remedy
This should be resolved once the OpenTelemetry Lambda collector layer is rebuilt with golang.org/x/crypto >= v0.52.0.
The upstream fix already appears to be available in OpenTelemetry Collector and Collector Contrib:
There is also an open OpenTelemetry Lambda dependency update PR that appears to pull in the newer collector dependency set:
The finding remains valid for the currently published collector layer opentelemetry-collector-arm64-0_22_0:1 until a new OpenTelemetry Lambda collector layer is released with the updated dependency set.
Hey, I would like to track the following
golang.org/x/cryptoCVEs here since a scanner raised them in our project:The findings are valid at dependency level, but most likely has no practical impact in simple/common AWS Lambda setups, as described below.
Context
The reported CVEs affect
golang.org/x/crypto, mainly SSH-related packages such asssh,ssh/agent, andssh/knownhosts.Official Go vulnerability reports:
The issues are fixed in
golang.org/x/cryptoversionv0.52.0(https://groups.google.com/g/golang-announce/c/a082jnz-LvI).The current collector Lambda module references
golang.org/x/crypto v0.50.0(https://github.com/open-telemetry/opentelemetry-lambda/blob/main/collector/lambdacomponents/go.mod#L242), which is below the fixed version.Exposure in a simple/common setup
For this assessment, the assumed simple setup is: deployment-controlled local collector configuration, static deployment-controlled exporter endpoints, no user- or tenant-controlled collector configuration, no SSH/SFTP/SCP/Git-over-SSH usage, no SSH agent forwarding, and no custom collector components using
golang.org/x/crypto/ssh.In a simple/common OpenTelemetry Lambda layer setup, the relevant place where this dependency exists is:
opentelemetry-collector-arm64-0_22_0:1The listed CVEs are SSH-related. In the standard Lambda collector setup, the collector is not expected to act as an SSH client, SSH server, SSH agent, SSH known-hosts verifier, or SSH certificate/public-key authorization component.
Therefore, the SSH-related code paths described in the Go vulnerability reports do not appear exploitable in a standard/simple OpenTelemetry Lambda layer setup.
Configurations increasing exposure risk
This could become relevant if the setup was changed to use:
golang.org/x/crypto/sshgolang.org/x/crypto < v0.52.0Simple setup assessment
So the assessment for the simple/common setup, as described above, is:
Affected dependency present, but no exploitable path identified in the current standard/simple OpenTelemetry Lambda layer configuration. Practical risk is assessed as low pending upgrade.
We are documenting this here for visibility, as automated tooling may flag it without evaluating runtime context.
If your assessment of this issue in a comparable setup differs, please comment.
Remedy
This should be resolved once the OpenTelemetry Lambda collector layer is rebuilt with
golang.org/x/crypto >= v0.52.0.The upstream fix already appears to be available in OpenTelemetry Collector and Collector Contrib:
There is also an open OpenTelemetry Lambda dependency update PR that appears to pull in the newer collector dependency set:
The finding remains valid for the currently published collector layer
opentelemetry-collector-arm64-0_22_0:1until a new OpenTelemetry Lambda collector layer is released with the updated dependency set.