Podatności Backstage

Backstage przed wersją 4.1.0 w pakiecie @backstage/plugin-scaffolder-backend może ujawniać wartości pochodzące z sekretów w logach zadań Scaffolder. Dotyczy to instalacji, które konfigurują wrażliwe sekrety scaffolder.defaultEnvironment.secrets i pozwalają atakującemu na tworzenie lub modyfikację szablonów Scaffolder. Autor szablonu może spowodować, że wartości pochodzące z sekretów używane podczas iteracji szablonu zostaną zapisane i ujawnione użytkownikom mającym dostęp do logów zadań.

Backstage przed wersją 3.9.1 w pakiecie @backstage/plugin-catalog-backend ma niespójną ocenę uprawnień dla właściwości katalogu. W instalacjach, które używają warunków uprawnień opartych na wartościach jako granicy poufności, uwierzytelniony użytkownik może otrzymać dane encji katalogu, które autorzy polityki zamierzali ograniczyć.

Pakiet @backstage/plugin-catalog-backend w Backstage przed wersją 3.9.1 nieegzekwuje spójnie dozwolonych typów lokalizacji podczas przetwarzania katalogu. W pewnych konfiguracjach backend może przetwarzać typy lokalizacji, które nie powinny być dozwolone, co może prowadzić do niezamierzonego dostępu do plików na hoście backendu.

Backstage przed wersją 0.17.8 w pakiecie @backstage/backend-defaults ma nieprawidłową walidację danych wejściowych w czytnikach URL magazynu w chmurze. Atakujący z dostępem do zapisu do zasobnika magazynu w chmurze używanego przez Backstage może stworzyć nazwy obiektów, które mogą kolidować z chronionymi plikami w katalogu wyjściowym. W niektórych konfiguracjach może to prowadzić do wstrzyknięcia treści.

Dostawcy katalogu magazynu w chmurze w Backstage przed wersją 1.54.6 nie weryfikowali wystarczająco ścieżek obiektów. Podmiot mogący tworzyć lub zmieniać nazwy obiektów w skonfigurowanym źródle katalogu Azure Blob Storage lub AWS S3 mógł spowodować odczyt deskryptorów katalogu spoza zamierzonej granicy magazynu, ograniczony do lokalizacji osiągalnych za pomocą skonfigurowanych poświadczeń backendu.

Backstage przed wersją 0.6.17 w pakiecie @backstage/plugin-proxy-backend ma nieprawidłową walidację danych wejściowych w proxy-backend. Uwierzytelniony użytkownik Backstage może skonstruować URL żądania, które powoduje przekazanie żądania do ścieżki poza skonfigurowaną ścieżką bazową na serwerze docelowym. Ogranicza się to do serwerów docelowych już skonfigurowanych jako punkty końcowe proxy i wymaga domyślnie uwierzytelnienia Backstage.

Backstage przed wersją 2.2.4 w pakiecie @backstage/plugin-techdocs-backend ma nieprawidłową walidację danych wejściowych w żądaniach statycznych treści techdocs. Przy użyciu dostawcy Azure Blob Storage, uwierzytelniony użytkownik Backstage może być w stanie odczytać ograniczone treści TechDocs, gdy włączone są uprawnienia na poziomie encji. Instalacje, które celowo wyłączają domyślną politykę uwierzytelniania backendu, mogą mieć szerszy zakres narażenia.

Backstage przed wersją 2.2.4 w pakiecie @backstage/plugin-techdocs-backend ma nieprawidłowe egzekwowanie autoryzacji dla statycznych treści techdocs. Uwierzytelniony użytkownik z dostępem do jednej witryny dokumentacji TechDocs może skonstruować URL umożliwiający odczyt dokumentacji należącej do innej encji. Dotyczy to tylko instalacji używających zewnętrznego buildera TechDocs z zewnętrznym dostawcą magazynu (S3, GCS itp.) i włączonym frameworkiem uprawnień. Instancje nieużywające frameworka uprawnień nie są dotknięte, ponieważ treści TechDocs są domyślnie widoczne dla wszystkich uwierzytelnionych użytkowników.

Pakiet @backstage/plugin-kubernetes-backend w Backstage przed wersją 0.21.10 jest dotknięty nieobsługiwanym trybem uwierzytelniania klastra katalogu w backendzie Kubernetes. Wdrożenia korzystające z odkrywania klastrów katalogu mogą być dotknięte, gdy kontrybutorzy katalogu mogą tworzyć lub modyfikować encje zasobów kubernetes-cluster. Przy wymaganych uprawnieniach do punktów końcowych i RBAC podów backend może użyć swojej lokalnej tożsamości w klastrze, potencjalnie ujawniając zasoby Kubernetes czytelne dla tej tożsamości. Poświadczenie jest używane tylko z lokalnym punktem końcowym API w klastrze i nie jest wysyłane do punktu końcowego dostarczonego przez katalog.

Backstage przed wersją 0.8.7 w pakiecie @backstage/plugin-catalog-backend-module-gitlab ma nieprawidłową autoryzację w ingestii użytkowników organizacji GitLab. Instalacje, które włączają ingestię zdarzeń organizacji GitLab i polegają na ograniczonych użytkownikach katalogu jako granicy dostępu, mogą dopuścić nieprzewidzianą tożsamość katalogu. W zależności od konfiguracji logowania i uprawnień może to umożliwić nieautoryzowany dostęp z uprawnieniami standardowego uwierzytelnionego użytkownika.

Backstage przed wersją 1.54.6 nie egzekwuje spójnie granic poświadczeń w akcjach scaffolder source-control. Uwierzytelniony użytkownik może spowodować, że akcja użyje szerszych poświadczeń integracji i wykona operacje z większym dostępem niż zamierzono. Problem naprawiono w wersji 1.54.6, pod warunkiem włączenia przez operatorów opcji scaffolder.requireScmUserCredentials po aktualizacji.

Backstage to otwarta platforma do budowania portali deweloperskich. Przed wersjami 3.3.1, 3.4.1, 4.0.3 i 4.1.0 pakiet @backstage/plugin-scaffolder-backend jest podatny na ujawnienie wrażliwych informacji w narzędziu Scaffolder. Uwierzytelniony użytkownik Backstage, który może odczytać zadanie Scaffolder innego użytkownika, może otrzymać wewnętrzne dane wykonawcze.

Backstage przed wersją 0.29.2 ma podatność w eksperymentalnych funkcjach dynamicznej rejestracji klienta i metadanych dokumentów ID klienta w @backstage/plugin-auth-backend. Użycie pełnego dopasowania glob może pozwolić na obejście listy dozwolonych URI przekierowań, umożliwiając atakującemu otrzymanie kodu autoryzacji OAuth po ukończeniu przepływu przez ofiarę. Funkcje są eksperymentalne i domyślnie wyłączone.

Backstage jest podatny na ataki typu path traversal przez dowiązania symboliczne w akcjach Scaffolder i ekstrakcji archiwów. Atakujący z dostępem do tworzenia i wykonywania szablonów Scaffolder może odczytać, usunąć lub zapisać pliki poza dozwolonym obszarem roboczym.