アカウント名:
パスワード:
どうみても仕様。こういうのをどや顔で脆弱性報告しちゃうのはどうかと思うし、受け付けちゃうのもびっくりする。日本のITスキルの水準がわかる事例。
大昔のUnixにあったPATHに.を入れる慣習と同じくらい頭の悪い仕様に見えるんだが、気のせいかなあ。
そしてそのUnixでもさすがにLD_LIBRARY_PATHに.を入れるなんて暴挙は寡聞にして知らない。
いや、今回の話はカレントディレクトリじゃないっすよ。exeと同一ディレクトリのほう。(カレントディレクトリはだいぶ前に優先順位が下げられてます)Windowsは大抵、実行ファイルを(PATHの通っていない)任意の場所に置くので、DLLを実行ファイルと同一ディレクトリから読めないと、アプリ固有のDLLが使えなくなります。(*nixなんかでも、「同一ディレクトリ中の別スクリプトを呼ぶの禁止」とかになったら困るよね?)
これについてはmacOSも同様なんだろうけど、あっちはそもそもapp形式の実体がディレクトリな上、バイナリ配布は大抵dmg(ディスクイメージ)で行うので、「同一ディレクトリ内に攻撃者のDLLが置かれる」という状況自体が発生しないのかも。
>(*nixなんかでも、「同一ディレクトリ中の別スクリプトを呼ぶの禁止」とかになったら困るよね?)
驚くべきことに、伝統的なUnixでは実行プロセス側から自分の実行ファイルがどのディレクトリにあるのか調べるAPIはそもそも存在しない。execve()で絶対パスを指定する形で起動されていたら自分の引数を見れば解決するのだが、そうでなければ$PATHを探すとかgetcwd()の結果を見るとかいった不確実な方法しかない。
実行ファイルの場所が調べられないってのはクソだと思う(実際、Linuxでは /proc の下を覗くと情報が取れるようになっている)けど、結果として「実行ファイルと同一ディレクトリの別スクリプトを呼ぶの禁止」なんて縛りは伝統的なUnixでは存在しえない、ということになる。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
イミフ (スコア:0)
どうみても仕様。こういうのをどや顔で脆弱性報告しちゃうのはどうかと思うし、受け付けちゃうのもびっくりする。日本のITスキルの水準がわかる事例。
Re: (スコア:2, すばらしい洞察)
大昔のUnixにあったPATHに.を入れる慣習と同じくらい頭の悪い仕様に見えるんだが、気のせいかなあ。
そしてそのUnixでもさすがにLD_LIBRARY_PATHに.を入れるなんて暴挙は寡聞にして知らない。
Re:イミフ (スコア:0)
いや、今回の話はカレントディレクトリじゃないっすよ。exeと同一ディレクトリのほう。
(カレントディレクトリはだいぶ前に優先順位が下げられてます)
Windowsは大抵、実行ファイルを(PATHの通っていない)任意の場所に置くので、DLLを実行ファイルと同一ディレクトリから読めないと、アプリ固有のDLLが使えなくなります。
(*nixなんかでも、「同一ディレクトリ中の別スクリプトを呼ぶの禁止」とかになったら困るよね?)
これについてはmacOSも同様なんだろうけど、あっちはそもそもapp形式の実体がディレクトリな上、バイナリ配布は大抵dmg(ディスクイメージ)で行うので、「同一ディレクトリ内に攻撃者のDLLが置かれる」という状況自体が発生しないのかも。
Re: (スコア:0)
>(*nixなんかでも、「同一ディレクトリ中の別スクリプトを呼ぶの禁止」とかになったら困るよね?)
驚くべきことに、伝統的なUnixでは実行プロセス側から自分の実行ファイルがどのディレクトリにあるのか調べるAPIはそもそも存在しない。execve()で絶対パスを指定する形で起動されていたら自分の引数を見れば解決するのだが、そうでなければ$PATHを探すとかgetcwd()の結果を見るとかいった不確実な方法しかない。
実行ファイルの場所が調べられないってのはクソだと思う(実際、Linuxでは /proc の下を覗くと情報が取れるようになっている)けど、結果として「実行ファイルと同一ディレクトリの別スクリプトを呼ぶの禁止」なんて縛りは伝統的なUnixでは存在しえない、ということになる。
Re: (スコア:0)
でも動いてるバイナリをmvで移動してもプロセスはそのまま動作し続ける(それどころかrmで消してもよい)のがUnixのセマンティクスだから実行ファイルの場所なんか知ってもしゃーないという気が