アカウント名:
パスワード:
sudoの脆弱性の件はともかく、Linuxカーネルに対してこの手の攻撃が可能になる意味がわからない。まずそもそも自分が使ってるカーネルの.configを見て、CC_STACKPROTECTOR_NONEになってるような状況が想像できない。デフォルトでCC_STACKPROTECTOR_REGULARであるし、セキュリティ意識の高い兄貴にあってはCC_STACKPROTECTOR_STRONGでビルドし直していることだろう。また、Linuxの現行リリース版は4.11.*であるが、4.9.*以降ならVMAP_STACKもあるわけで、これをわざわざ落としておく意味もわからない。Skylake以降のCPU使っていれば、X86_INTEL_MPXだって普通に利用しているだろ。
更にいうと、少なくとも現在Supported Releases中のGCCは、全て-fstack-protectorデフォルトであり。自らわざわざ-fno-stack-protectorしてビルドしない限り、ビルドはできてもその成果物でこの手の攻撃が成功することはない。てか今時はVisual Studioでさえ/GSデフォルトでしょ。
ただ単に古いだけのものを「枯れた」とかいって有難がる人達がいるのは否定しないが、今回の件に関しては完全に自業自得だろ。Windows等に関しても言えることだけど、「枯れた」と称していつまでも古いものを使い続けるってのは、想像しているよりもハイリスクだぞ。
stack-protector だけでは防げないという話のようです。名前が似ていますが stack-check はもっとコストの高い(普通はオフの)オプションです。ガードページをジャンプできるという問題ですので、ほんの数バイトのカナリアで防げるものではありません。また、普通の VMAP_STACK では防げない、というのは記事の「悪用できる [grsecurity.net]」という部分のリンクにある grsecurity のブログで触れられています。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
言ってる意味がわからない・・・ (スコア:0)
sudoの脆弱性の件はともかく、Linuxカーネルに対してこの手の攻撃が可能になる意味がわからない。
まずそもそも自分が使ってるカーネルの.configを見て、CC_STACKPROTECTOR_NONEになってるような状況が想像できない。
デフォルトでCC_STACKPROTECTOR_REGULARであるし、セキュリティ意識の高い兄貴にあってはCC_STACKPROTECTOR_STRONGでビルドし直していることだろう。
また、Linuxの現行リリース版は4.11.*であるが、4.9.*以降ならVMAP_STACKもあるわけで、これをわざわざ落としておく意味もわからない。
Skylake以降のCPU使っていれば、X86_INTEL_MPXだって普通に利用しているだろ。
更にいうと、少なくとも現在Supported Releases中のGCCは、全て-fstack-protectorデフォルトであり。
自らわざわざ-fno-stack-protectorしてビルドしない限り、ビルドはできてもその成果物でこの手の攻撃が成功することはない。
てか今時はVisual Studioでさえ/GSデフォルトでしょ。
ただ単に古いだけのものを「枯れた」とかいって有難がる人達がいるのは否定しないが、今回の件に関しては完全に自業自得だろ。
Windows等に関しても言えることだけど、「枯れた」と称していつまでも古いものを使い続けるってのは、想像しているよりもハイリスクだぞ。
Re:言ってる意味がわからない・・・ (スコア:2)
stack-protector だけでは防げないという話のようです。名前が似ていますが stack-check はもっとコストの高い(普通はオフの)オプションです。ガードページをジャンプできるという問題ですので、ほんの数バイトのカナリアで防げるものではありません。
また、普通の VMAP_STACK では防げない、というのは記事の「悪用できる [grsecurity.net]」という部分のリンクにある grsecurity のブログで触れられています。