Druga krytyczna luka została ujawniona w GitLab w niecały tydzień

Gitlab

Gitlab boryka się z drugim problemem bezpieczeństwa w mniej niż tydzień

W niecały tydzień Deweloperzy Gitlab musieli zabrać się do pracy, Cóż, kilka dni temu zostały wydane aktualizacje korygujące dla GitLab Collaborative Development Platform 15.3.1, 15.2.3 i 15.1.5, które usuwały krytyczną lukę.

wymienione poniżej CVE-2022-2884, ta luka może umożliwić uwierzytelnionemu użytkownikowi dostęp do GitHub Import API zdalnie uruchamiać kod na serwerze. Żadne szczegóły operacyjne nie zostały jeszcze opublikowane. Luka została zidentyfikowana przez badacza bezpieczeństwa w ramach programu nagród za luki w zabezpieczeniach HackerOne.

Jako obejście doradzono administratorowi wyłączenie importu z funkcji GitHub (w interfejsie WWW GitLab: „Menu” -> „Administrator” -> „Ustawienia” -> „Ogólne” -> „Widoczność i kontrola dostępu » -> «Importuj źródła» -> wyłącz «GitHub»).

Potem i za niecały tydzień GitLab Publikuję kolejną serię aktualizacji korygujących za ich platformę wspólnego rozwoju: 15.3.2, 15.2.4 i 15.1.6, która naprawia drugą krytyczną lukę.

wymienione poniżej CVE-2022-2992, ta luka umożliwia uwierzytelnionemu użytkownikowi wykonanie kodu zdalnie na serwerze. Podobnie jak usterka CVE-2022-2884, która została naprawiona tydzień temu, pojawił się nowy problem z interfejsem API do importowania danych z usługi GitHub. Luka objawia się między innymi w wydaniach 15.3.1, 15.2.3 i 15.1.5, w których naprawiono pierwszą lukę w kodzie importu z GitHub.

Żadne szczegóły operacyjne nie zostały jeszcze opublikowane. Luka została zgłoszona do GitLab w ramach programu nagród za luki w zabezpieczeniach HackerOne, ale w przeciwieństwie do poprzedniego problemu została zidentyfikowana przez innego autora.

Jako obejście, zaleca się administratorowi wyłączenie importu z funkcji GitHub (w interfejsie WWW GitLab: „Menu” -> „Administrator” -> „Ustawienia” -> „Ogólne” -> „Widoczność i kontrola dostępu » -> «Importuj źródła» -> wyłącz «GitHub»).

Ponadto, proponowane aktualizacje naprawiają 14 kolejnych luk, z których dwa są oznaczone jako niebezpieczne, dziesięć ma średni poziom dotkliwości, a dwa są oznaczone jako nie niebezpieczne.

Za niebezpieczne uznaje się: podatność CVE-2022-2865, który pozwala na dodanie własnego kodu JavaScript do stron wyświetlanych innym użytkownikom poprzez manipulację kolorowymi etykietami,

Możliwe było wykorzystanie luki w zabezpieczeniach, konfigurując funkcję koloru etykiety, która mogła prowadzić do zapisanego XSS, który umożliwiał atakującym wykonywanie dowolnych działań w imieniu ofiar po stronie klienta. 

Kolejną luką, która została rozwiązana za pomocą nowej serii poprawek, jest CVE-2022-2527, który umożliwia podmianę jego treści poprzez pole opisu na osi czasu skali incydentów). Luki o średnim stopniu ważności są związane przede wszystkim z możliwością odmowy usługi.

Brak walidacji długości opisów Snippet w GitLab CE/EE wpływa na wszystkie wersje przed 15.1.6, wszystkie wersje od 15.2 do 15.2.4, wszystkie wersje od 15.3 do 15.3.2 pozwala uwierzytelnionemu napastnikowi na stworzenie złośliwie dużego fragmentu które na żądanie z uwierzytelnieniem lub bez niego powoduje nadmierne obciążenie serwera, potencjalnie prowadząc do odmowy usługi.

O innych lukach które zostały rozwiązane:

  • Rejestr pakietów nie w pełni honoruje listę dozwolonych adresów IP grupy, GitLab nie uwierzytelniał się prawidłowo względem niektórych Rejestrów pakietów, gdy skonfigurowano ograniczenia adresu IP, co pozwala atakującemu, który już posiadał prawidłowy token wdrożenia, nadużyć go z dowolnej lokalizacji.
  • Nadużywanie wywołań Gitaly.GetTreeEntries prowadzi do odmowy usługi, umożliwiając uwierzytelnionemu i autoryzowanemu użytkownikowi wyczerpanie zasobów serwera przez zaimportowanie złośliwego projektu.
  • Możliwe dowolne żądania HTTP w Notatniku .ipynb ze złośliwymi znacznikami formularzy, które umożliwiają atakującemu wysyłanie dowolnych żądań HTTP.
  • Odmowa usługi z użyciem wyrażenia regularnego za pośrednictwem spreparowanych danych wejściowych umożliwiła atakującemu wywołanie wysokiego użycia procesora za pomocą spreparowanych danych wejściowych dodanych do pola Potwierdź.
  • Ujawnianie informacji za pomocą arbitralnych referencji GFM reprezentowanych w zdarzeniach na osi czasu incydentów
  • Czytaj zawartość repozytorium za pomocą funkcji LivePreview: Nieautoryzowany użytkownik mógł odczytać zawartość repozytorium, jeśli członek projektu użył spreparowanego łącza.
  • Odmowa usługi za pośrednictwem interfejsu API podczas tworzenia oddziału: niewłaściwa obsługa danych podczas tworzenia oddziału mogła spowodować wysokie użycie procesora.
  • Odmowa usługi za pośrednictwem podglądu problemu

Na koniec, jeśli chcesz dowiedzieć się więcej na ten temat, możesz zapoznać się ze szczegółami W poniższym linku.


Zostaw swój komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

*

*

  1. Odpowiedzialny za dane: Miguel Ángel Gatón
  2. Cel danych: kontrola spamu, zarządzanie komentarzami.
  3. Legitymacja: Twoja zgoda
  4. Przekazywanie danych: Dane nie będą przekazywane stronom trzecim, z wyjątkiem obowiązku prawnego.
  5. Przechowywanie danych: baza danych hostowana przez Occentus Networks (UE)
  6. Prawa: w dowolnym momencie możesz ograniczyć, odzyskać i usunąć swoje dane.