端末でエスケープシーケンス攻撃を回避する方法


29

読み込みCVE-2009-4487の詳細を(ログファイル内のエスケープシーケンスの危険性についてである)私は少し驚いています。

CVE-2009-4487を引用するには:

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

明らかに、これは実際にはnginxのセキュリティホールではなく、ターミナルエミュレータにあります。

確かに、おそらくcat端末へのログファイルgrepの書き込みは偶然だけで起こりますが、ログファイルの書き込みは非常に一般的です。lessおそらくエスケープシーケンスをサニタイズしますが、どのシェルコマンドがエスケープシーケンスを変更しないかを知っている人は...

私はワニスの反応に同意する傾向があります:

一般に、端末応答エスケープの知恵は定期的に疑問視されていますが、主要な端末エミュレーションプログラムはいずれも、おそらく使用されていない1970年代の技術との互換性の見当違いの試みで、これらのシーケンスを破棄するのにふさわしいものではありませんでした。[..]ログファイルを書き込むすべてのプログラムを非難するのではなく、セキュリティの観点から、端末エミュレーションプログラムに愚かなことをやめさせ、この問題やその他のセキュリティ問題を一度修正する方がはるかに生産的です。そしてすべてのために。

したがって、私の質問:

コマンドを実行したり、エスケープシーケンスを介してファイルを上書きしたりすることができなくなるように、xtermをセキュリティで保護するにはどうすればよいですか?

Xのどのターミナルエミュレーターがこの攻撃から保護されていますか?


4
多くのエスケープシーケンスは正当なことを行います(名前変更/サイズ変更/ etc xterm)。しかし、コマンド実行したりファイルを上書きしたりするエスケープシーケンスは誰でも識別できますか?
クルボ


Security SEでのpaste-control-chars-from-web-browser攻撃に関する同様の問題:このようなクリップボードの悪用から自分を守るにはどうすればよいですか?tl; dr:2013/2015以降にリリースされたxterm / vteベースの端末を使用している場合、デフォルトで制御文字が除外されるため、これに対して保護されます。
maxschlepzig

回答:


27

VT100端末(最新のすべての端末エミュレーターがある程度エミュレートする)は、多くの問題のあるコマンドをサポートしていましたが、最新のエミュレーターまたはディストリビューションは、より問題が多く有用性の低いコマンドを無効にします。危険な可能性のあるエスケープシーケンスの完全ではないリストを以下に示します(何らかの方法で表示を単に読みにくくするものは含まれません)。

  • HD Mooreによって報告されたrxvtおよびEtermの任意のログファイルコマンド。これらは本当に大きなバグであり、幸い長い間修正されています。
  • ENQCtrl+E)によって呼び出されるアンサーバックコマンド(リターンターミナルステータスとも呼ばれる)。これにより、ユーザーが入力したかのようにテキストが端末に挿入されます。ただし、このテキストは攻撃者の制御下にありません。端末の名前であり、通常はまたはxtermなどscreenです。私のシステム(Debian squeeze)では、xtermはデフォルトで空の文字列を返します(これはanswerbackStringリソースによって制御されます)。
  • デバイス属性の送信コマンド、ESC [ cおよびフレンド。端末は応答しますESC [ … c数字とASCII句読点のみを含むことができます)。これは、一部の端末機能をクエリする方法であり、ほとんどが時代遅れですが、おそらく古いアプリケーションで使用されています。繰り返しますが、端末の応答はユーザーの入力と区別できませんが、攻撃者の制御下にはありません。コントロールシーケンスはファンクションキーのように見えますが、ユーザーが通常とは異なる構成になっている場合に限ります(私が遭遇した通常の設定には、ターミナル応答のプレフィックスである有効なファンクションキーエスケープシーケンスがありません)。
  • さまざまなデバイス制御機能(DCSエスケープ、先頭はESC P)。
    • DECUDK一般的なターミナルエミュレータでどのような害が発生するか(ユーザー定義キーを設定する)がわかりません。
    • DECRQSS(Request Status String)は、端末がエスケープシーケンスで応答するもう1つのコマンドで、今回は\eP;で始まります。\eP有効なキー(Alt+ Shift+ P)であるため、これは問題になる可能性があります。
    • 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 tESC [ 2 1 t含み、攻撃者はこれらを選択できます。
    • 少なくともDebian squeezeでは、xtermはデフォルトでこれらのコマンドを無視します。allowWindowOpsリソースを設定するか、リソースを選択して有効にすることができますdisallowedWindowOps。Ubuntu 10.04のGnome-terminalは、デフォルトでタイトルのアンサーバックさえ実装しています。他の端末やバージョンを確認していません。
  • 端末のタイトルまたはアイコン名を設定するコマンド。xtermおよび他のほとんどのX端末では、これらはです。画面では、エスケープシーケンスはです。これらのコマンドに対する懸念は過大評価されています。多少のいたずらは許可されますが、どのWebページにも同じ問題があります。クラスではなく、タイトルのみに基づいてウィンドウを操作することは、信頼できない関係者から名前が付けられたファイルを開くこと、またはシェルスクリプトで変数展開を引用しないこと、または鼻に狂犬をpaでることに似ています—噛まれても文句を言わないでください。ESC ] digit ; title ESC \ESC k title ESC \

ワニスの反応は不誠実です。非難を変えようとしているように感じるか、セキュリティナチモード(本物であるかどうかにかかわらず、セキュリティ上の懸念は機能のブラックボール化を正当化する)です。

一般に、端末応答エスケープの知恵は定期的に疑問視されていますが、主要な端末エミュレーションプログラムはいずれも、おそらく使用されていない1970年代の技術との互換性の見当違いの試みで、これらのシーケンスを破棄するのにふさわしいものではありませんでした。(…)
ログファイルを書き込むすべてのプログラムを非難する代わりに、セキュリティの観点から、端末エミュレーションプログラムに愚かなことをやめさせ、この問題やその他のセキュリティの問題を一度修正すると、すべてのために。

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

テキストファイルには、制御文字などの非印刷文字が含まれることは想定されていません。通常、ログファイルはテキストファイルであることが期待されます。ログファイルに制御文字を含めることはできません。

ファイルにエスケープシーケンスが含まれているのではないかと心配する場合は、エディターで開くかless-rまたは-Rオプションなしで表示するか、で表示しますcat -v


2
「これらをioctl呼び出しに完全に依存することは可能でしょう」しかし、アプリと端末の間に本当にシリアルケーブルがある場合はどうでしょうか。
mmv-ru 14

5

それほど単純ではありません。多くの人がxterm、プロンプトなどの一部としてタイトルを設定するコードを持っています。非常に正当な理由により(shutdown間違った端末ウィンドウから間違ったマシンを使用している人なら誰でも教えてくれるので!)。したがって、適切に修正するには、セキュリティコンテキストを導入し、シェルとターミナルエミュレーター、およびおそらく人々のドットファイルとの相互作用を大幅に複雑にします。または、端末に表示される可能性のあるものをすべてサニタイズする低賃料ソリューションを使用できます。これにより、制御文字のエスケープが大幅に減ります。おそらく、目立つようにするためだけに行う必要があります(ログファイルでは、シェルコードを挿入しようとしている人を示すことができるため)。

(余談ですが、punycodeは同じ種類の問題のより深刻なインスタンスです。それでも公式の標準になっています。セキュリティは、制御不能な安全でない設計を緩和することになります。)


1
x用語では、エスケープシーケンスを介してタイトルを変更できますが、ファイルを上書きしたり、エスケープシーケンスを介して任意のコマンド実行し たりすることはできません。それは一歩前進でしょうか?
maxschlepzig

1
それを行う直接的な方法は何年もの間無効にされてきました。間接的な方法は依然として残っていますが、少なくとも追加の手順が必要です(つまり、ユーザーに再プログラムされたファンクションキーを呼び出させるためのソーシャルエンジニアリング攻撃)。しかし、おそらくユーザーを混乱させて間違った場所で何かをさせる攻撃の一部として、タイトルバーはCVEで明確に呼び出されました。現代の最大の懸念は、シェルに任意のテキストを送信するようにプログラムできるものと、ターミナルエミュレーターを使用して何ができるかを攻撃者に見つけさせるアンサーバックです
...-geekosaur

...しかしそれは、ペースソフトウェアは最小限に移植されているとそれだけで作られた適切な変更を取得するために歯を引っ張っよりもはるかに多くかかるところワニスは、ほぼ確実に、まだ大規模な商業環境で使用されています。
ギーコサウルス
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.