Er zijn meerdere beveiligingskwetsbaarheden onthuld in GitHub Desktop en andere Git-gerelateerde projecten die, indien succesvol misbruikt, een aanvaller in staat zouden kunnen stellen ongeautoriseerde toegang te krijgen tot de Git-gegevens van een gebruiker.
“Git implementeert een protocol genaamd Git Credential Protocol om inloggegevens op te halen van de inloghelper”, zei GMO Flatt Security-onderzoeker Ry0taK, die de fouten ontdekte, in een analyse die zondag werd gepubliceerd. “Vanwege de onjuiste afhandeling van berichten waren veel projecten op verschillende manieren kwetsbaar voor het lekken van inloggegevens.”
De lijst met geïdentificeerde kwetsbaarheden is als volgt:
- CVE-2025-23040 (CVSS-score: 6,6) – Kwaadwillig vervaardigde externe URL’s kunnen leiden tot lekken van inloggegevens in GitHub Desktop
- CVE-2024-50338 (CVSS-score: 7,4) – Het Carriage-return-teken in de externe URL zorgt ervoor dat de kwaadaardige repository inloggegevens in Git Credential Manager kan lekken
- CVE-2024-53263 (CVSS-score: 8,5) – Git LFS maakt het ophalen van inloggegevens mogelijk via vervaardigde HTTP-URL’s
- CVE-2024-53858 (CVSS-score: 6,5) – Recursief klonen van repository’s in GitHub CLI kan authenticatietokens lekken naar niet-GitHub-submodulehosts
Hoewel de credential-helper is ontworpen om een bericht terug te sturen met de inloggegevens die worden gescheiden door het newline-controleteken (“n”), is uit het onderzoek gebleken dat GitHub Desktop vatbaar is voor een geval van Carriage Return (“r”) smokkel, waarbij het injecteren van het teken in een vervaardigde URL kan de inloggegevens lekken naar een door een aanvaller bestuurde host.
“Door een kwaadwillig vervaardigde URL te gebruiken is het mogelijk om ervoor te zorgen dat het inlogverzoek afkomstig van Git verkeerd wordt geïnterpreteerd door Github Desktop, zodat het inloggegevens zal verzenden voor een andere host dan de host waarmee Git momenteel communiceert, waardoor geheime exfiltratie mogelijk is”, aldus GitHub. bij een advies.
Een soortgelijke zwakte is ook geïdentificeerd in het Git Credential Manager NuGet-pakket, waardoor inloggegevens kunnen worden blootgesteld aan een niet-gerelateerde host. Het is eveneens gebleken dat Git LFS niet controleert op ingebedde besturingstekens, wat resulteert in een Carriage Return Line Feed (CRLF)-injectie via vervaardigde HTTP-URL’s.
Aan de andere kant maakt de kwetsbaarheid die van invloed is op GitHub CLI misbruik van het feit dat het toegangstoken is geconfigureerd om naar andere hosts dan github(.)com en ghe(.)com te worden verzonden, zolang de omgevingsvariabelen GITHUB_ENTERPRISE_TOKEN, GH_ENTERPRISE_TOKEN en GITHUB_TOKEN zijn ingesteld, en CODESPACES is ingesteld op “true” in het laatste geval.
“Hoewel beide bedrijfsgerelateerde variabelen niet gebruikelijk zijn, is de omgevingsvariabele CODESPACES altijd ingesteld op true wanneer deze op GitHub Codespaces draait”, aldus Ry0taK. “Dus het klonen van een kwaadaardige repository op GitHub Codespaces met behulp van GitHub CLI zal altijd het toegangstoken lekken naar de hosts van de aanvaller.”
Succesvol misbruik van de bovengenoemde fouten kan ertoe leiden dat een kwaadwillende derde partij de gelekte authenticatietokens gebruikt om toegang te krijgen tot bevoorrechte bronnen.
Als reactie op de onthullingen is het lekken van inloggegevens als gevolg van het smokkelen van wagenretouren door het Git-project behandeld als een op zichzelf staande kwetsbaarheid (CVE-2024-52006, CVSS-score: 2.1) en verholpen in versie v2.48.1.
“Deze kwetsbaarheid houdt verband met CVE-2020-5260, maar is afhankelijk van gedrag waarbij enkele regelteruglooptekens door sommige credential-helperimplementaties worden geïnterpreteerd als nieuwe regels”, zei GitHub-software-ingenieur Taylor Blau in een bericht over CVE-2024-52006.
De nieuwste versie herstelt ook CVE-2024-50349 (CVSS-score: 2.1), die door een tegenstander kan worden uitgebuit om URL’s te maken met escape-reeksen om gebruikers te misleiden zodat ze hun inloggegevens aan willekeurige sites verstrekken.
Gebruikers wordt geadviseerd om te updaten naar de nieuwste versie om zich tegen deze kwetsbaarheden te beschermen. Als onmiddellijk patchen geen optie is, kan het risico dat gepaard gaat met de fouten worden beperkt door te voorkomen dat git clone met –recurse-submodules op niet-vertrouwde repository’s wordt uitgevoerd. Het wordt ook aanbevolen om de referentiehulp niet te gebruiken door alleen openbaar beschikbare repository’s te klonen.
