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