CVE-2025-48044

Biblioteka ash (wersje od 2.6.0 przed 3.34.6) zawiera podatność typu nieprawidłowa autoryzacja, która pozwala aktorowi wywnioskować dane z powiązanych rekordów, których nie może odczytać, poprzez Ash.count/2, Ash.exists/2 i Ash.aggregate/3. Ścieżka agregacji stosowała tylko politykę odczytu zasobu głównego, pomijając polityki odczytu zasobów powiązanych, co umożliwia testowanie warunków na ukrytych wierszach i odzyskiwanie ich istnienia oraz wartości atrybutów.

Ash przechowuje atrybuty typu :atom jako ciągi znaków i porównuje je jako ciągi. Gdy taki atrybut jest używany w filtrze, wartość porównania jest przekształcana przez Ash.Type.Atom. Ponieważ typ nie definiował wywołania zwrotnego coerce/2, przekształcenie spadało do domyślnego (cast_input/2), które wywołuje String.to_atom/1, gdy atrybut jest skonfigurowany z ograniczeniem unsafe_to_atom?: true. Filtrowanie takiego atrybutu za pomocą ciągów kontrolowanych przez atakującego powodowało internowanie nowego, trwałego atomu dla każdej odrębnej wartości. Atomy nigdy nie są usuwane przez garbage collector, a BEAM ogranicza tabelę atomów, więc aktor mogący dostarczać wartości filtrów dla publicznego, filtrowalnego atrybutu :atom zadeklarowanego z unsafe_to_atom?: true może wyczerpać tabelę atomów i spowodować awarię węzła (odmowa usługi). AshPaperTrail jest godnym uwagi przykładem: jego zasoby wersji domyślnie udostępniają publiczny, filtrowalny atrybut atomowy version_action_name z unsafe_to_atom?: true. Poprawka dodaje coerce/2 do Ash.Type.Atom, które nigdy nie internowuje atomów — wartość porównania pozostaje ciągiem, ponieważ typ jest przechowywany i porównywany jako ciąg. Ustawianie atrybutu z danych wejściowych akcji (cast_input/2, które nadal respektuje unsafe_to_atom?) pozostaje bez zmian. Problem dotyczy ash: od 3.5.1 przed 3.34.3.

Podatność w bibliotece Ash pozwala użytkownikowi ustawić wartość prywatnego argumentu akcji na ścieżkach masowego usuwania i masowej aktualizacji. Argumenty zadeklarowane jako public?: false powinny być ustawiane tylko przez zaufany kod serwerowy, ale brak sprawdzenia public? w tych ścieżkach umożliwia ich modyfikację z danych wejściowych użytkownika.

W Ash przed wersją 3.33.4, polityki pól (field_policies) mają chronić przed ujawnianiem informacji przez filtry, ale nilling (zastępowanie wartością nil) był stosowany tylko do atrybutów, nie do obliczeń (calculations) ani agregatów (aggregates). Użytkownik może odwołać się w filtrze do obliczenia lub agregatu, którego nie może zobaczyć, i użyć filtra jako wyroczni do odczytania chronionej wartości (np. filter(secret_calc == "x")).

Nieprawidłowa walidacja określonej ilości w danych wejściowych w ash-project ash pozwala atakującemu na przechowywanie wartości o dowolnym rozmiarze w atrybucie, którego ograniczenie długości powinno ją ograniczać. Ash mierzy długość stringa za pomocą String.length/1 z Elixira, która liczy grafy Unicode, w ograniczeniach max_length i min_length Ash.Type.String, w Ash.Resource.Validation.StringLength oraz w funkcji wyrażenia string_length. Graf może zawierać nieograniczoną liczbę znaków łączących, więc podstawowy znak z milionem akcentów ostrych to jeden graf i megabajty danych, spełniający max_length: 2. Tam, gdzie warstwa danych nie nakłada niezależnego limitu (ETS, Mnesia lub kolumna text w Postgresie), cała wartość jest zapisywana, więc atakujący może zapisać całe ciało żądania do atrybutu z małym maksimum i nieograniczenie zwiększać pamięć. Jednostka liczenia różni się również od warstwy przechowywania, która liczy punkty kodowe, a nie grafy, więc wartość zaakceptowana przez ograniczenie może zostać odrzucona lub obcięta przez kolumnę. Kolumna varchar(n) w Postgresie ogranicza samą wartość i nie jest narażona. Problem dotyczy ash: od 0.10.0 przed 3.33.0.

Podatność nieprawidłowej autoryzacji w ash-project ash zwraca rekordy, które polityka odczytu w czasie wykonania (runtime read policy) odmawia każdemu aktorowi. Gdy zasób ma politykę odczytu typu :runtime (sprawdzaną per rekord, a nie kompilowaną do filtra), Ash.Policy.Authorizer decyduje o każdym rekordzie w check_result/1, odrzucając niemożliwe scenariusze polityki i sprawdzając, co pozostaje. Gdy każdy scenariusz dla rekordu był niemożliwy, co oznacza, że żadna polityka nie może go autoryzować i musi być zabroniony, gałąź pustego scenariusza zamiast tego zachowywała rekord i zwracała go jako autoryzowany. Poprawka zabrania rekordu, którego wszystkie scenariusze są niemożliwe. Problem dotyczy ash od 3.4.44 przed 3.32.2.

W bibliotece ash występuje podatność nieprawidłowej autoryzacji, która poszerza filtr zakresu relacji parent(...) tak, że dopasowuje niezamierzone rekordy, gdy nie można rozwiązać odwołania do pola nadrzędnego. W takich przypadkach odwołanie jest rozwiązywane do nil, co powoduje, że predykaty takie jak org_id == parent(org_id) stają się dopasowaniem IS NULL, a warunki typu is_nil(parent(org_id)) aktywują nieograniczoną gałąź, przez co relacja zwraca rekordy, które powinny być wykluczone. Poprawka powoduje błąd odczytu, gdy odwołanie parent(...) nie może być rozwiązane.

Podatność na nieprawidłową autoryzację w ash pozwala na autoryzację agregatu pod jednym działaniem odczytu, a obliczenie go pod innym, co może prowadzić do uruchomienia agregatu z politykami niezgodnymi z działaniem, dla którego był autoryzowany. Może to umożliwić ujawnienie informacji o rekordach, których aktor nie powinien czytać.

W bibliotece ash występuje podatność braku autoryzacji, która pozwala aktorowi na aktualizację rekordów zabronionych przez polityki zasobów poprzez ścieżkę atomową Ash.update_many/4. Gdy używana jest strategia atomowa, zapytanie aktualizuje wszystkie wiersze pasujące do klucza głównego bez stosowania polityk, co pozwala na modyfikację rekordów należących do innych aktorów lub tenantów. Poprawka ogranicza ścieżkę atomową do warstw danych wspierających filtry changeset, autoryzuje każdy changeset i scala filtr polityki.

W bibliotece ash występuje podatność nieprawidłowej kontroli dostępu, która pozwala akcji tworzenia nadpisać istniejący rekord, gdy używana jest warstwa danych ETS lub Mnesia, ponieważ nie egzekwują one unikalności klucza głównego. Atakujący, który może ustawić klucz główny podczas tworzenia, może cicho nadpisać istniejący rekord, niszcząc dane innego podmiotu bez przechodzenia przez akcję aktualizacji i jej polityki. Poprawka odrzuca tworzenie, gdy klucz główny już istnieje.