Hvis de udnyttes, kan disse fejl give angribere mulighed for at få uautoriseret adgang til følsomme oplysninger eller generelt forårsage problemer
Få dage siden, GitHub afsløret Gennem et blogindlæg er detaljer om en sårbarhed som giver dig adgang til indholdet af miljøvariabler eksponeret i containere, der bruges i din produktionsinfrastruktur.
Sårbarheden blev opdaget af en deltager i Bug Bounty-programmet, designet til at finde sikkerhedsproblemer og belønne forskere for deres resultater. Dette problem påvirker både GitHub-tjenesten og til konfigurationerne GitHub Enterprise Server (GHES), der kører på brugernes systemer.
Sikkerhedssårbarheden, katalogiseret under CVE-2024-0200 med en høj sværhedsgrad på 7.2 (CVSS), ikke er blevet udnyttet i naturen, Det nævnes, at der efter analyse af registreringerne og revision af infrastrukturen ikke blev fundet beviser for udnyttelse af sårbarheden i fortiden, bortset fra aktiviteten fra den forsker, der rapporterede problemet. Men som en forebyggende foranstaltning erstattede vi alle krypteringsnøgler og legitimationsoplysninger, der kunne være blevet kompromitteret, hvis en hacker udnyttede sårbarheden.
GitHub Enterprise Server (GHES) nævnes at være påvirket, men Udnyttelse af sårbarheden kræver en autentificeret bruger med en ejerrolle af organisationen logger ind på en konto på GHES-instansen, hvilket begrænser potentialet for udnyttelse.
Denne sårbarhed er også til stede i GitHub Enterprise Server (GHES). Udnyttelsen kræver dog, at en autentificeret bruger med en organisationsejer-rolle logger ind på en konto på GHES-instansen, hvilket er et vigtigt sæt formildende omstændigheder for en potentiel udnyttelse. En patch er tilgængelig i dag, den 16. januar 2024, til GHES-versionerne 3.8.13, 3.9.8, 3.10.5 og 3.11.3. Vi anbefaler, at GHES-kunder anvender plasteret så hurtigt som muligt.
Afgang af legitimationsoplysninger på vores produktionssystemer forårsagede en række serviceafbrydelser mellem den 27. og 29. december. Vi anerkender den indvirkning, de har haft på vores kunder, der er afhængige af GitHub, og vi har forbedret vores procedurer for rotation af legitimationsoplysninger for at reducere risikoen for uplanlagt nedetid i fremtiden.
Det er værd at nævne det Sårbarheden i GitHub er blevet rettet, og en opdatering er blevet frigivet produktudgivelse til GHES 3.8.13, 3.9.8, 3.10.5 og 3.11.3, GitHub karakteriserede sårbarheden i GHES som et tilfælde af "Usikker brug af Reflection", hvilket udgør en risiko for refleksionsinjektion og fjernudførelse af kode (som disse typer af sårbarheder fører til kodekørsel eller brugerkontrollerede metoder på serversiden).
Udskiftningen af disse interne nøgler resulterede i en afbrydelse af nogle tjenester fra den 27. til den 29. december. GitHub-administratorer har forsøgt at lære af fejl begået, mens de opdaterer nøgler, der påvirker kunderne.
Blandt de tiltag, opdateret GitHub GPG privat commit signeringsnøgle som bruges til at underskrive de tilsagn, du opretter på GitHub. Disse omfatter commits, der er oprettet i webeditoren, gennem et koderum, gennem kommandolinjen i et koderum, eller gennem pull request-operationer eller gennem Codespace. Den gamle nøgle blev ugyldig den 16. januar, og en ny nøgle er blevet brugt siden da. Fra den 23. januar vil alle nye tilsagn, der er underskrevet med den gamle nøgle, ikke blive markeret som bekræftet på GitHub. Den 16. januar blev de offentlige nøgler, der blev brugt til at kryptere brugerdata sendt via API'et til GitHub Actions, GitHub Codespaces og Dependabot, også opdateret.
Ud over det Brugere anbefales at bruge disse GitHub-ejede offentlige nøgler til at bekræfte commits lokalt og krypter data i transit, der sikrer, at du har opdateret dine GitHub GPG-nøgler, så dine systemer fortsætter med at fungere, efter nøglerne er ændret.
endelig hvis du er det interesseret i at vide mere om det, du kan kontrollere detaljerne I det følgende link.