Linuxなどのスタック管理機構において権限昇格が可能な脆弱性が発見される。多くのLinuxディストリビューションに影響 65
皆様アップデートを 部門より
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は指摘しています。
ディストーション (スコア:1)
歪み・・・？
Linuxには詳しくないけど、ぱっと見にはディストリビューション(頒布形態)なんじゃないかなあ
RYZEN始めました
Re:ディストーション (スコア:1)
おっしゃる通りデストリビュージョン（配布物）ですね。
長いから仕方ないのかも。
＃文字数制限あんのかな？
Re: (スコア:0)
なんか変身でもしそうな語感ですね > デストリビュージョン
Re:ディストーション (スコア:1)
Re: (スコア:0)
こういう発音する方の脳内では
どのような綴りになっているのだろう？
ディスクトップとか
インストゥールとか
ワーニングとか
もう勘弁。
Re:ディストーション (スコア:1)
> ワーニング
Warning の表記なら、なにが勘弁なのかよくわからない。
ウォーニングって表記しろってこと？
ディスクトップ(Disktop?) や インストゥール(Instool?)とは全然別物だと思うけど
Re:ディストーション (スコア:1)
訂正されてる！
Re: (スコア:0)
つまり、今回の誤字はわざと入れたものではなく、意図しないものだったってことですね。
Re: (スコア:0)
こういうのには気楽におつかれと言いたいものだが、スラドの1コメントはそれをやるには少々重い。
Re: (スコア:0)
Linux で動いているギターエフェクターとかかな?
Re: (スコア:0)
「やぁｗ釣れた釣れた」と思っていることでしょう。
Re: (スコア:0)
Linuxの話題なのにアイコンはデーモン君。
よく見たらBSD系も対象でした。
これも罠なのか！
Re: (スコア:0)
単にアルファベット順だとL(inux)よりB(SD)が前だからだと思います。
アイコンの優先順位はアルファベット順→50音順のようなので。
正確な順番はタレコミ時のトピック一覧をどうぞ。
OpenBSD (スコア:1)
ファイルシステムが遅すぎてヒープをスタックと衝突させられないってのがいいね。
「畜生何でだ!! ソースを見る限りセキュリティホールはちゃんとあるのに……」
Re: (スコア:0)
Theo「よ、予想通り……(震え声)」
Re: (スコア:0)
脆弱性試験の為に速いマシンを寄付(以下略
ロゴがないからか (スコア:1)
Qualys がせっかく Stack Clash という格好いい名前をつけたのに
まったく無視されていて可哀想……。
Qualys は Google の Project Zero の対抗馬となるか？ とまで話題なのに
マーケティングでは今ひとつということでしょうかね。
Re: (スコア:0)
スタックでクラッシュなんて、
・意味が広すぎ
・一般人はスタックからしてわからん
ってのが問題なんじゃないかな。
ハートブリードだったら、
・内容はさっぱり
・一般人でもハートからブリードはやばそうだと思う
ってことだし。
いや、ハートブリードがマーケティング的に良かったのかはわからんが。
Re: (スコア:0)
脆弱性への名前つけはほんと意味ないからやめてほしい。
どうしても名前つけたかったらCVE-IDから適当に語呂合わせてしてやってくれ。
Re:ロゴがないからか (スコア:1)
小惑星への命名みたいなもんじゃない？
Re: (スコア:0)
てきとーでも名前を付けることで人間は認識しやすくなって結構有効なんだぞ。
# と言う話をシーマンの開発者のコラムとパトレイバーでやってた。
# コラムの載ってる本のタイトルは「ハンバーガーを待つ3分間の値段」だったかな。
で？ (スコア:0)
それで、一般ユーザはどうしたら良いの？
とりあえずアップデートはするけど…
Re:で？ (スコア:2)
CVE-2017-1000364の該当バージョンが4.11.5以前とあるので
最新のKernel 4.11.6に更新すれば……と思いきやChangeLogに
この件についてなにも書いてないので、アップデートして安心しては
イケない模様。
Re:で？ (スコア:1)
特権ユーザーに任せて待ってればいいです…違う？
Re: (スコア:0)
概ね、下記のいずれかで事足りる・・・はず。
yum update
apt-get upgrade
apt-get dist-upgrade
Re: (スコア:0)
一番下は実用上用途がちょっと違う。あとzypperが無い。
Re: (スコア:0)
お言葉に甘えて
zypper ref
zypper update
Re: (スコア:0)
emerge は?
Re: (スコア:0)
一般ユーザだったら、不特定多数がログインするシステムの管理なんかしてないだろうから、
自分の管理しているシステムに不正ログインされたりしないように気をつければ十分。
家を訪ねてきたハッカーな友人から目を離さないとか、端末から離れるときは常にロックするとかそういう一般的な対策あるのみ。
あとはいつの間にか出たパッチでいつか穴は塞がる。
Re: (スコア:0)
アップデートすりゃ良い。
Re:で？ (スコア:2)
OSX/macOSはこの辺どうなんでしょうね。
BSD各種とSolarisが挙がっていることからみると同様の脆弱性があるようにも見えますけど。
もしかしてゼロデイなの？ (スコア:0)
ストーリーにあるRed Hat Customer Portalを読むと、まだ根本的な解決策はなさそうなんだけど…。
どこかにアップデートがあるのかな？
Re: (スコア:0)
Status=Ongoing (継続中) なので、今後正式なパッチになるものと思われます。
根本解決をするには、まだいろいろやることがありそうです。
原理的におかしい？ (スコア:0)
「スタック範囲を他のメモリ領域と衝突させて悪用できる問題は2005年と2010年に示され、対策が取られてきました」
というあたり、元々の設計自体に問題がありすぎて、何度直しても穴が塞がらない感じがする。これ、実装の不備なんかじゃないだろ。
Re: (スコア:0)
スタック継続リフレッシュみたいな命令を加えんと無理だよね
復帰デファレンシャル・参照アドレス計算軽減用に何バイト持って行ってコピーするのか指示出来て新規セグメント生成出来るようなヤツ
いちいち4KB毎にアドレス確認すんの境目がループん中だったりしたらスゲー無駄だし
Re: (スコア:0)
x86「だからセグメントを使えとあれほど...」
Re: (スコア:0)
スタックは別のアドレス空間へ。
これ自体は脆弱性ではないのでは (スコア:0)
アドバイザリ読んだけど、別の脆弱性と組み合わせて、攻撃を構成する手段として効果的だよねって話に見える。
多重防御の観点から検出できた方がいいのはもちろんだけど、そもそも他の脆弱性が存在する状況が前提なので、
完全に防御するのはなかなか難しそう。
Re: (スコア:0)
たぶんそう。もし脆弱性だとしたらセキュリティフィックスのリリース前にゼロデイ脆弱性を公開したことになるわけで、Googleどころじゃない暴挙ということになる。
Linuxをつかってる機器 (スコア:0)
組込系は大丈夫なんだろうか？
再帰すべきか否か (スコア:0)
BSD系のqsortは再帰するから
スタック系の攻撃に弱いみたいだね。
再帰で書けるなら再帰で、というのが
意識高いプログラマかと思ってたけど
必ずしもそうではないと。
Re: (スコア:0)
言うまでもないことだが、再帰は使うメリットが大きい場面で使うものであって、何でも再帰で書けば良いというものではない。
Re: (スコア:0)
関数型言語「お前は俺達を敵に回した」
Re: (スコア:0)
Cで、通常想定される程度のスタック使用量で再帰するやつならガードページで捕まえられるんじゃない? それでクラッシュ(clashじゃなくてcrashの方)させるのを攻撃というなら攻撃だろうけど。今回のは従来の保護機構をスキップするような手段が見つかったって話じゃないのかな。
あと深い再帰でクラッシュっていうのは再帰そのものが悪いんじゃなくて言語ランタイム設計がそういう選択をしてるってことね。設計によっては深さを数えて一定以上はランタイムエラーを投げるものもあるし、割り当てられたスタック領域を使い切ったら生きてるフレームをヒープに移すことで事実上ヒープとスタックの境界を無くしたものとかもある。
言語の性質を知らないと再帰のコストは見えにくいけれど、ちゃんとわかってれば再帰はヒープとスタックのトレードオフだから適切な選択をすればいいだけ。
Re:再帰すべきか否か (スコア:1)
加えて、
今回の問題は qsort の再帰の深さ(=スタック使用量)が攻撃者の任意になることなので
再帰自体がどうとかではないようですね。
CVE-2017-1000373 [mitre.org]の修正 [openbsd.org]を見ても、
これで本当に防げているのか、私のような素人には中々理解できません…。
Re:再帰すべきか否か (スコア:1)
> CVE-2017-1000373 [mitre.org]の修正 [openbsd.org]を見ても、
> これで本当に防げているのか、私のような素人には中々理解できません…。
まったくです。私もこれはスタック使用量は減るだけで根本的に解決になっていないと思いますが、これで原理的に攻撃できるデータの組み合わせ存在しなくなるとか何かあるんですかね。
カーネル側の対策で、ガードとして1MB分あけるようにしているようです。
008: SECURITY FIX: May 19, 2017 [openbsd.org]
しかしこれもローカル変数が1MB以上あるような関数が呼び出されれば、ガードをスキップしてしまいそうな。
長い！ (スコア:0)
osdn曰く～の文章あることで、えらく弁解がましく見える。
他のOSだったら「未解決脆弱性」とかで終わってたんじゃないか？
Re: (スコア:0)
Solaris:ああ、まったくその通りだから私を使え
Re: (スコア:0)
HP-UX： うむ、おおむね同意
Re:言ってる意味がわからない・・・ (スコア:2)
stack-protector だけでは防げないという話のようです。名前が似ていますが stack-check はもっとコストの高い(普通はオフの)オプションです。ガードページをジャンプできるという問題ですので、ほんの数バイトのカナリアで防げるものではありません。
また、普通の VMAP_STACK では防げない、というのは記事の「悪用できる [grsecurity.net]」という部分のリンクにある grsecurity のブログで触れられています。