2.4.22-2.4.25/2.6.1-2.6.3にroot権限奪取可能な脆弱性 45
ストーリー by Oliver
メモリ管理は厳密に 部門より
メモリ管理は厳密に 部門より
Henrich 曰く、 "Debian-devel-announce メーリングリストに流されたメールによって知ったのだが、linux kernelに脆弱性がまた見つかっている。この脆弱性の対象となるバージョンは2.4系が2.4.22-2.4.25、2.6系が2.6.1-2.6.3。最新版は影響を受けない。 この脆弱性を発見したiSECのアドバイザリによると「2.4.22及び2.6.1で取り入れられたsetsockoptシステムコールの MCAST_MSFILTERオプションに欠陥があり、オーバーフローを起こす可能性がある。これによってローカルユーザがroot権限を奪うことが可能になり、権限を奪えなくともDoSとなってサーバの停止や再起動を起こせる」という話だ。"
処理に必要なメモリ割り当て量を計算する時にInteger Overflowを発生させることにより、後に割り当てられたメモリの範囲外を上書きできてしまう、というバグだ。
2.4.25 (スコア:2, おもしろおかしい)
半年前には見つけていたらしい。 (スコア:2, 参考になる)
Paul Starzetz (ihaquer@isec.pl) discovered the vulnerability over half a year ago.
うーむ。
Re:半年前には見つけていたらしい。 (スコア:1, 参考になる)
これが直ったのはたぶんこのバグ報告 [kernel.org]でだと思うんですが・・・。
＃後出しジャンケンって言葉が浮かぶので AC
Re:半年前には見つけていたらしい。 (スコア:1)
Re:半年前には見つけていたらしい。 (スコア:0)
なんでオープンソース厨は
「Linuxや*BSDもWindowsも穴だらけ」
と言われると怒るんだろう。
Re:半年前には見つけていたらしい。 (スコア:0)
#独り身なのでAC
2.4系ですが (スコア:2, 参考になる)
2.4.26には他にもここで話題になった [srad.jp]分の対策もありますね.
一応参考までに ITmediaの記事 [itmedia.co.jp]です.
何にしても早めにバージョンアップしておいた方がよさそうです.
Re:2.4系ですが (スコア:1)
Vine でも kernelのupdate [vinelinux.org]がでてました.
でも このストーリのやつについては まだのようで 他のやつは対策してあるようですね.
sudoで (スコア:1)
# Windoze感覚なユーザなのでID
/.configure;oddmake;oddmake install
Re:sudoで (スコア:2)
Re:sudoで (スコア:0)
＃用もないのにroot権限で動かしているのと何も変わらん。
Re:sudoで (スコア:1, すばらしい洞察)
WindowsUpdateをやるにはAdministrator権限が必要だよね。
Re:sudoで (スコア:1)
Administrator でログオンしなくてもできるよ。
俺はいつもそれで Windows Update やってる。
ログオンしないとできないこと/不便なことって、結構限られているような。
# mishimaは本田透先生を熱烈に応援しています
Re:sudoで (スコア:1)
この文章は飛躍しすぎでないかい。
元コメントを受けて、「sudo 経由で何でもできる設定にする」のと、「ユーザーそのものにスーパーユーザー権限を持たせて何でもできるようにする」のとが、単に「違うよ」と書いただけなんだけどねぇ。
Re:sudoで (スコア:1)
→ コマンドを root 権限で起動することはできるが、コマンド経由しない限り、root 権限がないと実行できないシステムコール (ex. iopl) は実行できない
→ コマンドを経由しなくてもスーパーユーザとして振舞える
まあ、「コマンド」に「sh」とか「su」とかが含まれてれば別ですが。
# まさかそんな事はしてないですよねえ？ ＞ oddmake 氏 [srad.jp]
Re:sudoで (スコア:1)
# やぼ
## ブラウザ系とか、ありそうですね
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:sudoで (スコア:0)
Re:sudoで (スコア:0)
integer overflow (スコア:0)
ヤバそうな所を自動検出するツールとか作れないかな。
Re:integer overflow (スコア:2, おもしろおかしい)
64bitアドレスになればoverflowするほどメモリは積めないので大丈夫!
# ウソ度1000%なのでID
Re:integer overflow (スコア:0)
Re:integer overflow (スコア:1)
ちょっとマジレスですが, いくら20年前の人でも32bitじゃあすぐに足りなくなるのは見えていましたよ. その時点で例えば画像処理や数値計算用途では20bit(i8086, Z8000)では全く役立たず, 24bit(mc68000, ns32016)でなんとかという状態でしたから. 余裕は8bit分, 容量で256倍になれば終わりです.
今回の32bitアドレスから64bitアドレスへの変更はbit数で見れば2倍になったにすぎませんが, 容量で見れば40億倍. ムーアの法則の様な対数的容量増加が続いたと仮定しても, 32bitCPUが主流になってから今までの時間の3～4倍はもつ計算になります.
ただ今度は富豪的メモリ空間割り当て手法とかを使って, 実メモリとは関係無しにアドレスを食いつぶすなんてこともあり得ますけどね.
Re:integer overflow (スコア:0)
メモリは手元にあるとは限らないし、アドレスはメモリ上のデータを指すとも限らないですからね。
ネットワーク上の他ノードのメモリ空間や、ファイル等のリソースを全てメモリ空間にマップするって話も新しいものじゃないし。 (10年以上前ですが、当時は64bitあれば何とかなるんじゃないって話だったかな)。
Re:integer overflow (スコア:1)
libsafe [avayalabs.com]とかがお勧めです。自動検出ツールは
知らないですけど。
romfffromのコメント設定
AC-2、プラスモデ+3、閾値0、スコアを表示しない(推奨)、高い評価のコメントを親にする
libsafe(off topic) (スコア:2, 参考になる)
ちなみにlibcをstaticリンクしている
バイナリにlibsafeは効きません。
BSDは先日 /binをdynamicリンクしました [srad.jp]が、
Linuxはふつうはしていないのでスタティックリンクしている
/bin /sbin に関数のバグには注意....
あ、libparanoiaもあったか。あれってどうなってるのかな...
やなぎ
字面じゃなく論旨を読もう。モデレートはそれからだ
Re:libsafe(off topic) (スコア:3, 参考になる)
あれ? Linux はかなり昔から /bin /sbin ともにダイナミックリンクだったはずですよ。覚えているのは slackware 3.1 の頃からですが。
# むしろこの事で、 *BSD 使いの人に「キモい」と言われていました(笑)
以下 debian sid の結果。 2 つとも意図的にスタティックリンクしたものですね
% file /{bin,sbin}/* | grep statically
/bin/sash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, statically linked, stripped
/sbin/ldconfig: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, statically linked, stripped
Re:libsafe(off topic) (スコア:2, 参考になる)
訂正です。
Fedora で確かめてみたら、 filesystem 周りのコマンドも statically linked でした。
distribution に依るんですね。
Re:integer overflow (スコア:0)
Re:integer overflow (スコア:2, 参考になる)
防ぐことはしないけど、インテガーオーバーフローが
原因でおこるバファーオーバーフローを防ぐことが
できます。
#今回の件で言えば、カーネルのバファーオーバフローを
#防ぐ事ができます。
インテガーオーバーフローが原因の脆弱性は
多くの場合それが、バファーオーバーフローを
起こさせててコードを走らせているように思うので、
結果的には多くのインテガーオーバーフローが原因の
脆弱性にも有効な対策のように私は思います。
SafeintはC++ソースがあって、自分でコンパイルして
走らせる場合には大変良いと思います。
#Pingをピングと書く人間なので読みにくかったら
#ゴメソ
romfffromのコメント設定
AC-2、プラスモデ+3、閾値0、スコアを表示しない(推奨)、高い評価のコメントを親にする
Re:integer overflow [補足] (スコア:1)
だめらしいです。ちなみに、私はカーネルが
Cでかかれているのかさえ知らないダメポなので、
今回の脆弱性をlibsafeで防げるのか知りません。
カーネルなんだから、リンクとかは利用しないような
気がするので、libsafeがlibcをダイナミックで
利用してるプログラム用だとカーネルの
バッファオーバーフローは防げないですね。
romfffromのコメント設定
AC-2、プラスモデ+3、閾値0、スコアを表示しない(推奨)、高い評価のコメントを親にする
Re:integer overflow (スコア:0)
Re:integer overflow (スコア:1)
# splint とかにこの手のチェックを盛り込めないかな...
Re:またですか (スコア:2, おもしろおかしい)
弱いところもふくめてオーポンなのがいいのよ。オーポン。
Re:またですか (スコア:1, おもしろおかしい)
Re:またですか (スコア:2, すばらしい洞察)
Re:またですか (スコア:0)
Re:またですか (スコア:1)
あとFedora系ならup2dateが赤「！」になります。
Re:またですか (スコア:1)
三日風呂に入らなかったら、あなたはすめるまんです。
Re:またですか (スコア:0)
ツーカーも不具合出す時代だし。
＃激しくオフトピ
またですよ (スコア:0)
そうですね。
# だからなに？
Re:またですよ (スコア:0)
こんなにコメント付いちゃって。
Re:またですよ (スコア:0)
そっとしておいてあげてください。