CVE-2024-29037

{"id": "CVE-2024-29037", "metrics": {"cvssMetricV31": [{"type": "Secondary", "source": "security-advisories@github.com", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 9.1, "attackVector": "NETWORK", "baseSeverity": "CRITICAL", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "NONE", "privilegesRequired": "NONE", "confidentialityImpact": "HIGH"}, "impactScore": 5.2, "exploitabilityScore": 3.9}]}, "published": "2024-03-20T21:15:32.040", "references": [{"url": "https://github.com/acryldata/datahub-helm/commit/ea8a17860f053c63387b8309e1f77c0e1462a1b3", "source": "security-advisories@github.com"}, {"url": "https://github.com/acryldata/datahub-helm/security/advisories/GHSA-82p6-9h7m-9h8j", "source": "security-advisories@github.com"}, {"url": "https://github.com/acryldata/datahub-helm/commit/ea8a17860f053c63387b8309e1f77c0e1462a1b3", "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://github.com/acryldata/datahub-helm/security/advisories/GHSA-82p6-9h7m-9h8j", "source": "af854a3a-2127-422b-91ae-364da2661108"}], "vulnStatus": "Awaiting Analysis", "weaknesses": [{"type": "Secondary", "source": "security-advisories@github.com", "description": [{"lang": "en", "value": "CWE-1394"}]}], "descriptions": [{"lang": "en", "value": "datahub-helm provides the Kubernetes Helm charts for deploying Datahub and its dependencies on a Kubernetes cluster. Starting in version 0.1.143 and prior to version 0.2.182, due to configuration issues in the helm chart, if there was a successful initial deployment during a limited window of time, personal access tokens were possibly created with a default secret key. Since the secret key is a static, publicly available value, someone could inspect the algorithm used to generate personal access tokens and generate their own for an instance. Deploying with Metadata Service Authentication enabled would have been difficult during window of releases. If someone circumvented the helm settings and manually set Metadata Service Authentication to be enabled using environment variables directly, this would skip over the autogeneration logic for the Kubernetes Secrets and DataHub GMS would default to the signing key specified statically in the application.yml. Most deployments probably did not attempt to circumvent the helm settings to enable Metadata Service Authentication during this time, so impact is most likely limited. Any deployments with Metadata Service Authentication enabled should ensure that their secret values are properly randomized. Version 0.2.182 contains a patch for this issue. As a workaround, one may reset the token signing key to be a random value, which will invalidate active personal access tokens."}, {"lang": "es", "value": "datahub-helm proporciona los gr\u00e1ficos de Kubernetes Helm para implementar Datahub y sus dependencias en un cl\u00faster de Kubernetes. A partir de la versi\u00f3n 0.1.143 y antes de la versi\u00f3n 0.2.182, debido a problemas de configuraci\u00f3n en el gr\u00e1fico de tim\u00f3n, si hab\u00eda una implementaci\u00f3n inicial exitosa durante un per\u00edodo de tiempo limitado, posiblemente se creaban tokens de acceso personal con una clave secreta predeterminada. Dado que la clave secreta es un valor est\u00e1tico y disponible p\u00fablicamente, alguien podr\u00eda inspeccionar el algoritmo utilizado para generar tokens de acceso personal y generar los suyos propios para una instancia. La implementaci\u00f3n con la autenticaci\u00f3n del servicio de metadatos habilitada habr\u00eda sido dif\u00edcil durante la ventana de lanzamientos. Si alguien eludi\u00f3 la configuraci\u00f3n del tim\u00f3n y configur\u00f3 manualmente la autenticaci\u00f3n del servicio de metadatos para que se habilite usando variables de entorno directamente, esto omitir\u00eda la l\u00f3gica de generaci\u00f3n autom\u00e1tica para Kubernetes Secrets y DataHub GMS usar\u00eda de forma predeterminada la clave de firma especificada est\u00e1ticamente en application.yml. La mayor\u00eda de las implementaciones probablemente no intentaron eludir la configuraci\u00f3n del tim\u00f3n para habilitar la autenticaci\u00f3n del servicio de metadatos durante este tiempo, por lo que el impacto probablemente sea limitado. Cualquier implementaci\u00f3n con la autenticaci\u00f3n del servicio de metadatos habilitada debe garantizar que sus valores secretos est\u00e9n correctamente aleatorizados. La versi\u00f3n 0.2.182 contiene un parche para este problema. Como workaround, se puede restablecer la clave de firma del token para que sea un valor aleatorio, lo que invalidar\u00e1 los tokens de acceso personal activos."}], "lastModified": "2024-11-21T09:07:25.500", "sourceIdentifier": "security-advisories@github.com"}