セキュリティ管理者は依然としてパッチの追跡に追われています。シェルショック、先週Web上を襲ったBashの脆弱性。
Bash は数百万台のコンピュータで使用されているシステム ソフトウェアであるため、この脆弱性により、攻撃者がそれを実行しているマシン上で任意のコマンドを実行できる可能性が生じます。
関連項目:
最大のターゲットは Web サーバーです。今のところ、平均的なユーザーはそれほど恐れる必要はありません。しかし、セキュリティ研究者が Bash コードベースの側面を調査するにつれて、より危険な脆弱性が出現し始めています。
GoogleのMichal Zalewski氏、別名「」lカムトゥフ」では、ここ数日だけで Bash パーサーにさらに 2 つの一般的な脆弱性とエクスポージャー (CVE) が発見されました。
オリジナルの RCE に相当する、bash で 6 番目の最も深刻な問題が見つかりました。最初のパッチだけを使用している場合は、すぐに問題が発生するでしょう。— lcamtuf (@lcamtuf)2014 年 9 月 28 日
これにより、Shellshock に関連付けることができる Bash の CVE の合計数は 6 になります。 6 番目の脆弱性は、ザレウスキー日曜日に報告されたが、元の欠陥と同じくらいひどいものだ。
「2番目のものは本質的に元の欠陥と同等であり、最初のバグの修正を導入したシステム上でもリモートでのコード実行を簡単に許可してしまう」とZalewski氏は語った。iTニュースオーストラリアで。
Zalewski 氏は、この脆弱性に関する技術的な詳細を明らかにしていません。彼は、管理者と企業に最初に更新する機会を与えたいと考えています。しかし彼はすべてのサーバー管理者に強く勧めます上級ユーザーは、非公式パッチRed Hat 社員の Florian Weimer より。
Weimer のパッチはいくつかの Linux ディストリビューションに同梱されているため、上級ユーザーは最新のパッチが入手可能かどうか、または手動でインストールする必要があるかどうかを確認する必要があります。
最初の Shellshock の脆弱性と、ここ数日で発生した脆弱性により、当然のことながら、セキュリティ研究者は Bash パーサー自体のセキュリティに疑問を抱くようになりました。
Bash コードベースの歴史は 1987 年に遡ります。 Shellshock バグ自体は 1992 年に導入された可能性があります。そのため、この規模のバグとしては、この期間に未公開となったものとしては最古ではないにしても、最も古いものの 1 つとなります。
セキュリティの正誤表ロバート・グラハムについて書きましたBash コードベースの状態彼は Errata Security ブログで、その慣行の多くがいかに時代遅れであるかを指摘しています。
#shellshock への返答として、Richard Stallman 氏は、このバグは単なる「瞬間」であると述べました。それはそうではありません、それは「飛行船」です - 来るべき大きな出来事を警告するレーダー上の巨大な厄介なスポットです。さらに 3 つの関連バグが発見されており、今後さらに多くのバグが発見される可能性があります。原因はプログラマーがミスをしたことではなく、コードに体系的な欠陥があることです。コードは 2014 年ではなく 1984 年の標準に従って書かれており、時代遅れです。
問題の一部 -- 私たちが見たものハートブリードも-- コードが機能しているように見える場合、「目が多ければすべてのバグが浅くなる」という長年の理論は消える傾向にあるということです。それは、多くの人の目は実際にはコードを見ているわけではないからです。オープンソース エコシステムの最も重要な部分の一部では、ユーザーの数がメンテナーや監査人の数と一致することはほとんどありません。
Heartbleed 脆弱性の希望の兆しは、OpenSSL プロジェクトがいかに悲惨なほど資金不足であるかを明らかにしたことでした。のLinux Foundationなど将来そのような問題が起こらないようにするため、コアインフラストラクチャイニシアチブを設立します。
GNU Bash の広範な監査は、このイニシアチブの次の目標に自然に適合すると思われます。グラハム氏が言うように、解決策の一部は、これらの中核プロジェクトの技術的負債を一掃し、最新の基準に引き上げることです。
それまでは、システム管理者、大手企業、オペレーティング システム ベンダーやディストリビューションは、穴を見つけ次第、その穴をふさぐ努力を続けるでしょう。
それまでの間、Shellshock の「概念実証」コードのリポジトリGitHub 上にあります。これにより、他のプロジェクトのソフトウェア保守者やシステム管理者が何をする必要があるかがわかり、さらなる不正行為を防ぐことができます。
ボーナス: シェルショックとは何ですか?