Dwie dziesiątki i żadna nie jest błędem AI

W tym tygodniu dwa advisory dostały pełną dziesiątkę. Oba siedzą w korporacyjnym produkcie sprzedawanym jako platforma AI. Jedno to SQL injection, drugie code injection. Ich klasy słabości skatalogowano, zanim większość branży usłyszała określenie duży model językowy.

I to jest właśnie ta historia, przecinająca sposób, w jaki zwykle się o tym pisze. Ciekawe pytanie nie brzmi, jakie nowe ataki wymyśliło AI. Brzmi: ile z tej nowej powierzchni przenosi bardzo stare błędy.

Dwa najgorsze są zwyczajne

Nieuwierzytelnione dowolne SQL do bazy instancji. Nieuwierzytelnione wykonanie dowolnego kodu na platformie. Zdejmij nazwę produktu, a to są znaleziska, które dało się napisać w 2005 roku, i zalecenie naprawcze byłoby identyczne: sparametryzuj zapytanie, przestań ewaluować napisy, na które wpływa atakujący.

Etykieta AI nie jest tu podatnością. Jest powodem, dla którego ten kod istnieje, i powodem, dla którego powstał szybko. Nowa linia produktowa to nowa baza kodu, nowy zestaw endpointów i nowy termin, a te trzy rzeczy zawsze dawały ten efekt.

Jedno jest naprawdę nowe

Jest też framework agentowy, w którym zdalne wykonanie kodu przychodzi przez prompt injection. Jego narzędzia pythonowe i powłokowe biorą argumenty wyprodukowane przez model i podają je, nieodkażone, do miejsc wykonania:

exec()
runpy.run_path()
subprocess.run()

Atakujący nigdy nie dotyka tych wywołań. Wpisuje coś na stronę albo do dokumentu, agent czyta to w ramach swojej pracy, a model uprzejmie produkuje argument. Wejście jest przepuszczone przez model i właśnie to czyni je trudnym do odfiltrowania: zanim napis dotrze do miejsca wykonania, wygenerował go Twój własny, zaufany komponent.

To nie jest stary błąd w nowym miejscu. Granica zaufania faktycznie się przesunęła i biegnie teraz między modelem a narzędziami, które może wywołać.

I jedno, które jest jednym i drugim naraz

Najbardziej pouczający jest przypadek IDE, którego tryb agentowy potrafił zapisać poza obszarem roboczym. Klasa słabości to path traversal, czyli rzecz całkowicie leciwa. Nowe jest to, skąd wzięła się ścieżka: podał ją model, a sprawdzenie zawierania, które złapałoby ścieżkę od użytkownika, nigdy nie zostało zastosowane do ścieżki od modelu.

To jest most między dwiema połowami tej listy. Klasa błędu jest stara. Powodem, dla którego nikt nie zwalidował wejścia, jest to, że przyszło od komponentu, który kod uznawał za część siebie.

Doszło do przeglądarki

Wydana przeglądarka mobilna Microsoftu ma teraz własny identyfikator za prompt injection. Ocena jest umiarkowana, a skutkiem jest spoofing, a nie przejęcie, więc to nie jest część niepokojąca. Niepokojąca jest kategoria: prompt injection przestał być ograniczony do czyjegoś frameworka agentowego na GitHubie. Jest w oprogramowaniu z setkami milionów instalacji i będą go oceniać zespoły, które nigdy nie musiały o tym myśleć.

Co z tym realnie zrobić

• Przejrzyj produkt AI najpierw jak zwykłą aplikację webową. Najgorsze znaleziska tego tygodnia wyłapałby zwyczajny przegląd appsec, a nie cokolwiek specyficznego dla agentów.
• Dopiero potem dodaj tę jedną nową granicę. Traktuj wyjście modelu jak niezaufane wejście do każdego narzędzia, do którego sięga, zwłaszcza tego, które wykonuje kod, zapisuje pliki albo wysyła żądania.
• Zastosuj istniejącą walidację do wartości pochodzących od modelu. Sprawdzanie zawierania ścieżek, listy dozwolonych i kanonikalizacja zwykle już u Ciebie są, tylko nie są podpięte do tego źródła.
• Sprawdź, gdzie Twoje narzędzia agentowe trzymają klucze dostawców. Co najmniej jeden projekt w tym tygodniu zapisywał je na dysk otwartym tekstem, pod przewidywalną nazwą.