ターミナルでエスケープシーケンス攻撃を避けるには?

ターミナルでエスケープシーケンス攻撃を避けるには?

読むCVE-2009-4487の詳細(ログファイルのエスケープシーケンスのリスクに関する)少し驚きました。

見積もりCVE-2009-4487:

nginx 0.7.64は、印刷できない文字を削除せずにログファイルにデータを書き込みます。これにより、リモート攻撃者がターミナルエミュレータエスケープシーケンスを含むHTTPリクエストを介してウィンドウのタイトルを変更したり、任意のコマンドを実行したり、ファイルを上書きしたりする可能性があります。

明らかに、これは実際にnginxのセキュリティの脆弱性ではなく、端末エミュレータのセキュリティの脆弱性です。

もちろん、cat端末にログファイルを書き込むことは偶然に起こるかもしれませんが、grepログファイルは一般的です。lessたぶんエスケープシーケンスをクリーンアップすることは可能かもしれませんが、どのシェルコマンドがエスケープシーケンスを変更しないのか誰が知っていますか?

私は同意する方ですニスの反応:

一般に、ターミナルレスポンスエスケープの知恵はしばしば疑問を投げかけてきたが、依然として主要ターミナルエミュレーションプログラムはこれらのシーケンスを破棄するのに適しているとは考えられない。おそらく、廃止された1970年代の技術と互換性があるという誤った試みかもしれません。 [..]セキュリティの観点から、ログファイルに書き込むすべてのプログラムを非難するよりも、端末エミュレーションプログラムが愚かなことをやめるようにして、この問題やその他のセキュリティ問題を完全に解決する方が生産的です。そして皆のため。

だから私の質問は次のようになります

コマンドを実行したりエスケープシーケンスを介してファイルを上書きしたりしないようにxtermをどのように保護しますか?

どのX端末エミュレータがこの攻撃に抵抗しますか?

答え1

VT100ターミナル(すべての最新のターミナルエミュレータがある程度エミュレートします)は、問題のある多くのコマンドをサポートしますが、最新のエミュレータまたはディストリビューションでは、より多くの問題と便利なコマンドを無効にします。これは潜在的なリスクの非完全なリストです。エスケープシーケンス(単にディスプレイを読むことができないコンテンツを除く):

  • rxvtとEtermのランダムログファイルコマンドHDムーアレポート。これは幸いなことに、長い間修正された主なバグでした。
  • 戻り端末状態とも呼ばれる応答コマンドはENQCtrl+E)によって呼び出されます。これにより、ユーザーがテキストを入力したかのように端末にテキストが挿入されます。ただし、このテキストは攻撃者によって制御できません。通常、またはにxterm似た端末自体の名前ですscreen。私のシステム(Debian squeeze)では、xtermはデフォルトで空の文字列を返します(これはリソース制御されていますanswerbackString)。
  • デバイス属性コマンドESC [ cなどを送信します。ターミナル応答ESC [ … c数字とASCII句読点のみを含めることができます)これはほとんど使用されていませんが、以前のアプリケーションで利用可能な特定のターミナル機能を照会する方法です。同様に、端末の応答はユーザー入力と区別できませんが、攻撃者の制御下にはありません。制御シーケンスはファンクションキーのように見えますが、ユーザーが異常な設定を持っている場合にのみ可能です(私が遭遇した一般的な設定のうち、端末の応答の前に付く有効なファンクションキーエスケープシーケンスはありません)。
  • さまざまなデバイス制御機能(DCSエスケープ、で始まるESC P
    • DECUDK一般的な端末エミュレータで(カスタムキーを設定)すると、どのような害を及ぼすのかわかりません。
    • DECRQSS(要求ステータス文字列)は、端末が今回は\eP;で始まるエスケープシーケンスで応答する別のコマンドです。\ePキーが有効なため(++)問題が発生する可能性がありますAltShiftP
    • Xtermには2つの実験的機能もあります。ESC P + p …およびESC P + q …、termcap文字列を取得および設定する機能です。説明によれば、これは少なくともファンクションキーの効果を修正するために使用され得る。
  • 複数のステータスレポートコマンド:(ESC [ … nデバイスステータスレポート)。端末はエスケープシーケンスで応答します。ほとんどのエスケープシーケンスはファンクションキーエスケープシーケンスに対応しません。問題があるように見える1つは、レポートのESC [ 6 n合計が一連の数値である形式であるため、一部の修飾子があるように見えることです。ESC [ x ; y RxyF3
  • ウィンドウ操作コマンドESC [ … t
    • これらのいくつかはxtermウィンドウのサイズ変更、アイコン化などを可能にしますが、これは破壊的です。
    • これらのいくつかは、端末がエスケープシーケンスで応答するようにします。ほとんどのエスケープシーケンスは危険度が低いように見えますが、2つの危険なコマンド(それぞれターミナルウィンドウアイコンのラベルとタイトルを含む答え)はESC [ 2 0 t攻撃者ESC [ 2 1 tが選択する可能性があります。
    • 少なくともDebian squeezeでは、xtermはデフォルトでこれらのコマンドを無視します。allowWindowOpsリソースを設定したり、オプションでdisallowedWindowOpsリソースを介して有効にしたりできます。 Ubuntu 10.04のGnome端末はデフォルトでヘッダレスポンスも実装しています。他の端末やバージョンを確認していません。
  • 端末のタイトルやアイコン名を設定するコマンドです。 xtermと他のほとんどのX端末では、画面の下にエスケープシーケンスがあります。私はこれらの命令に対する懸念が誇張されたと思います。特定のレベルのいたずらを許可しますが、すべてのWebページに同じ問題があります。クラスの代わりにタイトルだけでウィンドウを操作することは、信頼できない当事者によって提供された名前でファイルを開く、シェルスクリプトで変数の拡張を参照しない、または狂気の犬を叩くのと似ています。文句を言わないでください。ESC ] digit ; title ESC \ESC k title ESC \

私はVarnishの反応が率直ではないと思います。非難を避けようとしたり、セキュリティナチモードになっているように感じます(実際には、すべてのセキュリティ問題は機能ブロックを正当化します)。

一般に、ターミナルレスポンスエスケープの知恵はしばしば疑問を投げかけてきたが、依然として主要ターミナルエミュレーションプログラムはこれらのシーケンスを破棄するのに適しているとは考えられない。おそらく、廃止された1970年代の技術と互換性があるという誤った試みかもしれません。 (...)
セキュリティの観点からは、ログファイルに書き込むすべてのプログラムを非難するよりも、端末エミュレーションプログラムが愚かなことをやめるようにして、この問題やその他のセキュリティ問題を完全に解決する方が生産的です。すべて。

ほとんどの答えは便利な機能についてです。つまり、アプリケーションは実際にカーソルの位置やウィンドウのサイズなどを知る必要があります。ウィンドウのタイトルを設定することも非常に便利です。これらの呼び出しに完全に依存することは可能ですioctlが、これらの呼び出しを実行してioctlファイル記述子を渡すUnixスタイルのテキストに変換するには、追加のコードとユーティリティが必要です。今、これらのインターフェイスを変更することは、ほとんど表示できない多くの作業になります。

テキストファイルには、制御文字などの印刷できない文字を含めないでください。ログファイルは通常テキストファイルでなければなりません。ログファイルには制御文字を含めないでください。

ファイルにエスケープシーケンスが含まれる可能性があるという懸念がある場合は、エディタでファイルを開き、オプションなしでまたはを介してless確認-r-Rてくださいcat -v

答え2

それほど簡単ではありません。多くの人がxtermプロンプトなどの一部としてタイトルを設定するコードを持っており、それには理由があります(shutdown間違った端末ウィンドウで間違ったシステムを使用した人は誰でもわかります!)。したがって、これを正しく修正するには、セキュリティコンテキストを導入する必要があります。これは、シェルと端末エミュレータ、および人々のドットファイルとの間の相互作用を深刻に複雑にします。または、安価なソリューションを選択して端末に表示できるものをすべて整理することもできます。これにより、制御文字を目立たせるためにエスケープ処理文字が大幅に減少します(ログファイルのように)。誰かがシェルコードを注入しようとしています。)

(余談で、ポニーコード同じ問題のより深刻な例にもかかわらず、公式の標準になりました。時々、セキュリティは人々が制御できない安全でない設計を減らすことにつながります。 )

関連情報