Lista dozwolonych poleceń nie przechytrzy powłoki

Agent programistyczny proponuje polecenie powłoki. Zanim ono się wykona, niewielki fragment kodu decyduje, czy zapytać człowieka, czy przepuścić je bez pytania. W Roo Code ten fragment kodu dostał właśnie pięć CVE jednego dnia i każde działa tak samo: bramka czyta polecenie na jeden sposób, powłoka na inny, a wykonuje się wersja powłoki.

Dwa parsery, jeden napis

Bramka zatwierdzająca polecenia powłoki jest, czy jej autorzy tego chcieli, czy nie, drugim parserem powłoki. Zanim porówna polecenia z listą, musi je wszystkie znaleźć w jednym napisie. Prawdziwym parserem jest bash, za którym stoją dekady gramatyki: reguły cytowania, podstawienia, przekierowania, rozwijanie wzorców i nowa składnia w każdym wydaniu. Bramka to kilka wyrażeń regularnych.

Wszędzie tam, gdzie te dwa parsery nie zgadzają się, gdzie polecenie się zaczyna i kończy, atakujący wybiera, którą wersję zobaczy bramka. Słabość przypisana czterem z pięciu rekordów nazywa się dokładnie tak: konflikt interpretacji. To najuczciwiej dobrane CWE, jakie widzieliśmy w tym roku.

>&echo X            przekierowanie usunięte, reszta wygląda jak echo
echo \";X;\"         cudzysłów z ukośnikiem maskuje separatory
echo ${ X; }         funsub odczytany jako rozwinięcie parametru
echo *$(X)          podstawienie znika razem ze wzorcem glob
$(echo X)           wynik echo staje się poleceniem

Żadne z nich nie wymaga sprytnego ładunku. Każde to zwykła składnia powłoki, której bramka po prostu nie modeluje. Ostatnie jest najczystsze: bramka sprawdza polecenie wewnętrzne, widzi niegroźne echo i zatwierdza. Powłoka uruchamia echo, a potem wykonuje to, co echo wypisało.

Dlaczego kolejna łatka by tego nie zamknęła

Kod miał już osobne sprawdzenie niebezpiecznych podstawień, czyli ręcznie spisaną listę form, które trzeba pokazać człowiekowi. Przypadek z wzorcem glob dostał własną etykietę, niepełną listę niedozwolonych danych, bo tym zawsze staje się lista znanych złych kształtów. Każde z tych obejść da się załatać jeszcze jednym wyrażeniem regularnym, a załatana bramka nadal będzie częściową kopią basha, która goni oryginał, a oryginał się zmienia: jedno z pięciu obejść używa składni, której starsze wydania basha w ogóle nie przyjmują.

Wyzwalaczem jest treść, nie użytkownik

Rekordy wskazują pośredni prompt injection jako drogę wejścia. Nikt tych poleceń nie wpisuje. Agent czyta README, zgłoszenie albo stronę WWW z instrukcjami, proponuje polecenie w jednym z powyższych kształtów, a bramka je zatwierdza, bo widoczny początek jest na liście. Zaufanie to powierzchnia ataku: liście ufano, że opisuje to, co się wykona, a opisywała tylko to, co bramce udało się sparsować.

Co konkretnie zrobić

• Wyłącz teraz automatyczne zatwierdzanie poleceń w Roo Code. Żaden rekord nie wskazuje wersji z poprawką, więc to ustawienie jest jedyną kontrolą, jaką masz. Każde polecenie trafi wtedy do człowieka.
• Sprawdź pod tym kątem każdego agenta programistycznego w firmie. Jeśli automatyczne zatwierdzanie polega na dopasowywaniu początku napisu dla powłoki, zakładaj, że ta sama klasa obejść istnieje, dopóki ktoś nie wykaże inaczej. Forki jednego kodu dzielą jeden parser.
• Jeśli budujesz agenty, przestań przekazywać napisy powłoce. Uruchamiaj narzędzia jako listę argumentów bez powłoki pośrodku albo odmawiaj automatycznego zatwierdzenia każdego polecenia, które zawiera jakikolwiek metaznak powłoki. Oba podejścia są toporniejsze niż parser i oba są poprawne.
• Postaw granicę pod agentem. Kontener albo sandbox bez Twoich poświadczeń ogranicza to, do czego dosięgnie zatwierdzone polecenie, niezależnie od tego, który parser dał się oszukać.