最近、Twitterを介してCVE-2014-6271について聞いたことがあります。
Webサーバーとして機能していない通常のOS Xデスクトップは、この脆弱性を悪用する攻撃を受けるリスクがありますか?
「リスク」を定義します。
この攻撃の中心は、Bashスクリプト関数のように見えるが、プログラムの呼び出しで終了する環境変数を作成し、Bashを実行させることです。 Bashは環境変数を確認して解析し、関数の最後を超えて解析を続け、プログラムを実行します。
攻撃者が制御する少なくとも1つの環境変数を使用してBashの実行をトリガーする方法はすべて機能します。 WebサーバーのCGI攻撃が現在注目を集めていますが、SSH経由でログインしているユーザーがそれを行う可能性があります(ただし、ログインの失敗はできません)。一部のFTPサーバーが(たとえば、アップロード後のスクリプトを実行して)トリガーする可能性があります。 PackageMakerベースのインストーラーがトリガーする可能性がありますが、悪意のあるインストーラーを実行している場合は、これよりも大きな問題が発生します。おそらく他にも多くの方法があります。
平均的なデスクトップユーザーアクティビティを実行している平均的なデスクトップユーザーが、このバグをトリガーするために使用できる攻撃ベクトルを開いている可能性は低いですが、Bashは予想外の十分な場所に現れ、確実に言うことはできません。
あなたがする必要があるのは、どのプロセスがbashを実行しているかを決定することです。 Linuxシステムでは、DHCPリクエストの処理方法に脆弱性が存在する可能性があります。
Execsnoopを使用してbashが実行されているものを特定し、wifiネットワークへの接続や外部ヘルパー(iTunesなど)を必要とするWebページの閲覧などの通常の操作を試すことができます。 bashが実行されているかどうかを確認し、他のdtraceツールを使用して、環境を検査できるかどうかを確認します。
ただし、正直に言うと、修正が利用可能になったらすぐにマシンを更新する方が理にかなっています。 OS Xについてはまだ見たことがありません(しかし、数時間調べていません)が、それが発生したときは目を離さずに更新します。
いいえ、私が知る限り、通常 OS Xデスクトップはそうではありません。
OS X DHCPは脆弱ではありません。最近では、シェルを呼び出すことすらありません。bootpdを使用したバージョンではdidがシェルを呼び出すため、シェルはBashではありませんでした。一部のサイトでは、実行されたのはtcshであると示唆されていましたが、実際には/bin/sh
、これは(メモリから)古いバージョンのOS XではBourne ShellのBSDの実装でしたnot Bash。
Apacheを実行していて、BashでVanilla CGI(OS Xデスクトップではnot通常)を使用している場合、脆弱です。
同様に、OS Xマシンを使用して、ForceCommandを使用して制限付きのSSHサーバーを実行している場合は、脆弱です。繰り返しますが、これはnot OS Xデスクトップの通常の動作です。
Appleのさまざまなサーバープロセスについては、すべてを確認したわけではありませんが、メモリからTwistedを使用し、Apacheを使用してリバースプロキシする傾向があります。これにはCGIは含まれず、脆弱性もありません。