☰

Bashシェル機能とシェルショックの理解

tag-icon • tag-icon bash shell
Bashシェル機能とシェルショックの理解

私はそれについて尋ねた。質問Bashでシェル関数を定義して使用します。この質問では、どの関数定義方式がシェルショックを引き起こすかを具体的に尋ねたいと思います。私はいくつかのテストを行い、他の人に確認したいと思いました。私はテストのためにbash v4.2を実行しています。

私が知る限り、サブシェルにシェル関数定義を提供する方法は2つあります。

  • シェル変数を介して環境にエクスポート +
  • シェル機能による定義+環境へのエクスポート

最初の方法：

$ foo='() { echo "hello world"; }'
$ export foo
$ env | grep foo
foo = () { echo "hello world"; }

2番目の方法は次のとおりです。

$ foo() { echo "hello world"; }
$ export -f foo
$ env | sed -n '/foo/{N;p}'
foo = () { echo "hello world"
}

どちらの方法でも、環境はシェル関数を名前と値のペアとして受け取ります[ foo = () { echo "hello world"; } ]。今私が興味を持っているのはCVE-2014-6271。関数定義の最後に、bashが後続のコマンドを解析する方法のためにこれが起こることを知っていますが、上記の両方がこの問題を引き起こしているかどうかを尋ねたいと思います。

最初のケースでは、次のように定義できます。

$ foo='() { echo "hello"; }; echo "world";'
$ export foo
$ env | grep foo
foo = () { echo "hello"; }; echo "world";
$ bash -c foo
world // <-- shellshock bug
hello

ただし、2番目のケースでは同じことはできません。

// won't put trailing echo in definition
$ foo() { echo "hello"; }; echo "world"; 

// bad syntax
$ foo() '{ echo "hello"; }; echo "world";'

だから私の質問は、CVE-2014-6271が環境変数の関数定義の後に後続のコマンドの解析エラーのために発生しますが、そのような関数定義をexport -f <func>環境にORで関連付けることができることです。これがこの文書の要点です。後続のコマンドを入力するとシェルショックが発生することがありますか？

ベストアンサー1

質問：

...これらの関数定義をORを介して環境に配置できますかexport -f <func>？最初のケースは、シェルショックを引き起こす末尾のコマンドを入力する唯一の方法ですか？

A：最初のシナリオはシェルショックを引き起こす唯一の方法です。

脆弱性は環境解析によって引き起こされます。変わりやすい、エクスポートされた関数ではありません。

それを見てください（これシマンテックの写真はこちら。読むバグレポーターの説明。

含まれる環境変数の処理は(){...}関数定義として扱われます。そして処置: これらの変数を後続する場合は、;cmdコマンドが実行されます。cmd重要な問題は、関数の解析が関数の解釈を制限しないことです。一つ実行可能トークンを生成し、エクスポートされたvarに含まれている残りの行を実行可能コマンドとして処理します。

変数のエクスポートにのみ実行を制限する部分は次のとおりです。最初のパッチの試み。すぐに明らかになったので、これだけでは十分ではありませんでした。いくつかの追加エラー。

したがって、いいえ、関数定義を正しくエクスポートできず、再読み込みに失敗して（完全にシェルの制御下にある）エラーが発生するわけではありません。しかし、結果は一部攻撃者が注入した可能性のある変数の値を解析する際に問題が発生しました。

それにもかかわらず、バグを最初に報告した人はそのサイトの一般ユーザーでした。おそらくその人は問題を見に来たようです。

おすすめ記事