Skip to content

Server/API for Vela Insecure Variable Substitution

High severity GitHub Reviewed Published Mar 12, 2024 in go-vela/server • Updated Mar 15, 2024

Package

gomod github.com/go-vela/server (Go)

Affected versions

<= 0.23.1

Patched versions

0.23.2

Description

Impact

Vela pipelines can use variable substitution combined with insensitive fields like parameters, image and entrypoint to inject secrets into a plugin/image and — by using common substitution string manipulation — can bypass log masking and expose secrets without the use of the commands block. This unexpected behavior primarily impacts secrets restricted by the "no commands" option. This can lead to unintended use of the secret value, and increased risk of exposing the secret during image execution bypassing log masking.

Given by the following substitution examples:
using parameters

steps:
  - name: example
    image: <some plugin>
    secrets: [ example_secret ]
    parameters:
      example: $${EXAMPLE_SECRET}

using image tag

steps:
  - name: example
    image: <some plugin>:latest${EXAMPLE_SECRET}
    secrets: [ example_secret ]

using entrypoint as a shim for commands

steps:
  - name: example
    image: <some plugin>
    secrets: [ example_secret ]
    entrypoint:
      [
        "sh",
        "-c",
        "echo $EXAMPLE_SECRET",
      ]

To exploit this the pipeline author must be supplying the secrets to a plugin that is designed in such a way that will print those parameters in logs. Plugin parameters are not designed for sensitive values and are often intentionally printed throughout execution for informational/debugging purposes. Parameters should therefore be treated as insensitive.

While Vela provides secrets masking, secrets exposure is not entirely solved by the masking process. A docker image (plugin) can easily expose secrets if they are not handled properly, or altered in some way. There is a responsibility on the end-user to understand how values injected into a plugin are used. This is a risk that exists for many CICD systems (like GitHub Actions) that handle sensitive runtime variables. Rather, the greater risk is that users who restrict a secret to the "no commands" option and use image restriction can still have their secret value exposed via substitution tinkering, which turns the image and command restrictions into a false sense of security.

Patches

N/A

Workarounds

  • Do not provide sensitive values to plugins that can potentially expose them, especially in parameters that are not intended to be used for sensitive values.
  • Ensure plugins (especially those that utilize shared secrets) follow best practices to avoid logging parameters that are expected to be sensitive.
  • Minimize secrets with pull_request events enabled, as this allows users to change pipeline configurations and pull in secrets to steps not typically part of the CI process.
  • Make use of the build approval setting, restricting builds from untrusted users
  • Limit use of shared secrets, as they are less restrictive to access by nature.

References

For more information

If you have any questions or comments about this advisory:

Affected products: go-vela/worker

References

@plyr4 plyr4 published to go-vela/server Mar 12, 2024
Published to the GitHub Advisory Database Mar 15, 2024
Reviewed Mar 15, 2024
Last updated Mar 15, 2024

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
None
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Weaknesses

No CWEs

CVE ID

No known CVE

GHSA ID

GHSA-69p4-j5v5-x234

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.