パスワードを忘れた? アカウント作成
13316204 story
BSD

Linuxなどのスタック管理機構において権限昇格が可能な脆弱性が発見される。多くのLinuxディストリビューションに影響 65

ストーリー by hylom
皆様アップデートを 部門より

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は指摘しています。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Emc2 (14960) on 2017年06月21日 16時39分 (#3231871) 日記

    歪み・・・?

    Linuxには詳しくないけど、ぱっと見にはディストリビューション(頒布形態)なんじゃないかなあ

    --
    RYZEN始めました
    • おっしゃる通りデストリビュージョン(配布物)ですね。
      長いから仕方ないのかも。

      #文字数制限あんのかな?

      親コメント
    • by Anonymous Coward on 2017年06月21日 17時23分 (#3231917)

      訂正されてる!

      親コメント
      • by Anonymous Coward

        つまり、今回の誤字はわざと入れたものではなく、意図しないものだったってことですね。

      • by Anonymous Coward

        こういうのには気楽におつかれと言いたいものだが、スラドの1コメントはそれをやるには少々重い。

    • by Anonymous Coward

      Linux で動いているギターエフェクターとかかな?

    • by Anonymous Coward

      「やぁw釣れた釣れた」と思っていることでしょう。

    • by Anonymous Coward

      Linuxの話題なのにアイコンはデーモン君。
      よく見たらBSD系も対象でした。
      これも罠なのか!

      • by Anonymous Coward

        単にアルファベット順だとL(inux)よりB(SD)が前だからだと思います。
        アイコンの優先順位はアルファベット順→50音順のようなので。
        正確な順番はタレコミ時のトピック一覧をどうぞ。

  • by Anonymous Coward on 2017年06月21日 17時43分 (#3231931)

    ファイルシステムが遅すぎてヒープをスタックと衝突させられないってのがいいね。
    「畜生何でだ!! ソースを見る限りセキュリティホールはちゃんとあるのに……」

    • by Anonymous Coward

      Theo「よ、予想通り……(震え声)」

      • by Anonymous Coward

        脆弱性試験の為に速いマシンを寄付(以下略

  • by osdn (47242) on 2017年06月21日 17時47分 (#3231933)

    Qualys がせっかく Stack Clash という格好いい名前をつけたのに
    まったく無視されていて可哀想……。
    Qualys は Google の Project Zero の対抗馬となるか? とまで話題なのに
    マーケティングでは今ひとつということでしょうかね。

    • by Anonymous Coward

      スタックでクラッシュなんて、
      ・意味が広すぎ
      ・一般人はスタックからしてわからん
      ってのが問題なんじゃないかな。

      ハートブリードだったら、
      ・内容はさっぱり
      ・一般人でもハートからブリードはやばそうだと思う
      ってことだし。

      いや、ハートブリードがマーケティング的に良かったのかはわからんが。

    • by Anonymous Coward

      脆弱性への名前つけはほんと意味ないからやめてほしい。
      どうしても名前つけたかったらCVE-IDから適当に語呂合わせてしてやってくれ。

  • by Anonymous Coward on 2017年06月21日 18時01分 (#3231943)

    それで、一般ユーザはどうしたら良いの?
    とりあえずアップデートはするけど…

    • by kohzoh (34869) on 2017年06月21日 22時14分 (#3232077) 日記

      CVE-2017-1000364の該当バージョンが4.11.5以前とあるので
      最新のKernel 4.11.6に更新すれば……と思いきやChangeLogに
      この件についてなにも書いてないので、アップデートして安心しては
      イケない模様。

      親コメント
    • by Anonymous Coward on 2017年06月21日 18時26分 (#3231961)

      特権ユーザーに任せて待ってればいいです…違う?

      親コメント
    • by Anonymous Coward

      概ね、下記のいずれかで事足りる・・・はず。
      yum update
      apt-get upgrade
      apt-get dist-upgrade

      • by Anonymous Coward

        一番下は実用上用途がちょっと違う。あとzypperが無い。

    • by Anonymous Coward

      一般ユーザだったら、不特定多数がログインするシステムの管理なんかしてないだろうから、
      自分の管理しているシステムに不正ログインされたりしないように気をつければ十分。
      家を訪ねてきたハッカーな友人から目を離さないとか、端末から離れるときは常にロックするとかそういう一般的な対策あるのみ。
      あとはいつの間にか出たパッチでいつか穴は塞がる。

    • by Anonymous Coward

      アップデートすりゃ良い。

  • by Anonymous Coward on 2017年06月21日 19時27分 (#3232004)

    ストーリーにあるRed Hat Customer Portalを読むと、まだ根本的な解決策はなさそうなんだけど…。
    どこかにアップデートがあるのかな?

    • by Anonymous Coward

      Status=Ongoing (継続中) なので、今後正式なパッチになるものと思われます。
      根本解決をするには、まだいろいろやることがありそうです。

  • by Anonymous Coward on 2017年06月21日 19時53分 (#3232014)

    「スタック範囲を他のメモリ領域と衝突させて悪用できる問題は2005年と2010年に示され、対策が取られてきました」
    というあたり、元々の設計自体に問題がありすぎて、何度直しても穴が塞がらない感じがする。これ、実装の不備なんかじゃないだろ。

    • by Anonymous Coward

      スタック継続リフレッシュみたいな命令を加えんと無理だよね
      復帰デファレンシャル・参照アドレス計算軽減用に何バイト持って行ってコピーするのか指示出来て新規セグメント生成出来るようなヤツ
      いちいち4KB毎にアドレス確認すんの境目がループん中だったりしたらスゲー無駄だし

      • by Anonymous Coward

        x86「だからセグメントを使えとあれほど...」

    • by Anonymous Coward

      スタックは別のアドレス空間へ。

  • by Anonymous Coward on 2017年06月21日 20時40分 (#3232036)

    アドバイザリ読んだけど、別の脆弱性と組み合わせて、攻撃を構成する手段として効果的だよねって話に見える。

    多重防御の観点から検出できた方がいいのはもちろんだけど、そもそも他の脆弱性が存在する状況が前提なので、
    完全に防御するのはなかなか難しそう。

    • by Anonymous Coward

      たぶんそう。もし脆弱性だとしたらセキュリティフィックスのリリース前にゼロデイ脆弱性を公開したことになるわけで、Googleどころじゃない暴挙ということになる。

  • by Anonymous Coward on 2017年06月21日 23時20分 (#3232111)

    組込系は大丈夫なんだろうか?

  • by Anonymous Coward on 2017年06月22日 0時41分 (#3232138)

    BSD系のqsortは再帰するから
    スタック系の攻撃に弱いみたいだね。
    再帰で書けるなら再帰で、というのが
    意識高いプログラマかと思ってたけど
    必ずしもそうではないと。

    • by Anonymous Coward

      言うまでもないことだが、再帰は使うメリットが大きい場面で使うものであって、何でも再帰で書けば良いというものではない。

      • by Anonymous Coward

        関数型言語「お前は俺達を敵に回した」

    • by Anonymous Coward

      Cで、通常想定される程度のスタック使用量で再帰するやつならガードページで捕まえられるんじゃない? それでクラッシュ(clashじゃなくてcrashの方)させるのを攻撃というなら攻撃だろうけど。今回のは従来の保護機構をスキップするような手段が見つかったって話じゃないのかな。

      あと深い再帰でクラッシュっていうのは再帰そのものが悪いんじゃなくて言語ランタイム設計がそういう選択をしてるってことね。設計によっては深さを数えて一定以上はランタイムエラーを投げるものもあるし、割り当てられたスタック領域を使い切ったら生きてるフレームをヒープに移すことで事実上ヒープとスタックの境界を無くしたものとかもある。

      言語の性質を知らないと再帰のコストは見えにくいけれど、ちゃんとわかってれば再帰はヒープとスタックのトレードオフだから適切な選択をすればいいだけ。

      • by osdn (47242) on 2017年06月22日 16時04分 (#3232478)

        加えて、
        今回の問題は qsort の再帰の深さ(=スタック使用量)が攻撃者の任意になることなので
        再帰自体がどうとかではないようですね。
        CVE-2017-1000373 [mitre.org]の修正 [openbsd.org]を見ても、
        これで本当に防げているのか、私のような素人には中々理解できません…。

        親コメント
        • by tho (23328) on 2017年06月22日 19時37分 (#3232647)

          > CVE-2017-1000373 [mitre.org]の修正 [openbsd.org]を見ても、
          > これで本当に防げているのか、私のような素人には中々理解できません…。
          まったくです。私もこれはスタック使用量は減るだけで根本的に解決になっていないと思いますが、これで原理的に攻撃できるデータの組み合わせ存在しなくなるとか何かあるんですかね。

          カーネル側の対策で、ガードとして1MB分あけるようにしているようです。
          008: SECURITY FIX: May 19, 2017 [openbsd.org]
          しかしこれもローカル変数が1MB以上あるような関数が呼び出されれば、ガードをスキップしてしまいそうな。

          親コメント
  • by Anonymous Coward on 2017年06月22日 2時02分 (#3232169)

    osdn曰く~の文章あることで、えらく弁解がましく見える。
    他のOSだったら「未解決脆弱性」とかで終わってたんじゃないか?

typodupeerror

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

読み込み中...