Stack Clash: CVE-2017-1000364, CVE-2017-1000365, CVE-2017-1000366

Security Vulnerability
Response Information

Stack Clash: CVE-2017-1000364, CVE-2017-1000365, CVE-2017-1000366

Stack Clash: CVE-2017-1000364, CVE-2017-1000365, CVE-2017-1000366

Wind River® is committed to delivering secure, reliable products that keep your devices protected. As part of this commitment, our Security Response Team is constantly monitoring and assessing thousands of notifications from CERT-accepted authorities and agencies, Linux security communities such as oss-security, and our customers. Wind River prioritizes these notifications, responds, and proactively contacts customers for timely alerts, enabling them to secure their devices.

Affected Products

The latest reported Stack Clash vulnerability, tracked under the CVE entries CVE-2017-1000364, CVE-2017-1000365, and CVE-2017-1000366, has been addressed by the Security Response Team.

We have determined that some Wind River products are affected, including the following:

  • Wind River Linux
  • Wind River Intelligent Device Platform
  • Wind River Pulsar Linux

Customers not on the latest version of software may be vulnerable and should contact Wind River Customer Support or their local Wind River representative for information regarding a fix for their version.

This issue has been rated as high. Further information can be found on https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash.

Note: Due to the significant difference in the privilege model, VxWorks is not impacted by this vulnerability. Specifically, in VxWorks all real-time processes (RTPs) execute in user mode (least privileged processor execution mode), and the concepts of SUID (set-user-ID) and SGID (set-group-ID) processes do not exist. VxWorks is highly configurable, and if you are concerned about the potential of a “stack clash” scenario, VxWorks provides configuration parameters to specify the size of various stack guard regions, including the overflow and underflow regions for an RTP task’s execution stack, the overflow region for an RTP task’s exception stack, and the overflow and underflow regions for a kernel task’s execution stack. Contact Customer Support or your Wind River representative for more information on these configuration options.

Remediation

Wind River has released hot patches for all affected Wind River products.

The following is a list of Wind River products and their vulnerabilities to CVE-2017-1000364, CVE-2017-1000365, and CVE-2017-1000366.

Product

Vulnerable

Version

Details**

VxWorks
No
5.x, 6.x, 7.x
Wind River Linux
Yes
9.x, 8.x, 7.x, 6.x, 5.x
Wind River Intelligent Device Platform
Yes
All
Note: Ensure appropriate remedial action is taken on the Linux product/version that Wind River Intelligent Network Platform is running on.
Wind River Workbench
No
All
Wind River Simics
No
All
** You need an account to access the Knowledge Library. If you don't have a valid Knowledge Library account, please contact local customer support.

We continue to monitor the situation on our security mailing lists in case there are new developments, and will post periodic updates via RSS feeds and the Wind River Support Network.

http://www.windriver.com/feeds/wrlinux_900.xml
http://www.windriver.com/feeds/wrlinux_800.xml
http://www.windriver.com/feeds/wrlinux_700.xml

You Can’t Afford A Security Breach

This is just one of the more than 6,000 security vulnerabilities that our Security Response Team analyzes annually, and only one of the more than 1,000 annually for which we have produced a fix and rolled it out to all of our current customers.

Our support and maintenance practices and processes provide the most tangible proof of value when choosing Wind River products.
Learn more about Wind River Security practices at www.windriver.com/products/linux/security.

Customers are urged to keep their support and maintenance contracts current, and to install the latest available updates to their installed products. If you don’t know if your support and maintenance contract is current, make sure to contact your Wind River representative.

Wind River Linuxが The Open GroupのFACE Technical StandardにLinuxとして初の適合を達成


デジタルトランスフォーメーションは、航空宇宙・防衛産業に大きな変革をもたらしています。

Return to Resource Center

The Future of Open RAN | Wind River

play
CHOOSE-YOUR-OWN WEBINAR

  The Future of Open RAN  

Distributed Open RAN can deliver savings of 22% in total cost of ownership for a large Tier 1 in Western Europe (Analysys Mason, 2022). Carriers and their clients can control costs while enabling innovation and growth.

Nicola Marziliano, Wind River® VP of International Telco Sales, and other experts discuss the evolution and future of Open RAN. View the entire session above, or choose the sections you’re most interested in below.

Nicola Marziliano

Sample Highlights

 
 
 

Container Security from Cloud to Edge-Japan

 



クラウドからエッジまでのコンテナセキュリティ

July 29, 2022 セキュリティ

ディープダイブ:クラウドセキュリティに関するQ&A

ウインドリバーでは、「Container Security from Cloud to Edge(クラウドからエッジまでのコンテナセキュリティ)」と題するウェビナーを開催し、クラウドやエッジを問わない、コンテナ化した環境を保護するには、多層防御アプローチが必要なことをご紹介しました。このウェビナーをまだご覧になっていない方は、是非こちらよりご覧ください。

以下は、ウェビナーでスコット・マックレガーが回答したQ&Aの一部です。

Q:コンテナ技術とはどのようなものですか?また、どのような利点があるのでしょうか?

コンテナ化とは、ソフトウェア(アプリケーションやサービス)を、ライブラリやフレームワークなどの依存関係にあるすべてのコンポーネントとともにパッケージ化することです。このパッケージ化されたものがコンテナです。必要な部品がすべて同じ場所にまとめて設置されているため、コンテナを移動しても、あらゆるインフラストラクチャで実行することができます。また、コンテナ技術を活用してアプリケーションを実行することで、コンテナが動作するオペレーティングシステム(OS)から独立して動作することが可能です。

コンテナ化の主な利点の1つは、ポータビリティです。今日の市場では、企業はアプリケーションをさまざまな環境にデプロイする方法を、「互換性のない」環境を生み出し、乗り換えをさけられない状況を促す独自の研究開発を行う代わりに、コンテナ技術を活用してアプリケーションの開発とデプロイを最適化し、開発投資を抑えたいと考えています。 コンテナ化は、お客様はOSレベル、あるいはCSP(クラウドサービスプロバイダ)レベルといったより高いレベルでのロックインを回避することを可能にします。Amazon、Azure、Google Cloudなどのクラウド上でコンテナを動作させ、そのコンテナを取り出して、CSP上で動作させたり、あるいは内部のマシンでローカルに動作させたりすることができます。ビルドは一度だけにするのがベストです。その他に注目すべき利点としては、高速なデプロイメント(軽量化による)、社内インフラのコスト削減(同じハードウェア上で複数のコンテナが実行可能なため)、アプリケーションの分離(システム上にあるのが自分のアプリケーションだけであるかのように動作可能なため)などが挙げられます。

Q:この技術を使うことによるリスクにはどのようなものがありますか?

コンテナ化のリスクは、そのメリットに直結するものもあります。重大なリスクの1つは、同じホストまたはマシン上で複数のコンテナを実行している場合、あるコンテナで実行中のプロセスの通信や動作が、別のコンテナで実行中のプロセスを認識してしまう可能性があることです。トラフィックや通信に加え、ファイルなどのアーティファクトが他のコンテナからアクセスできてしまう可能性もあります。小規模で機密性の低い環境であれば、これは大きな問題ではないかもしれない。しかし、クラウドサービスプロバイダや、複数の顧客が同じハードウェアを共有するホスト環境の場合は、これが何らかのリスクになり得ることは明らかです。

もう1つのリスクは、コンテナ自体の性質です。コンテナは再利用可能なイメージを利用するため、簡単に利用することができます。なぜなら、必要なコンポーネントの一部がすでに配置されている可能性のある、吟味されたイメージを利用するからです。しかし、このイメージにも他のものと同様に脆弱性が存在する可能性があります。ハッカーがイメージのリポジトリになりすますことにより、ユーザーは信頼できるイメージを使用していると思うかもしれませんが、実際には危険ないイメージを使用していることがあります。このようなイメージの脆弱性を設計の初期段階で発見しておかないと、コンテナが稼働しているあらゆる場所でその脆弱性が拡散してしまう可能性があります。イメージは静的なものであるため、パッチが適用されるか置き換えられるまで、これらの脆弱性は存在します。脆弱性のあるイメージによっては、それが発見されないと、様々なシステム上の様々なコンテナで実行されている他のイメージの一部になってしまう可能性があります。

Q:コンテナのセキュリティリスクを軽減するために、どのようなセキュリティ対策が有効でしょうか?

セキュリティ対策のベストプラクティスについては、様々なものがありますが、私がお勧めするのは、Center for Internet Security – CIS Benchmarksと、National Institute of Standards and Technology NIST SP 800-190 Application Container Security Guideの2つです。

これらのドキュメントでは、いくつかの対策方法と制御について紹介されています。ここでは、先に述べたリスクに対抗するために適用できる、2つの大きなカテゴリについて手短にお話しします。1つ目は、通信の機密性についてです。先ほど、あるコンテナから別のコンテナのトラフィックや通信を確認することができる可能性があることを述べました。Istioでは、TLSやmTLSといった技術を活用することができます。TLSは基本的に暗号化と鍵管理機能を用いて、意図した受信者だけが通信を読み取り、理解できるようにするものです。そのため、トラフィックが侵害された場合でも、暗号化されているため影響はありません。また、特定のエンティティ向けにネットワークトラフィックをセグメント化する、ネットワークポリシーを実装することもできます。

もう1つのカテゴリは、主にコンテナ内部のセキュリティ制御を扱うものです。これらの制御は、基盤となるコンテナの許容範囲、特権、および動作に影響を与えます。悪意のある攻撃者がコンテナにアクセスした場合に備え、あらゆる障害を大幅に制限します。より一般的な設定としては、runAsNonRoot(ルートレベルのアクションの実行を制限)、capabilities(コンテナ自身が使用できる機能を具体的に制御。重要な機能のみに限定したリストにより、全体的なセキュリティ体制を強化)、readOnlyRootFilesystem(悪意のあるものによる基本アプリケーションに対する改ざんや悪意のある実行ファイルのディスクへの書き込みを防止)があります。

Q:コンテナ技術の採用を推進しているソフトウェアプロジェクトには、どのようなものがありますか?

Cloud Native Computing Foundation (CNCF):CNCFは、クラウドネイティブコンピューティングをより普遍的、標準的、かつアクセスしやすくすることを目的としたオープンソースソフトウェアファウンデーションです。相対的な成熟度(サンドボックス、インキュベーティング、グラジュエーション)に基づいてプロジェクトを評価するモデルを定義しています。

関連するオープンソースプロジェクトは多数ありますが、その中でも特に注目したいのは、Kubernetes、Prometheus、Harborです。

Kubernetes:Kubernetesはコンテナのオーケストレーションシステムです。

Prometheus:Prometheus System Monitoring Toolは、環境内で実行されているコンテナを監視し、コンテナ内で実行されているアクティビティをよりわかりやすく監視する方法を提供します。

Harbor:Harbor Image Repositoryは、コンテナイメージのセキュアな管理を実現します。前述の通り、これはコンテナ化されたアプリケーションのセキュリティを確保する上で非常に重要です。(イメージから開始します)

多くのオープンソースプロジェクトが、コンテナセキュリティの領域に注力しています。さまざまなツールが、コンテナやコンテナイメージの脆弱性やベストプラクティスへの準拠を評価しています。ここでは、1つの重要なプロジェクトに焦点を当てたいと思います。それは、Open Policy Agent Gatekeeperです。Open Policy Agent Gatekeeperは、ユーザーが自分の環境内のコンテナが満たすべきさまざまなセキュリティ条件を定義することを可能にします。定義されたポリシーを満たさないコンテナは、システム上で実行させないというフェンスを設置することができます。このようなプロジェクトは、環境のセキュリティ体制を向上させる上で大きな役割を果たします。

Q:エッジ・ツー・クラウドのユースケースにコンテナ技術はどのように活用されているのでしょうか。

基本的にクラウドは、さまざまな場所に分散しているノード(または物理的なハードウェアマシンやコンピュータ)の接続されたセットと考えることができます。アプリケーション、サービス、プログラムは、これらのノードまたはデバイス上で実行され、インターネットを介してどこでも利用することができます。これらのノードはすべて、データセンターに設置されたコンピュータにすぎませんでした。しかし、現在では、エッジノードと呼ばれる機能を持つようになりました。エッジノードは、ユーザーの近くにあるより小型で堅牢なデバイスで、その場所からアプリケーションを実行することができます。例えば、自動車部品、通信システム、携帯端末といった小さなものをエッジノードと見なすことができるようになりました。これまでデータセンターにあるマシンで実行していたコンテナを、1つのエッジノードで実行できるようになったのです。

コンテナ化を活用している場合、これまで述べた脅威がすべて当てはまります。さらに、ノードがデータセンター内のコンピュータであることから、さらに1つの主要な懸念事項があります。私たちは、安全なデータセンターが提供するあらゆるセキュリティレイヤーと多層防御の恩恵を受けています。しかし、現在では、携帯端末のような小さなものでもエッジノードとして利用できるため、よりアクセスが容易となり、データセンター内のマシンが持つすべての保護を受けられなくなります。そこで、ウインドリバーは、潜在的なセキュリティ脅威への対策として、セキュアブートや耐タンパーなど、ハードウェアレベルのさまざまなセキュリティ制御を活用しています。これらにより、悪意ある攻撃者がシステムにアクセスできたとしても、そのシステムを危険にさらすことは難しくなります。

インテリジェントシステム分野への参入や、コンテナ化などのクラウドネイティブテクノロジーの活用を検討されている方、セキュリティアセスメントについてご相談などは、以下よりお問い合わせください。ウインドリバーが、お客様の目標に基づいたシステムのセキュリティ確保と変革に関する具体的な方法やや技術(オープンソースを含む)を支援いたします。
https://www.windriver.com/japan/contact