Gitlab lider av et nytt sikkerhetsproblem på mindre enn en uke
På mindre enn en uke Gitlab-utviklere har måttet begynne å jobbe, Vel, for noen dager siden ble de korrigerende oppdateringene for GitLab Collaborative Development Platform 15.3.1, 15.2.3 og 15.1.5 utgitt, som løste en kritisk sårbarhet.
oppført under CVE-2022-2884, dette sikkerhetsproblemet kan tillate en autentisert bruker med tilgang til GitHub Import API eksternt kjøre kode på en server. Ingen operasjonelle detaljer er foreløpig offentliggjort. Sårbarheten ble identifisert av en sikkerhetsforsker som en del av HackerOnes sårbarhetsprogram.
Som en løsning ble administratoren anbefalt å deaktivere importen fra GitHub-funksjonen (i GitLab-nettgrensesnittet: "Meny" -> "Admin" -> "Innstillinger" -> "Generelt" -> "Synlighet og tilgangskontroller » -> «Importer kilder» -> deaktiver «GitHub»).
Etter det og om mindre enn en uke GitLab Jeg publiserer neste serie med korrigerende oppdateringer for deres samarbeidende utviklingsplattform: 15.3.2, 15.2.4 og 15.1.6, som fikser den andre kritiske sårbarheten.
oppført under CVE-2022-2992, dette sikkerhetsproblemet lar en autentisert bruker kjøre kode eksternt på en server. I likhet med CVE-2022-2884-sårbarheten som ble fikset for en uke siden, er det et nytt API-problem for import av data fra GitHub-tjenesten. Sårbarheten manifesterer seg blant annet i utgivelser 15.3.1, 15.2.3 og 15.1.5, der den første sårbarheten i importkoden fra GitHub ble fikset.
Ingen operasjonelle detaljer er foreløpig offentliggjort. Sårbarheten ble sendt til GitLab som en del av HackerOnes sårbarhetspremieprogram, men i motsetning til forrige utgave ble den identifisert av en annen bidragsyter.
Som en løsning anbefales det at administratoren deaktiverer importen fra GitHub-funksjonen (i GitLab-nettgrensesnittet: "Meny" -> "Admin" -> "Innstillinger" -> "Generelt" -> "Synlighet og tilgangskontroller » -> «Importer kilder» -> deaktiver «GitHub»).
Videre foreslåtte oppdateringer fikser 14 flere sårbarheter, hvorav to er merket som farlige, ti har middels alvorlighetsgrad og to er merket som ufarlige.
Følgende er anerkjent som farlige: sårbarhet CVE-2022-2865, som lar deg legge til din egen JavaScript-kode til sidene som vises til andre brukere gjennom manipulering av fargeetiketter,
Det var mulig å utnytte en sårbarhet ved å konfigurere etikettfargefunksjonen som kunne føre til lagret XSS som tillot angripere å utføre vilkårlige handlinger på vegne av ofre på klientsiden.
En annen av sårbarhetene som ble løst med den nye serien med korreksjoner, er CVE-2022-2527, som gjør det mulig å erstatte innholdet gjennom beskrivelsesfeltet på tidslinjen for hendelsesskalaen). Middels alvorlige sårbarheter er først og fremst knyttet til tjenestenektpotensial.
Mangel på lengdevalidering på Snippet-beskrivelser i GitLab CE/EE som påvirker alle versjoner før 15.1.6, alle versjoner fra 15.2 før 15.2.4, alle versjoner fra 15.3 før 15.3.2 lar en autentisert angriper lage en ondsinnet stor kodebit som, når det blir bedt om med eller uten autentisering, forårsaker overdreven belastning på serveren, som potensielt kan føre til tjenestenekt.
Av de andre sårbarhetene som ble løst:
- Pakkeregisteret respekterer ikke gruppens IP-tillatelsesliste fullt ut, GitLab autentiserte ikke riktig mot noen pakkeregister da IP-adressebegrensninger ble konfigurert, noe som tillater en angriper som allerede hadde et gyldig distribusjonstoken, vil misbruke det fra et hvilket som helst sted.
- Misbruk av Gitaly.GetTreeEntries-anrop fører til tjenestenekt, noe som lar en autentisert og autorisert bruker tømme serverressurser ved å importere et ondsinnet prosjekt.
- Mulige vilkårlige HTTP-forespørsler i .ipynb Notebook med ondsinnede skjemakoder, som lar en angriper utstede vilkårlige HTTP-forespørsler.
- Regulært uttrykk for tjenestenekt via laget inndata tillot en angriper å utløse høy CPU-bruk via en laget inndata lagt til i feltet Bekreft melding.
- Informasjonsavsløring gjennom vilkårlige GFM-referanser representert i hendelser på tidslinjen
- Les depotinnhold via LivePreview-funksjonen: Det var mulig for en uautorisert bruker å lese depotinnhold hvis et prosjektmedlem brukte en laget lenke.
- Denial of Service via API når du oppretter en filial: Feil datahåndtering ved opprettelse av filial kan ha blitt brukt til å utløse høy CPU-bruk.
- Nektelse av tjenesten via forhåndsvisning av problemet
Til slutt, hvis du er interessert i å vite mer om det, kan du se detaljene I den følgende lenken.