Podatności Rekor

Rekor w wersjach 1.4.3 i starszych pozwala na SSRF do dowolnych usług wewnętrznych, ponieważ /api/v1/index/retrieve obsługuje pobieranie klucza publicznego z adresu URL podanego przez użytkownika. SSRF może wywoływać tylko żądania GET, nie zmienia stanu, a odpowiedź nie jest zwracana, więc możliwy jest jedynie blind SSRF (sondujący sieć wewnętrzną).

W Rekor (log przejrzystości łańcucha dostaw oprogramowania) w wersjach 1.4.3 i starszych implementacja wpisu może spowodować panikę przy przetwarzaniu danych kontrolowanych przez atakującego, gdy kanonizowany jest proponowany wpis z pustym polem spec.message. Funkcja validate() zwraca nil (sukces) dla pustej wiadomości, pozostawiając sign1Msg niezainicjalizowany, a Canonicalize() później dereferencjonuje v.sign1Msg.Payload, co prowadzi do dereferencji wskaźnika nil. Wątek jest odzyskiwany, więc klient otrzymuje błąd 500, a usługa działa dalej, więc wpływ na dostępność jest minimalny. Problem naprawiono w wersji 1.5.0.

Rekor, system rejestru przejrzystości łańcucha dostaw, zawiera podatność na atak typu „bomba dekompresyjna” w funkcji `Package.Unmarshal()` dla plików APK. Atakujący może przesłać specjalnie spreparowany plik APK, który po dekompresji zajmuje ogromną ilość pamięci, powodując awarię serwera. Podatność dotyczy wersji od 0.3.0 do 1.5.1 i jest dostępna przez dwa nieuwierzytelnione endpointy.

Podatność w Rekor polega na tym, że źle sformatowany wpis typu `intoto/v0.0.2` może spowodować panikę w wątku procesu Rekor. Mimo to, usługa nadal działa, a użytkownik otrzymuje komunikat o błędzie 500.