CVE-2024-28236

{"id": "CVE-2024-28236", "metrics": {"cvssMetricV31": [{"type": "Secondary", "source": "security-advisories@github.com", "cvssData": {"scope": "CHANGED", "version": "3.1", "baseScore": 7.7, "attackVector": "NETWORK", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "NONE", "privilegesRequired": "LOW", "confidentialityImpact": "HIGH"}, "impactScore": 4.0, "exploitabilityScore": 3.1}]}, "published": "2024-03-12T21:15:59.027", "references": [{"url": "https://github.com/go-vela/worker/commit/e1572743b008e4fbce31ebb1dcd23bf6a1a30297", "source": "security-advisories@github.com"}, {"url": "https://github.com/go-vela/worker/security/advisories/GHSA-pwx5-6wxg-px5h", "source": "security-advisories@github.com"}], "vulnStatus": "Awaiting Analysis", "weaknesses": [{"type": "Secondary", "source": "security-advisories@github.com", "description": [{"lang": "en", "value": "CWE-200"}, {"lang": "en", "value": "CWE-532"}]}], "descriptions": [{"lang": "en", "value": "Vela is a Pipeline Automation (CI/CD) framework built on Linux container technology written in Golang. Vela pipelines can use variable substitution combined with insensitive fields like `parameters`, `image` and `entrypoint` to inject secrets into a plugin/image and \u2014 by using common substitution string manipulation \u2014 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. **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. This issue has been addressed in version 0.23.2. Users are advised to upgrade. Users unable to upgrade should 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, and limit use of shared secrets, as they are less restrictive to access by nature."}, {"lang": "es", "value": "Vela es un marco de automatizaci\u00f3n de tuber\u00edas (CI/CD) construido sobre tecnolog\u00eda de contenedores de Linux escrita en Golang. Los pipelines de Vela pueden usar sustituci\u00f3n de variables combinada con campos insensibles como \"par\u00e1metros\", \"imagen\" y \"punto de entrada\" para inyectar secretos en un complemento/imagen y, mediante el uso de manipulaci\u00f3n com\u00fan de cadenas de sustituci\u00f3n, pueden evitar el enmascaramiento de registros y exponer secretos sin el uso de el bloque de comandos. Este comportamiento inesperado afecta principalmente a los secretos restringidos por la opci\u00f3n \"sin comandos\". Esto puede provocar un uso no intencionado del valor secreto y un mayor riesgo de exponer el secreto durante la ejecuci\u00f3n de la imagen sin pasar por el enmascaramiento del registro. **Para explotar esto**, el autor de la canalizaci\u00f3n debe proporcionar los secretos a un complemento manipulado de tal manera que imprima esos par\u00e1metros en los registros. Los par\u00e1metros del complemento no est\u00e1n manipulados para valores confidenciales y, a menudo, se imprimen intencionalmente durante la ejecuci\u00f3n con fines informativos/depuraci\u00f3n. Por lo tanto, los par\u00e1metros deben tratarse como insensibles. Si bien Vela proporciona enmascaramiento de secretos, la exposici\u00f3n de secretos no se resuelve por completo mediante el proceso de enmascaramiento. Una imagen acoplable (complemento) puede exponer secretos f\u00e1cilmente si no se manejan adecuadamente o se modifican de alguna manera. El usuario final tiene la responsabilidad de comprender c\u00f3mo se utilizan los valores inyectados en un complemento. Este es un riesgo que existe para muchos sistemas CICD (como GitHub Actions) que manejan variables confidenciales de tiempo de ejecuci\u00f3n. M\u00e1s bien, el mayor riesgo es que los usuarios que restringen un secreto a la opci\u00f3n \"sin comandos\" y usan restricci\u00f3n de im\u00e1genes a\u00fan puedan exponer su valor secreto a trav\u00e9s de modificaciones de sustituci\u00f3n, lo que convierte las restricciones de im\u00e1genes y comandos en una falsa sensaci\u00f3n de seguridad. Este problema se solucion\u00f3 en la versi\u00f3n 0.23.2. Se recomienda a los usuarios que actualicen. Los usuarios que no puedan actualizar no deben proporcionar valores confidenciales a los complementos que potencialmente puedan exponerlos, especialmente en los \"par\u00e1metros\" que no est\u00e1n destinados a ser utilizados para valores confidenciales, aseg\u00farese de que los complementos (especialmente aquellos que utilizan secretos compartidos) sigan las mejores pr\u00e1cticas para evitar el registro de par\u00e1metros. que se espera que sean confidenciales, minimice los secretos con los eventos `pull_request` habilitados, ya que esto permite a los usuarios cambiar las configuraciones de canalizaci\u00f3n e incorporar secretos a pasos que normalmente no forman parte del proceso de CI, utilice la configuraci\u00f3n de aprobaci\u00f3n de compilaci\u00f3n y restrinja las compilaciones que no sean de confianza, usuarios y limitar el uso de secretos compartidos, ya que su acceso es menos restrictivo por naturaleza."}], "lastModified": "2024-03-13T12:33:51.697", "sourceIdentifier": "security-advisories@github.com"}