MacはBash shellshockのバグに対して脆弱ですか?


58

Red Hatは最近、Bashシェルのセキュリティ関連の主要なバグ発表しました。一部の人はそれを「shellshock」バグと呼んでいます。OS XはUnixで構築されているため、このバグを悪用する攻撃に対して脆弱ですか?

エンドユーザーとして、即時の修正について心配する必要がありますか?それとも、Appleからの公式のソフトウェアアップデートを待つ方が良いでしょうか?



OSXに影響するアクションを確認するには、security.stackexchange.com
questions / 68123 /…

質問を更新して、だまされにくくなり、素人向けのアドバイスを求めるようになりました。
ヘアボート

1
Appleは今修正をリリースしました:support.apple.com/kb/DL1769を
AT

回答:


46

はい、技術的に脆弱です。パニック状態に陥ったクライアントに数時間のパニック作業をさせてパニックに陥ったり、料金を請求したりする場合は、ぜひ行ってください!

ただし、現実には、リモート接続またはサーバー側スクリプトを実行するWebサーバーからのSSHアクセスを許可しない限り、リスクはありません。あなたが知らない人があなたのマシンにリモートでアクセスでき、Bashコマンドを実行できる方法でアクセスできる場合にのみ、本当に脆弱になります。

あなたのデスクトップMacを意味する-それは実際にはいかなる種類のサーバーアプリケーションも実行しない-深刻なリスクにはさらされていない。ここでは「謙虚なパイ」という有名なものを食べたいと思っていますが、そこにいるMacユーザーの大多数が一日の終わりに危険にさらされるとは思いません。

そのため、この問題は、SSH共有を有効にしないデスクトップユーザーではなく、主に世界に公開されているMac OS XおよびUnix / Linuxサーバーのシステム管理者の関心事です。

Macマルウェアまたはウイルスがこのリスクを悪用するために作成されるというリスクがあるかもしれませんが、私はそれを疑います。

編集:そして、この問題がどういうものかを詳しく説明するために-私の謙虚な意見では-実際にはほとんどの平均的なユーザーにとっては問題ではない、はいbash、Mac OS X 10.9.5 から次のコマンドを実行できます:

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

そして私はこれを見ます:

vulnerable
hello

何だと思う?これを合理的に考えない限り、それは恐ろしいことです。ターミナルを開くために、すでにMacにログインしている必要がありました。また、上記のSSHについて述べたことを否定するために、SSHが有効になっている場合でもこのテストを実行できるようになるには、ログインする必要があります。そして、SSH経由でアクセスできるとしましょう。このコマンドは、次のような通常のユーザー権限を超えて何もすることを許可しません。

env x='() { :;}; echo vulnerable' bash -c 'cat /etc/ssh_host_rsa_key'

つまり、このハッキングの悪用に対して本当に脆弱な場合は、システムのコアセキュリティを非常に危険にさらす必要があるのでbash、欠陥があるという事実は実際にはごくわずかな問題です。

これは、振る舞いが予想される規範の範囲を超えているため、意図しないアクセスを許可する可能があるため、全体的なコントロールと権利の問題からの懸念です。しかし、私の謙虚な意見では、OpenSSLや庭のバラエティに匹敵するリスクではありません。「画面にテープで貼り付けたメモにパスワードを残しておく」リスクです。

結局のところ、私はまだ標準手順として実行しているすべてのLinux / Unixサーバーにパッチを当てています。そして、修正プログラムが公開されたら、私が管理しているMacに喜んでパッチを適用します。しかし、実際の日常的な使用では、昇格したユーザー特権を許可しない欠陥がどのように追加されるのか理解していないため、これについて心配する必要はありません。

更新: Appleからの公式の言葉がここに投稿されました。強調鉱山:

Appleの広報担当者は、「OS Xユーザーの大多数は最近報告されたbashの脆弱性のリスクにさらされていません」と語っています。脆弱なシステムの制御。OS Xでは、システムはデフォルトで安全であり、ユーザーが高度なUNIXサービスを設定しない限り、bashのリモートエクスプロイトにさらされません。 私たちは、上級のUNIXユーザー向けにソフトウェアアップデートを迅速に提供するよう取り組んでいます。」

翻訳:これがサーバーの問題であり、クライアントの問題ではないことについて上で言ったことは何ですか?まさに。

最終的なUDPATE:ソースからのコンパイルに苦労している人のために、9月29日の時点で、AppleはMac OS X 10.9.5、10.8.5および10.7.5のパッチを公式にリリースしました。

まだ別の最終更新:そして、Appleは本日、このbash更新含む組み合わせセキュリティ更新をリリースしました!

注:Security Update 2014-005には、OS X bash Update 1.0のセキュリティコンテンツが含まれています


7
「またはサーバー側のスクリプティングを実行するWebサーバー」-または、開いているポートでリッスンしているアプリケーションを実行して、シェルコマンドを実行するRPC呼び出しを許可します。RPCを実行する標準的なアプリケーションが多数あるため、これはいくつもの可能性があります。この答えはとてもナイーブだと思います。クライアント/サーバー型の処理を行うアプリケーションを実行しているときに、「Webサーバーを実行する」のは不注意です。
イアンC.

3
@IanC。すぐに使えるOS Xが本当に脆弱になる例を提供できますか?たとえば、WebExやGotoMeetingのようなものがBashの機能に近づきますか?ポイントは、私が本当に物事を公開する単純なOS Xのインストールシナリオを考えることができないということです。あなたはできる?
JakeGould 14

8
ゲストアカウントはsshで使用できません。実際、IIRCのsshで利用可能にすることすらできません。事実、OS Xユーザーの大多数にとって、bashの脆弱性はまったく問題ではありません。それが問題である私たちにとっては、テスト済みの修正が利用可能になり次第、bashを再コンパイルする必要がありますが、それは今ではありません。
lbutlr 14

3
@IanC。さて、公正な例。しかし、あなたはまだポイントを失っています:あなたが提供しているすべての例でどのようにそのような脆弱性を悪用することができますか?いずれの場合も、ユーザーはシステムにアクセスしてから何にアクセスする必要がありますか?私はこれについて軽率ではありませんが、実際にリスクがどうなるかを把握していませんか?たとえば、誰かがPlex APIを駆け抜けて、通常のユーザー権限とアクセス権限以外のことをbashで正確に行う必要がありますか?
JakeGould

6
@danielAzuelos 「ゲストアカウントが開いている限り、誰もが脆弱です:[!]ゲストアカウントはには関係ありませんbash。それで、恐怖は正確に何に基づいていますか?また、たとえゲストアカウントが開いていてbash、どういうわけか使用可能であっても、それではどうでしょうか。このエクスプロイトを使用した推測では、昇格された特権やそれに近いものはないと思われます。真剣に、私は自分のスタンスから後退したいと思っていますが、これはあまりないことに基づいたパニックのように見えますが、OpenSSLは本当の問題でした。
JakeGould 14

37

はい!

これをシェルに入力します

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

それが言うならvulnerable、あなたは脆弱です。

それが言うなら

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello

その後、あなたは良いです。

編集:修正へのリンク


4
ありがとう。質問を更新しました-脆弱性が見つかった場合、Macユーザーはどのように修正できますか?
ヘアボート

3
@abbyhairboat私の答えを投稿しました。外の世界にさらされているサーバーを実行していない限り、実際的なリスクはありません。これを心配する必要があるのはサーバー管理者です。
JakeGould 14

1
アビー:関連する回答:apple.stackexchange.com/a/146851/22003をご覧ください。
ダン14

2
これを試してみてくださいenv X="() { :;} ; echo busted" /bin/sh -c "echo completed"-私のシステムにパッチを適用した後でも、これはコマンドラインで「バスト」を吐き出します。ああ。
トレーンフランクス

1
@Mark nope、zshは安全です。「bash -c」を「zsh -c」に置き換えてテストする必要があります。
ismail 14

3

エンドユーザーとして、次のことを確認します。

  • ゲストアカウントはオフです:

    [システム環境設定]> [ユーザーとグループ]> [ゲストユーザー]
    
  • あなたのsshアクセスはオフです:

    システム環境設定>共有>リモートログイン
    

デフォルトでは、これらはMavericksではオフになっています。

エンドユーザーとして、この脆弱性を修正するアップルの公式セキュリティアップデートを待つ方が安全bashです。


1
これらは無関係です。これらのどちらも、その性質上、システム上でコマンドを実行するためのアクセスをユーザーに許可するため、それらを有効にした場合は、ユーザーにコマンドの実行を許可することが意図されます。Shellshockバグは、実行する予定のないユーザーがコマンドを実行できるようにするための手段です。たとえば、実行するWebサーバーのユーザーです。したがって、答えは「Web共有を無効にする」と言う必要があります(ただし、これは確認することの1つにすぎません)
ジョシュ14

Appleがこれらの設定をオフにするようアドバイスしなかったのはいらいらします。誰がそれらを有効にしますか?私は...するだろう。私は1986年からMacユーザーであり、フルタイムのWebアプリケーション開発者(だからsshが私の人生です)、そして父親(子供のゲストアカウントはそれほど悪い考えではありません)です。これらの点でAppleラップトップを使用している私のような人をたくさん知っています。私たちを失いたいですか?この脆弱性を開いたままにしておくのは良い方法です。
ミノプレット14

2

Appleがbashにパッチを当てるセキュリティアップデートを発行するまで、すべてのMac OS Xマシンは「Shellshock」に対して技術的に脆弱です。

あなたの質問は次のとおりです。リモートでハッキングできますか?

bashぼんやりと使用するソフトウェアが非常に多いため、その質問に答えることは非常に困難です。心配な場合はSystem Preferences、リモートエクスプロイトを防ぐためにいくつかの変更をお勧めします。

  • 共有設定ですべての共有サービスを無効にします。
  • セキュリティとプライバシーの下でファイアウォールを有効にします。

特に心配な場合は、Firewallオプションボタンを押して:

  • チェックを外しますAutomatically allow signed software to receive incoming connections
  • 確認してくださいBlock all incoming connections

DHCP、Bonjourなどを使用したレベル攻撃に対して脆弱である可能性はかなりありますが、別のサービスが必要な場合は、悪用されないことを期待しながら実行することができます。また、ファイアウォールをさらにオープンにしておく必要があります。マシンが別のファイアウォールの背後にある場合は、おそらく問題ありません。

また、「Shellshock」によって有効にされるローカル権限昇格攻撃はありますか?はい、ほぼ確実です。Mac OS Xには同様の攻撃が十分にあるため、心配する必要はありません。Appleは、ローカル権限エスカレーションのバグをすぐに修正しません。また、AppleはApple Script対応サービスを使用して頻繁にそれらを作成します。すべてのMac OS Xマシンが常にローカル攻撃に対して脆弱であると仮定してください。DEFCONなどのハッカー会議に出席する必要がある場合は、その目的のためにLinuxボックスを購入してください。

更新:のための指示があり、独自の固定のbashを再コンパイルし、そうカバーし、別の質問すぎては。私はこれを自分で行いますが、サーバーを実行せず、Appleのファイアウォールをオンのままにしておくと、私見はやり過ぎです。

更新:あなたは、端末の使用に慣れている場合、呼ばれるプログラムがあるexecsnoop述べ、ここでそれはあなたがbashのは、通常ご使用のサーバプロセスによって呼び出されているかどうかをテストできますが。サーバープロセスは異常な状況でのみbashを呼び出す可能性があるため、魔法の弾丸ではありませんが、良いアイデアを提供します。

最後に、Appleはセキュリティの脆弱性にパッチを適用することについてはあまり得意ではありませんが、PRには長けているため、比較的迅速にパッチが適用されます。したがって、「私は熊よりも速く走る必要はありません。インターネット上の膨大な数の簡単に悪用可能なサーバーよりも速く走る必要があるだけだ」と考えるのは理にかなっています。:)


2
MacがBashを使用しないため、DHCPを使用した攻撃に対して脆弱である可能性はありません。

1
どうやってわかったの?最初のアドバイザリは脆弱なDHCPクライアントでした。また、多くの記事は、Mac OS Xおよび/またはiOS DHCPクライアントが脆弱である可能性があると推測しています。特に断りのない限り、すべてのサーバーは脆弱であると想定する必要があります。
ジェフバード14

1
いいえ、そうではありません。それは絶対的なFUDです。OS Xのdhcp実装のオープンソースコードと、システムコールを測定して検証することができます。

3
@ JeffBurdges、OS Xは10.3以降、DHCPでシェルexecを使用しておらず、その前はbashがシステムにインストールされていませんでした。OS X上のDHCPは、Shellshockの問題ではありません。(心配することについて1つ少ないこと。:))
Trane Francks 14

1
→ジェフ:検討してください:strings /usr/libexec/bootpd | egrep '/bin|bash'nm -a /usr/libexec/bootpd | egrep 'fork|exec'。MacOS Xの異なるバージョンにこれらのコマンドの出力を読むことによって、あなたが起因して、あなたのリスク分析を見直す可能性があるdhcpdのMacOS X上...しかし、これだけで1 :(。
ダン

2

この脆弱性について聞いてすぐに、このツールを作成しました。ツールが脆弱であると判断した場合にシェルにパッチを適用するための記事へのリンクを提供します。

Mac OS X 10.6以降が必要です。


3
たぶんそれは私だけかもしれません...しかし、エクスプロイトをテストするためにランダムな人のコードを実行するというアイデアは、文字列を簡単に貼り付けることができる場合は本当に悪いアイデアのようです(明らかにテストを実行するだけです)ターミナルウィンドウ。
ジョー14


ただし、場合によっては、複数のシステムをテストするための使いやすさを提供できます。
トーマスジョーンズ14

私はこのことの利点を見ていません。ターミナルウィンドウに単純なコマンドラインを貼り付けることにより、脆弱性の確認がはるかに簡単になります。
アルバートゴッドフリンド

しかし、特に私の場合、複数のマシンをテストするときは、それが私がしていることなので、フラッシュドライブを入れてShellshock Check.appを開くのは、Safariを開いてbashコマンドを確認してからターミナルを開いて貼り付けるよりもはるかに簡単ですコマンドを押してからEnterを押します。フラッシュドライブを接続して、1つのアプリケーションを開く方がはるかに高速です。
トーマスジョーンズ14
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.