LinuxやUNIX系OSにおいて、一般ユーザーが不正に特権を得ることができる「Stack Guard Page Circumvention」と呼ばれる攻撃手法が発見された（Red Hat Customer Portal）。Linuxカーネルやglibc、sudoなどの脆弱性を利用するもので、幅広い影響が出るようだ。

ベースとなっているのは、スタック領域に多量のメモリ割り当てとデータ書き込みを行ってスタック領域を溢れさせることで、ヒープ領域のデータを不正に書き換えられることがあるという問題。Red Hatによると、関連する脆弱性はCVE-2017-1000364（Linuxカーネルのstack guard pageの脆弱性）、CVE-2017-1000366（glibcでLD_LIBRARY_PATHの値に細工をすることでヒープ/スタックの値を操作できる脆弱性）、CVE-2017-1000367（sudo 1.8.20以前の入力バリデーションの不備）という3つとされている。osdn曰く、

スタック範囲を他のメモリ領域と衝突させて悪用できる問題は2005年と2010年に示され、対策が取られてきました。しかしセキュリティ企業Qualysが19日、少なくともLinux、OpenBSD、NetBSD、FreeBSD、Solarisのi386とamd64では対策の不備があり、実際に悪用可能か、少なくともPoCが存在することを示しました。（ITmedia）。

数多くの入口からローカル権限上昇攻撃ができた （あるいは理論上可能な道筋がある） そうです。緩和策としてはlimits.conf等でスタックを制限することなどがありますが、完全ではありませんし副作用も大きいです。各ベンダーには既に通知され、順次対策が取られることになっていますので、アップデートの用意をしておくのが最善でしょう。

アドバイザリによれば、Debianでも8.5と8.6、また8.xと9以上の間には脆弱さに大きな違いがあり、最新のものほど効率よく悪用することは難しくなってきているそうです。

しかし現状で最も簡単に悪用できる方法はi386のDebianでEximを使ってローカル権限上昇をすることだ、とQualysは指摘しています。またOpenBSDではatを使って攻撃しようとしたものの、ファイルシステムが遅すぎて、一週間かけてもヒープがスタックに届くほどの数のジョブファイルを作成できなかったそうです。

なお、今回は64bitでもスタックと他領域が近い場合があることも示されましたが、基本的にはメモリ領域が広い方が安全です。

grsecurity/PaXにはスタック・ガードページの大きさを変更できる機能があるので、これを大きくするのは簡単で有効です。またGCCには-fstack-checkというオプションがあり、各4KBページにアクセスすることで、スタックポインタが他領域に行ってしまう前に必ずガードページに当たり、SEGVになってくれるそうです。パフォーマンスに影響はありますが、長期的には良い方法だとQualysは指摘しています。