アカウント名:
パスワード:
実はジャンクション機能の仕様の脆弱性なんじゃないかなぁ。
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)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
これって (スコア:0)
実はジャンクション機能の仕様の脆弱性なんじゃないかなぁ。
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で動かすだろ
頭おかしいと思うほうが頭おかしい