アカウント名:
パスワード:
実はジャンクション機能の仕様の脆弱性なんじゃないかなぁ。
権限がないと消せないなら本質的にはジャンクション機能の問題ではなさげ。特権を持ってるセキュリティソフトがこれを盲目的に使うから問題になる。
と記事から判断してたんだけど、そうじゃないのかなあ?
致命傷になるという点ではジャンクション周りの取り扱いミスだけど、任意のファイルを消させる的が出来るという点では、レースコンディション系バグでよくあるミス。検知したあとに「すり替えておいたのさ!」が出来る間があるのが問題だからね。
検知から削除までをアトミックに実施できないなら、ブートプロセスの初期段階でロックされる前に再チェックして削除するしかない。
TxFを再設計して載せるとか。。やんないだろうなぁ。
と言うかWindowsの機能じゃなくて自前で削除すべきだね。ハンドル閉じられるまで粘ったりハンドル強制的に閉じるのもありかな。どうせ強制削除でファイル参照してるプロセスはエラー踏むし。
# ジャンクションとアンチウィルスと言えば、# XP時代、ジャンクション先に置いてたハックツールにノートンがブチ切れて消そうとするも、# ジャンクションをうまく扱えずに削除失敗ポップアップが無限ループしてたのを思い出す……
UNIXなら典型的なsymlink attackでアプリは当然対策していなければならないけど、Windowsはsymlink機能が後付けなのでこうなる。Windowsでsymlinkに管理者権限とかデベロッパーモードとかが必要な理由なのだがsymlinkと類似の機能であるジャンクションはなぜか不要なんだよな。
おまえ何か勘違いしてるな
この脆弱性の場合、UNIXにおけるsymlinkならば、何ら対策などいらないなぜならsymlinkファイルに対して削除したところで、実体には影響なくsymlinkファイル自体が削除されるだけだからだ必要なのはApacheのFollowSymlinkのように、symlinkファイルの指す先まで辿るか否かということの方
UNIXなら仮にhardlinkされていたとしても問題ない削除したとしてもhardlinkカウンタがひとつ減るだけの話でありカウンタがゼロになるまで、どこか別の場所にあるhardlinkされていたファイル自体は存在し続ける
この脆弱性で言及されているWindowsにおけるジャン
この問題はどちらかというと、「Windowsが提供するファイル削除予約機能」の脆弱性じゃないかな。ファイル移動のAPIである MoveFileEx(変更後ファイル名をnullにすれば削除もできる)は、フラグ指定により、即座に実行せず再起動時に処理するようにできる。「ロックされているファイルも操作できる」という便利機能であり、Windowsで動くアプリがよくアップデート時に再起動を促される羽目になる元凶。
こいつが、名前ベースで予約してるから、「予約してから再起動するまでの間に移動元に指定したファイルが変更されても、変更後のファイルが処理対象になる」ことで、今回の問題がおきる。ジャンクションを使うのが手軽なだけで、ジャンクションを使わなくても不正な処理を行わせるシナリオはありえると思う。
MoveFileExを呼び出した時点で、再起動まで変更できないようにロックしてしまうとか、再起動での処理実行時にMFT番号?とか?で、API呼び出しと同じかどうか検証するとか、無関係なファイルを処理しないようにするのが、正しい挙動じゃないかな、と。
まあ、今更 Windows API の挙動を変更するわけにはいかないので、MoveFileExを呼び出す側で慎重に取り扱う、という対応をするしかないでしょうけど。
削除予約時と削除実行時で実際のファイルが異なることを想定して使っていることは悪いことをする目的以外ではほとんどないんじゃないかと（個人的には）思うので、別にMoveFileExの挙動を変えてしまってもいいんじゃないかなあ。
そういう隙をつく攻撃も、TOCTOUという名前がついているほど典型的
この問題はどちらかというと、「Windowsが提供するファイル削除予約機能」の脆弱性じゃないかな。
うーん消す機能も予約機能も脆弱性とはいえないのでその操作指示の問題じゃないかなんでシステムファイルを消せる権限付与を全開放しているわけじゃないから脆弱性とはいえないかとんでセキュリティソフトウェアに対する特権付与も脆弱性とはいえないかと
なので権限内で操作できるというだけですから悪質な指示をセキュリティソフトウェアが出すならセキュリティソフトウェアの悪意だし悪質な指示をセキュリティソフトウェアが受け付けて代理してしまうならセキュリティソフトウェアの脆弱性ってことじゃないかなぁ
# まぁWindowsのジャンクションってユーザーの想定外でデータ消えちゃう仕様だからってのはなくもない
それほどの強権って何を指してるの？
消させるのはリンク自体じゃなくリンク先ディレクトリに入ってるファイルだろ例えばC:\mydir\explorer.exeというマルウェアを作成してロックし、再起動時削除が予約されたらmydirを削除して代わりにC:\Windowsを指すリンクを作成することでC:\Windows\explorer.exeを削除させられるって寸法
> この脆弱性の場合、UNIXにおけるsymlinkならば、何ら対策などいらない> なぜならsymlinkファイルに対して削除したところで、実体には影響なくsymlinkファイル自体が削除されるだけだからだ
おまえ何か勘違いしてるななんでシンボリックリンク貼る先がファイル前提なんだ？間のディレクトリに貼れば実体ごと消えるだろ
例）~/virus/hoge を用意して引っ掛けさせる。そんでAVが消す前にln -s /sbin ~/virus する。AV が rm ~/virus/hoge したら /sbin/hoge も消えるsymlinkなら大丈夫、な分けない
回避するには権限というのは正しいが、AVにどこまでの権限を与えるか（どこまでのファイルを削除・隔離するか）の要件に依存するだけてかclamavもclamonaccはrootで動かすだろ頭おかしいと思うほうが頭おかしい
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
これって (スコア:0)
実はジャンクション機能の仕様の脆弱性なんじゃないかなぁ。
Re: (スコア:0)
権限がないと消せないなら本質的にはジャンクション機能の問題ではなさげ。
特権を持ってるセキュリティソフトがこれを盲目的に使うから問題になる。
と記事から判断してたんだけど、そうじゃないのかなあ?
Re: (スコア:0)
致命傷になるという点ではジャンクション周りの取り扱いミスだけど、
任意のファイルを消させる的が出来るという点では、レースコンディション系バグでよくあるミス。
検知したあとに「すり替えておいたのさ!」が出来る間があるのが問題だからね。
検知から削除までをアトミックに実施できないなら、ブートプロセスの初期段階でロックされる前に再チェックして削除するしかない。
Re: (スコア:0)
TxFを再設計して載せるとか。。やんないだろうなぁ。
Re: (スコア:0)
と言うかWindowsの機能じゃなくて自前で削除すべきだね。
ハンドル閉じられるまで粘ったりハンドル強制的に閉じるのもありかな。
どうせ強制削除でファイル参照してるプロセスはエラー踏むし。
# ジャンクションとアンチウィルスと言えば、
# XP時代、ジャンクション先に置いてたハックツールにノートンがブチ切れて消そうとするも、
# ジャンクションをうまく扱えずに削除失敗ポップアップが無限ループしてたのを思い出す……
Re: (スコア:0)
UNIXなら典型的なsymlink attackでアプリは当然対策していなければならないけど、Windowsはsymlink機能が後付けなのでこうなる。Windowsでsymlinkに管理者権限とかデベロッパーモードとかが必要な理由なのだがsymlinkと類似の機能であるジャンクションはなぜか不要なんだよな。
Re: (スコア:0, 参考になる)
おまえ何か勘違いしてるな
この脆弱性の場合、UNIXにおけるsymlinkならば、何ら対策などいらない
なぜならsymlinkファイルに対して削除したところで、実体には影響なくsymlinkファイル自体が削除されるだけだからだ
必要なのはApacheのFollowSymlinkのように、symlinkファイルの指す先まで辿るか否かということの方
UNIXなら仮にhardlinkされていたとしても問題ない
削除したとしてもhardlinkカウンタがひとつ減るだけの話であり
カウンタがゼロになるまで、どこか別の場所にあるhardlinkされていたファイル自体は存在し続ける
この脆弱性で言及されているWindowsにおけるジャン
Re:これって (スコア:4, 参考になる)
この問題はどちらかというと、「Windowsが提供するファイル削除予約機能」の脆弱性じゃないかな。
ファイル移動のAPIである MoveFileEx(変更後ファイル名をnullにすれば削除もできる)は、
フラグ指定により、即座に実行せず再起動時に処理するようにできる。
「ロックされているファイルも操作できる」という便利機能であり、
Windowsで動くアプリがよくアップデート時に再起動を促される羽目になる元凶。
こいつが、名前ベースで予約してるから、
「予約してから再起動するまでの間に移動元に指定したファイルが変更されても、変更後のファイルが処理対象になる」
ことで、今回の問題がおきる。
ジャンクションを使うのが手軽なだけで、ジャンクションを使わなくても不正な処理を行わせるシナリオはありえると思う。
MoveFileExを呼び出した時点で、
再起動まで変更できないようにロックしてしまうとか、
再起動での処理実行時にMFT番号?とか?で、API呼び出しと同じかどうか検証するとか、
無関係なファイルを処理しないようにするのが、正しい挙動じゃないかな、と。
まあ、今更 Windows API の挙動を変更するわけにはいかないので、
MoveFileExを呼び出す側で慎重に取り扱う、という対応をするしかないでしょうけど。
Re: (スコア:0)
削除予約時と削除実行時で実際のファイルが異なることを想定して使っていることは
悪いことをする目的以外ではほとんどないんじゃないかと（個人的には）思うので、
別にMoveFileExの挙動を変えてしまってもいいんじゃないかなあ。
Re: (スコア:0)
そういう隙をつく攻撃も、TOCTOUという名前がついているほど典型的
Re: (スコア:0)
この問題はどちらかというと、「Windowsが提供するファイル削除予約機能」の脆弱性じゃないかな。
うーん消す機能も予約機能も脆弱性とはいえないのでその操作指示の問題じゃないかな
んでシステムファイルを消せる権限付与を全開放しているわけじゃないから脆弱性とはいえないかと
んでセキュリティソフトウェアに対する特権付与も脆弱性とはいえないかと
なので権限内で操作できるというだけですから
悪質な指示をセキュリティソフトウェアが出すならセキュリティソフトウェアの悪意だし
悪質な指示をセキュリティソフトウェアが受け付けて代理してしまうならセキュリティソフトウェアの脆弱性
ってことじゃないかなぁ
# まぁWindowsのジャンクションってユーザーの想定外でデータ消えちゃう仕様だからってのはなくもない
Re: (スコア:0)
adminじゃないとMOVEFILE_DELAY_UNTIL_REBOOTフラグは立てられないと思ったけど
Re: (スコア:0)
それほどの強権って何を指してるの？
Re: (スコア:0)
消させるのはリンク自体じゃなくリンク先ディレクトリに入ってるファイルだろ
例えばC:\mydir\explorer.exeというマルウェアを作成してロックし、再起動時削除が予約されたらmydirを削除して代わりにC:\Windowsを指すリンクを作成することでC:\Windows\explorer.exeを削除させられるって寸法
Re: (スコア:0)
> この脆弱性の場合、UNIXにおけるsymlinkならば、何ら対策などいらない
> なぜならsymlinkファイルに対して削除したところで、実体には影響なくsymlinkファイル自体が削除されるだけだからだ
おまえ何か勘違いしてるな
なんでシンボリックリンク貼る先がファイル前提なんだ？
間のディレクトリに貼れば実体ごと消えるだろ
例）
~/virus/hoge を用意して引っ掛けさせる。そんでAVが消す前に
ln -s /sbin ~/virus する。
AV が rm ~/virus/hoge したら /sbin/hoge も消える
symlinkなら大丈夫、な分けない
回避するには権限というのは正しいが、AVにどこまでの権限を与えるか（どこまでのファイルを削除・隔離するか）の要件に依存するだけ
てかclamavもclamonaccはrootで動かすだろ
頭おかしいと思うほうが頭おかしい