「セキュリティソフトウェアに任意ファイルを削除させることが可能な脆弱性」記事へのコメント

これって

[Anonymous Coward]

実はジャンクション機能の仕様の脆弱性なんじゃないかなぁ。

Re:

[Anonymous Coward]

UNIXなら典型的なsymlink attackでアプリは当然対策していなければならないけど、Windowsはsymlink機能が後付けなのでこうなる。Windowsでsymlinkに管理者権限とかデベロッパーモードとかが必要な理由なのだがsymlinkと類似の機能であるジャンクションはなぜか不要なんだよな。

Re:

[Anonymous Coward]

おまえ何か勘違いしてるな

この脆弱性の場合、UNIXにおけるsymlinkならば、何ら対策などいらない
なぜならsymlinkファイルに対して削除したところで、実体には影響なくsymlinkファイル自体が削除されるだけだからだ
必要なのはApacheのFollowSymlinkのように、symlinkファイルの指す先まで辿るか否かということの方

UNIXなら仮にhardlinkされていたとしても問題ない
削除したとしてもhardlinkカウンタがひとつ減るだけの話であり
カウンタがゼロになるまで、どこか別の場所にあるhardlinkされていたファイル自体は存在し続ける

この脆弱性で言及されているWindowsにおけるジャン

Re:これって

[taka2 (14791)]

この問題はどちらかというと、「Windowsが提供するファイル削除予約機能」の脆弱性じゃないかな。
ファイル移動のAPIである MoveFileEx(変更後ファイル名をnullにすれば削除もできる)は、
フラグ指定により、即座に実行せず再起動時に処理するようにできる。
「ロックされているファイルも操作できる」という便利機能であり、
Windowsで動くアプリがよくアップデート時に再起動を促される羽目になる元凶。

こいつが、名前ベースで予約してるから、
「予約してから再起動するまでの間に移動元に指定したファイルが変更されても、変更後のファイルが処理対象になる」
ことで、今回の問題がおきる。
ジャンクションを使うのが手軽なだけで、ジャンクションを使わなくても不正な処理を行わせるシナリオはありえると思う。

MoveFileExを呼び出した時点で、
再起動まで変更できないようにロックしてしまうとか、
再起動での処理実行時にMFT番号?とか?で、API呼び出しと同じかどうか検証するとか、
無関係なファイルを処理しないようにするのが、正しい挙動じゃないかな、と。

まあ、今更 Windows API の挙動を変更するわけにはいかないので、
MoveFileExを呼び出す側で慎重に取り扱う、という対応をするしかないでしょうけど。

Re:

[Anonymous Coward]

削除予約時と削除実行時で実際のファイルが異なることを想定して使っていることは
悪いことをする目的以外ではほとんどないんじゃないかと（個人的には）思うので、
別にMoveFileExの挙動を変えてしまってもいいんじゃないかなあ。

Re:

[Anonymous Coward]

そういう隙をつく攻撃も、TOCTOUという名前がついているほど典型的

Re:

[Anonymous Coward]

この問題はどちらかというと、「Windowsが提供するファイル削除予約機能」の脆弱性じゃないかな。

うーん消す機能も予約機能も脆弱性とはいえないのでその操作指示の問題じゃないかな
んでシステムファイルを消せる権限付与を全開放しているわけじゃないから脆弱性とはいえないかと
んでセキュリティソフトウェアに対する特権付与も脆弱性とはいえないかと

なので権限内で操作できるというだけですから
悪質な指示をセキュリティソフトウェアが出すならセキュリティソフトウェアの悪意だし
悪質な指示をセキュリティソフトウェアが受け付けて代理してしまうならセキュリティソフトウェアの脆弱性
ってことじゃないかなぁ

# まぁWindowsのジャンクションってユーザーの想定外でデータ消えちゃう仕様だからってのはなくもない

Re:

[Anonymous Coward]

システムファイルを消せる権限付与を全開放しているのでは？
adminじゃないとMOVEFILE_DELAY_UNTIL_REBOOTフラグは立てられないと思ったけど