Jak uniknąć ataków sekwencji ucieczki na terminalach?

Czytając szczegóły CVE-2009-4487 (który dotyczy niebezpieczeństwa sekwencji specjalnych w plikach dziennika) jestem nieco zaskoczony.

Cytując CVE-2009-4487 :

nginx 0.7.64 zapisuje dane do pliku dziennika bez odkażania znaków niedrukowalnych, co może pozwolić zdalnym atakującym na modyfikację tytułu okna, ewentualnie wykonanie dowolnych poleceń lub zastąpienie plików, za pośrednictwem żądania HTTP zawierającego sekwencję ucieczki dla emulatora terminala.

Najwyraźniej tak naprawdę nie chodzi o lukę w zabezpieczeniach w nginx, ale w emulatorach terminali.

Jasne, być może przesłanie catpliku dziennika do terminala dzieje się tylko przypadkowo, ale grepplik dziennika jest dość powszechny. lessmoże dezynfekuje sekwencje specjalne, ale kto wie, które polecenia powłoki nie zmieniają sekwencji specjalnych ...

Zwykle zgadzam się z odpowiedzią lakieru :

Mądrość ucieczek terminala-odpowiedź w ogóle była kwestionowana w regularnych odstępach czasu, ale nadal żaden z głównych programów emulacji terminalu nie uznał za stosowne odrzucić te sekwencje, prawdopodobnie w przypadku błędnej próby zgodności z nieużywaną już technologią z lat 70-tych. [..] Zamiast obwiniać wszystkie programy, które zapisują logi, byłoby znacznie bardziej produktywne, z punktu widzenia bezpieczeństwa, aby programy do emulacji terminali przestały robić głupie rzeczy, a tym samym naprawić to i inne problemy bezpieczeństwa raz i dla wszystkich.

Zatem moje pytania:

Jak mogę zabezpieczyć swój Xterm, aby nie było już możliwe wykonywanie poleceń ani zastępowanie plików za pomocą sekwencji ucieczki?

Jakie emulatory terminali dla X są zabezpieczone przed tym atakiem?

Terminale VT100 (które do pewnego stopnia emulują wszystkie współczesne emulatory terminali) obsługiwały wiele problematycznych poleceń, ale nowoczesne emulatory lub dystrybucje wyłączają te bardziej problematyczne i mniej przydatne. Oto niewyczerpująca lista potencjalnie ryzykownych sekwencji ucieczki (z wyłączeniem tych, które po prostu sprawiają, że wyświetlanie jest w jakiś sposób nieczytelne):

• Polecenia dowolnego pliku dziennika w rxvt i Eterm zgłoszone przez HD Moore . To są naprawdę poważne błędy, na szczęście długo naprawione.
• Komenda answerback, znana również jako Return Terminal Status, wywoływana przez ENQ( Ctrl+E). Powoduje to wstawienie tekstu do terminala, tak jakby użytkownik go wpisał. Jednak ten tekst nie jest pod kontrolą atakującego: jest to nazwa terminala, zwykle coś w rodzaju xtermlub screen. W moim systemie (ściśnięcie Debiana) xterm domyślnie zwraca pusty ciąg znaków (jest to kontrolowane przez answerbackStringzasób).
• Polecenia wysyłania atrybutów urządzeń ESC [ ci znajomych. Terminal odpowiada ESC [ … c(gdzie …może zawierać tylko cyfry i znaki interpunkcyjne ASCII). Jest to sposób na sprawdzenie niektórych możliwości terminalu, głównie przestarzałych, ale być może używanych przez stare aplikacje. Ponownie, odpowiedź terminalu jest nie do odróżnienia od danych wprowadzonych przez użytkownika, ale nie jest pod kontrolą atakującego. Sekwencja kontrolna może wyglądać jak klawisz funkcyjny, ale tylko wtedy, gdy użytkownik ma nietypową konfigurację (żadne z typowych ustawień, które napotkałem, nie ma prawidłowej sekwencji specjalnej klawisza funkcyjnego, która jest prefiksem odpowiedzi terminala).
• Różne funkcje sterowania urządzeniem (DCS ucieka, zaczynając od ESC P).
  • Nie wiem, jaką szkodę można wyrządzić DECUDK(ustawiając klucze zdefiniowane przez użytkownika) w typowym emulatorze terminali.
  • DECRQSS(Request Status String) to kolejne polecenie, na które terminal reaguje sekwencją ucieczki, tym razem zaczynając od \eP; może to być problematyczne, ponieważ \ePjest to prawidłowy klucz ( Alt+ Shift+ P).
  • Xterm ma jeszcze dwie funkcje eksperymentalne: ESC P + p …oraz ESC P + q …, aby uzyskać i ustawić ciągi termcap. Z opisu można tego użyć przynajmniej do modyfikacji działania klawiszy funkcyjnych.
• Kilka poleceń raportu o stanie: ESC [ … n(Raport o stanie urządzenia). Terminal odpowiada sekwencją ucieczki. Większość tych sekwencji ucieczki nie odpowiada sekwencjom ucieczki klawiszy funkcyjnych. Jeden wydaje się problematyczny: raport ESC [ 6 nma formę, gdzie i są sekwencjami cyfrowymi, i może to wyglądać jak w przypadku niektórych modyfikatorów.ESC [ x ; y RxyF3
• Polecenia manipulowania oknem ESC [ … t.
  • Niektóre z nich pozwalają na zmianę rozmiaru okna, ikonkę itp., Co jest uciążliwe.
  • Niektóre z nich powodują, że terminal odpowiada sekwencją ucieczki. Większość z tych sekwencji ucieczki wygląda na małe ryzyko, jednak istnieją dwa niebezpieczne polecenia: odpowiedzi na ESC [ 2 0 ti odpowiednio ESC [ 2 1 tzawierają etykietę i tytuł okna terminala, a atakujący może je wybrać.
  • Przynajmniej w przypadku ściśnięcia Debiana xterm domyślnie ignoruje te polecenia; można je włączyć, ustawiając allowWindowOpszasób lub selektywnie poprzez disallowedWindowOpszasób. Gnome-terminal pod Ubuntu 10.04 domyślnie implementuje nawet odpowiedzi zwrotne tytułu. Nie sprawdziłem innych terminali ani wersji.
• Polecenia do ustawienia tytułu lub nazwy terminala. Pod xterm i większości innych terminali X, są . W obszarze Screen sekwencją ucieczki jest . Uważam, że troska o te polecenia jest przereklamowana. Chociaż pozwalają na pewne psoty, każda strona internetowa ma ten sam problem. Działanie na oknie opartym wyłącznie na jego tytule, a nie na jego klasie, przypomina otwieranie pliku, którego nazwa została ci nadana przez niezaufaną stronę, nie cytowanie zmiennego rozszerzenia w skrypcie powłoki lub poklepywanie wściekłego psa po nosie - nie narzekaj, jeśli zostaniesz ugryziony.ESC ] digit ; title ESC \ESC k title ESC \

Uważam, że odpowiedź Varnisha jest nieszczera. Wygląda na to, że albo próbuje zmienić winę, albo działa w trybie nazistowskim (wszelkie obawy dotyczące bezpieczeństwa, autentyczne lub nie, uzasadniają blackballing funkcji).

Mądrość ucieczek terminala-odpowiedź w ogóle była kwestionowana w regularnych odstępach czasu, ale nadal żaden z głównych programów emulacji terminalu nie uznał za stosowne odrzucić te sekwencje, prawdopodobnie w przypadku błędnej próby zgodności z nieużywaną już technologią z lat 70-tych. (...)
Zamiast obwiniać wszystkie programy, które zapisują logi, byłoby znacznie bardziej produktywne, z punktu widzenia bezpieczeństwa, aby programy do emulacji terminali przestały robić głupie rzeczy, a tym samym naprawić to i inne problemy bezpieczeństwa raz i dla wszystkich.

Wiele odpowiedzi zwrotnych to przydatne funkcje: aplikacja musi wiedzieć takie rzeczy, jak pozycja kursora i rozmiar okna. Bardzo przydatne jest również ustawienie tytułu okna. Byłoby możliwe poleganie wyłącznie na ioctlwywołaniach tych, jednak wymagałoby to dodatkowego kodu i narzędzi do wykonania tych ioctlwywołań i przekształcenia ich w tekst w stylu uniksowym, przekazujący deskryptory plików. Zmiana tych interfejsów byłaby teraz bardzo pracochłonna, bez większych korzyści.

Pliki tekstowe nie powinny zawierać znaków niedrukowalnych, takich jak znaki kontrolne. Pliki dziennika są zwykle plikami tekstowymi. Pliki dziennika nie powinny zawierać znaków kontrolnych.

Jeśli martwisz się, że plik może zawierać sekwencje, otwórz go w edytorze lub zobaczyć ją lessbez -rlub -Ropcji, lub zobaczyć go przez cat -v.

To nie jest takie proste; wiele osób ma kod, aby ustawić xtermtytuł w ramach monitu itp., i to z bardzo dobrych powodów (jak każdy, kto jest shutdownniewłaściwą maszyną z niewłaściwego okna terminala, może ci powiedzieć!). Prawidłowe naprawienie go wymaga zatem wprowadzenia kontekstów bezpieczeństwa, a tym samym poważnego komplikowania interakcji między powłokami i emulatorami terminali a prawdopodobnie także plikami kropkowymi ludzi. Lub możesz zastosować rozwiązanie z niskim czynszem dezynfekujące wszystko, co może być wyświetlane w terminalu; ogranicza się to w dużej mierze do ucieczkowych znaków kontrolnych, co prawdopodobnie powinno być zrobione, aby się wyróżnić (ponieważ w pliku dziennika mogą wskazywać, że ktoś próbuje wstrzyknąć kod powłoki).

( Nawiasem mówiąc , punycode jest poważniejszym przykładem tego samego rodzaju problemu - i mimo to został oficjalnym standardem. Czasami bezpieczeństwo sprowadza się do łagodzenia niepewnych projektów, które są poza kontrolą użytkownika.)