アカウント名:
パスワード:
まず対象のサーバーに入ってシンボリックリンクを張っておいてから、外部からwgetを仕掛けるってことかな。だとしたらサーバーに入れる時点で好きなことができると思うけどそうでもないのか。
あるいは、自分では入れないけど何らかの手段でシンボリックリンクを作らせるように「誘導」するか。そこに細工されたシンボリックリンクが既に存在していることを知っているような状況か。もしや「偶然」そんなシンボリックリンクが存在している環境があるのか。/.J諸兄ならどうするんでしょうか。ってやったらダメだけど。
賢いクラッカーはもっとスマートにあれこれやるんだろうなぁ。#わたしゃとてもゆうちゃんの足元にも及びそうもないし・・・
逆でしょ。
・攻撃者はFTPサーバーを運営する。・被害者はそこからwgetでファイルをダウンロードする。(ように、なんかウェブサイトで指示しておく。「ミラーだよ」とか。)
ときに、wgetがこっちのシンボリックリンクに対してgetをかけてきたら、シンボリックリンクに変なコマンドを仕込んでおいて、被害者側のマシンにファイルを作ることができるってこと。ユーザー権限の設定ファイルを書き換えることもできる、ってこと。bashやXの設定ファイルにキーロガーとかできるんじゃないかな。
攻撃対象はローカル(wgetを実行している端末)なので。たとえば攻撃者がFTPサーバーを用意して、偽の解説ページなどを利用してwgetでアクセスするよう誘導すると、ローカルにマルウェアを仕込むことが可能になります。
お間抜けなftpやhttp管理者が、公開向けディレクトリに/etc/passwordへのシンボリックリンクをうっかり入れちゃっていたような場合に、再帰的ダウンロードをしたいDLユーザのwget実行時に、wgetが「誠実なあまり」DLユーザのPCの/etc/passwordへのシンボリックリンクとして解釈してDLユーザのPCの/etc/passwordを上書きしちゃう！
って困った挙動だ、というわけで、攻撃の手段がどうこうというのは違うのでは。
#ていうか、root権限を持たないで実行すればまあ大体の（システムに影響するような）問題は発生しないんで、#(windowsや一部のLinuxみたいに）常時root権限で、rootのままwgetするなんて#wgetが作られたころは想定外だったのではないか。
と、タレこみ文とリンク先を見ただけの印象なので嘘かもしれません。
↓たぶんエロい人が正解を書いてくれる。
/etc/passwd じゃなければよさげ。もしそこでシンボリックリンク貼ったとしてpasswd自体のパーミッションは効かないのかな。
別にrootでなくても ~/.ssh/authorized_keys とか狙えばいいんでは。
~/.bashrcを上書きされて任意のプログラム動かされたり、データ送信されるだけでも嫌すぎる感じ。
#ていうか、root権限を持たないで実行すればまあ大体の（システムに影響するような）問題は発生しないんで、
んなわけねー。じゃあユーザーがrootを取れないAndroidやiPhoneは一切セキュリティの心配がいらないってか？
#(windowsや一部のLinuxみたいに）常時root権限で、rootのままwgetするなんて
UACが導入されたの何年前だよ…。エンジニアがそんな不勉強で大丈夫か？
>#(windowsや一部のLinuxみたいに）2014(XPサポート切れ)問題ここに現れるかぁ〜・・・たぶんそのエンジニアは、もうサポート切れなんじゃないか？
UACなんてどうせ「はい」か「続行」しか選択しないでしょ
あなたがバカだからといって他人までそうとは限らない
こういう人はどうせ「自分は知識があるから」って常にrootなんだろうな
root不要なファイル参照にroot使ってたり、DBでフル権限ユーザしか定義がない大規模システムがあちこちにある現実があります。
UAC自体をバグだと語ってる場所もあります。
もう、通常ログオン不可（回避不可）にする時期が来てるのかも。。なんだかなぁ。。。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
この場合攻撃者は (スコア:1)
まず対象のサーバーに入ってシンボリックリンクを張っておいてから、外部からwgetを仕掛けるってことかな。
だとしたらサーバーに入れる時点で好きなことができると思うけどそうでもないのか。
あるいは、自分では入れないけど何らかの手段でシンボリックリンクを作らせるように「誘導」するか。
そこに細工されたシンボリックリンクが既に存在していることを知っているような状況か。
もしや「偶然」そんなシンボリックリンクが存在している環境があるのか。
/.J諸兄ならどうするんでしょうか。ってやったらダメだけど。
賢いクラッカーはもっとスマートにあれこれやるんだろうなぁ。
#わたしゃとてもゆうちゃんの足元にも及びそうもないし・・・
Re:この場合攻撃者は (スコア:1)
逆でしょ。
・攻撃者はFTPサーバーを運営する。
・被害者はそこからwgetでファイルをダウンロードする。(ように、なんかウェブサイトで指示しておく。「ミラーだよ」とか。)
ときに、wgetがこっちのシンボリックリンクに対してgetをかけてきたら、シンボリックリンクに変なコマンドを仕込んでおいて、被害者側のマシンにファイルを作ることができるってこと。ユーザー権限の設定ファイルを書き換えることもできる、ってこと。bashやXの設定ファイルにキーロガーとかできるんじゃないかな。
Re: (スコア:0)
攻撃対象はローカル(wgetを実行している端末)なので。
たとえば攻撃者がFTPサーバーを用意して、偽の解説ページなどを利用してwgetでアクセスするよう誘導すると、
ローカルにマルウェアを仕込むことが可能になります。
Re: (スコア:0)
お間抜けなftpやhttp管理者が、公開向けディレクトリに/etc/passwordへのシンボリックリンクをうっかり入れちゃっていたような場合に、
再帰的ダウンロードをしたいDLユーザのwget実行時に、wgetが「誠実なあまり」DLユーザのPCの/etc/passwordへのシンボリックリンクとして解釈して
DLユーザのPCの/etc/passwordを上書きしちゃう！
って困った挙動だ、というわけで、攻撃の手段がどうこうというのは違うのでは。
#ていうか、root権限を持たないで実行すればまあ大体の（システムに影響するような）問題は発生しないんで、
#(windowsや一部のLinuxみたいに）常時root権限で、rootのままwgetするなんて
#wgetが作られたころは想定外だったのではないか。
と、タレこみ文とリンク先を見ただけの印象なので嘘かもしれません。
↓たぶんエロい人が正解を書いてくれる。
Re:この場合攻撃者は (スコア:1)
/etc/passwd じゃなければよさげ。
もしそこでシンボリックリンク貼ったとしてpasswd自体のパーミッションは効かないのかな。
Re: (スコア:0)
別にrootでなくても ~/.ssh/authorized_keys とか狙えばいいんでは。
Re: (スコア:0)
~/.bashrcを上書きされて任意のプログラム動かされたり、データ送信されるだけでも嫌すぎる感じ。
Re: (スコア:0)
#ていうか、root権限を持たないで実行すればまあ大体の（システムに影響するような）問題は発生しないんで、
んなわけねー。
じゃあユーザーがrootを取れないAndroidやiPhoneは一切セキュリティの心配がいらないってか？
#(windowsや一部のLinuxみたいに）常時root権限で、rootのままwgetするなんて
UACが導入されたの何年前だよ…。エンジニアがそんな不勉強で大丈夫か？
Re: (スコア:0)
>#(windowsや一部のLinuxみたいに）
2014(XPサポート切れ)問題ここに現れるかぁ〜
・・・たぶんそのエンジニアは、もうサポート切れなんじゃないか？
Re: (スコア:0)
UACなんてどうせ「はい」か「続行」しか選択しないでしょ
Re: (スコア:0)
あなたがバカだからといって他人までそうとは限らない
Re: (スコア:0)
こういう人はどうせ「自分は知識があるから」って常にrootなんだろうな
Re: (スコア:0)
root不要なファイル参照にroot使ってたり、DBでフル権限ユーザしか定義がない大規模システムがあちこちにある現実があります。
UAC自体をバグだと語ってる場所もあります。
もう、通常ログオン不可（回避不可）にする時期が来てるのかも。。なんだかなぁ。。。