Security

如何避免終端中的轉義序列攻擊?

  • April 3, 2017

閱讀CVE-2009-4487 的詳細資訊(這是關於日誌文件中轉義序列的危險)我有點驚訝。

引用CVE-2009-4487

nginx 0.7.64 將數據寫入日誌文件而不清理不可列印的字元,這可能允許遠端攻擊者通過包含終端模擬器轉義序列的 HTTP 請求修改視窗的標題,或者可能執行任意命令或覆蓋文件。

顯然,這並不是 nginx 中的安全漏洞,而是終端模擬器中的安全漏洞。

當然,也許cating 一個 log 文件到終端只是偶然發生的,但是greping 一個 logfile 是很常見的。less也許清理轉義序列,但誰知道哪些 shell 命令不會改變轉義序列……

我傾向於同意清漆的回應

一般來說,終端響應轉義的智慧經常受到質疑,但仍然沒有一個主要的終端仿真程序適合丟棄這些序列,這可能是在與不再使用的 1970 年代技術兼容的錯誤嘗試。

$$ .. $$ 從安全的角度來看,讓終端仿真程序停止做愚蠢的事情,從而一勞永逸地解決這個問題和其他安全問題,而不是責怪任何和所有寫入日誌文件的程序。

因此我的問題:

如何保護我的 xterm,從而無法再通過轉義序列執行命令或覆蓋文件?

X 的哪些終端仿真器可以抵禦這種攻擊?

VT100 終端(所有現代終端仿真器都在一定程度上進行了仿真)支持許多有問題的命令,但現代仿真器或發行版禁用了問題較多且用處不大的命令。這是潛在風險轉義序列的非詳盡列表(不包括僅以某種方式使顯示不可讀的轉義序列):

  • HD Moore 報告的rxvt 和 Eterm 中的任意日誌文件命令。這些確實是主要錯誤,幸運的是長期修復。

  • answerback 命令,也稱為返回終端狀態,由ENQ( Ctrl+E) 呼叫。這會將文本插入終端,就好像使用者輸入了它一樣。但是,此文本不受攻擊者的控制:它是終端自己的名稱,通常類似於xtermor screen。在我的系統(Debian 擠壓)上,xterm 預設返回空字元串(這由answerbackString資源控制)。

  • 發送設備屬性命令ESC [ c和朋友。終端響應ESC [ … c(其中只能包含數字和 ASCII 標點符號)。這是一種查詢某些終端功能的方法,這些功能大多已過時,但可能已被舊應用程序使用。同樣,終端的響應與使用者輸入無法區分,但它不受攻擊者的控制。控制序列可能看起來像一個功能鍵,但前提是使用者具有不尋常的配置(我遇到的正常設置都沒有一個有效的功能鍵轉義序列,它是終端響應的前綴)。

  • 各種設備控制功能(DCS 轉義,以 開頭ESC P)。

    • 我不知道DECUDK在典型的終端模擬器上通過(設置使用者定義的鍵)會造成什麼危害。
    • DECRQSS(請求狀態字元串)是終端以轉義序列響應的另一個命令,這次以\eP;開頭 這可能是有問題的,因為\eP它是一個有效的鍵(Alt+ Shift+ P)。
    • Xterm 還有兩個實驗性功能:ESC P + p …ESC P + q …, 獲取和設置 termcap 字元串。從描述來看,這至少可以用來修改功能鍵的效果。
  • 幾個狀態報告命令:(ESC [ … n設備狀態報告)。終端以轉義序列響應。這些轉義序列中的大多數不對應於功能鍵轉義序列。一個看起來有問題:報告ESC [ 6 n的形式是where和are digit sequences,這可能看起來像帶有一些修飾符。ESC [ *x* ; *y* R``*x*``*y*``F3

  • 視窗操作命令ESC [ … t

    • 其中一些允許調整 xterm 視窗的大小、圖示化等,這是破壞性的。
    • 其中一些會導致終端以轉義序列進行響應。這些轉義序列中的大多數看起來風險很低,但是有兩個危險的命令:答案分別ESC [ 2 0 t包括ESC [ 2 1 t終端視窗的圖示標籤和標題,攻擊者可以選擇這些。
    • 至少在 Debian 擠壓下,xterm 預設會忽略這些命令;它們可以通過設置allowWindowOps資源來啟用,也可以通過資源有選擇地啟用disallowedWindowOps。預設情況下,Ubuntu 10.04 下的 Gnome-terminal 甚至實現了標題應答。我沒有檢查其他終端或版本。
  • 用於設置終端標題或圖示名稱的命令。在 xterm 和大多數其他 X 終端下,它們是. 在 Screen 下,轉義序列是. 我發現對這些命令的擔憂被高估了。雖然它們確實允許一些惡作劇,但任何網頁都有同樣的問題。僅根據其標題而不是其類對視窗進行操作類似於打開一個名稱由不可信方提供給您的文件,或者不引用 shell 腳本中的變數擴展,或者拍一隻瘋狗的鼻子- 如果你被咬了,不要抱怨。ESC ] *digit* ; *title* ESC \``ESC k *title* ESC \


我發現 Varnish 的回答不誠實。感覺就像是在試圖推卸責任,或者處於安全納粹模式(任何安全問題,無論是否真實,都可以證明對某個功能進行黑名單)。

一般來說,終端響應轉義的智慧經常受到質疑,但仍然沒有一個主要的終端仿真程序適合丟棄這些序列,這可能是在與不再使用的 1970 年代技術兼容的錯誤嘗試。(…)

與其責備任何和所有寫入日誌文件的程序,從安全的角度來看,讓終端仿真程序停止做愚蠢的事情會更有效率,從而一次解決這個和其他安全問題,對所有人。

許多回复都是有用的功能:應用程序確實需要知道游標位置和視窗大小等資訊。設置視窗標題也非常有用。完全依賴ioctl這些呼叫是可能的,但是這將需要額外的程式碼和實用程序來進行這些ioctl呼叫並將它們轉換為通過文件描述符傳遞的 unix 樣式的文本。現在更改這些介面需要做很多工作,但收效甚微。

文本文件不應包含非列印字元,例如控製字元。日誌文件通常應該是文本文件。日誌文件不應包含控製字元。

如果您擔心文件可能包含轉義序列,請在編輯器中打開它,或者less不使用-ror-R選項查看它,或者通過cat -v.

引用自:https://unix.stackexchange.com/questions/15101