アカウント名:
パスワード:
リンク先のITmediaの記事に書かれていますが、root権限がなくてもシステムの時刻を変更することができます。
このため管理者パスワードを入力しなくても、「systemsetup」ユーティリティを使って簡単にOS Xに変更を加えることができてしまうという。
$ systemsetup -setdate mm:dd:yy$ systemsetup -settime hh:mm:ss
実際の挙動は知らないけれど、 ITmedia の記事には「root 権限がなくてもシステムの時刻を変更することができる」なんて書いてないよ。それに、システム全体に影響のある設定が root 権限なしでできるってのは、さすがにないだろうという気がする。
そこに書いてあるのは、「システムの日付が 1970 年 1 月 1 日になっていれば、過去に sudo したことのあるユーザーが再度 sudo するのにパスワードを入力する必要がない」というだけ。もちろん、既にシステムの日付が 1970 年 1 月 1 日になっていれば、この挙動を使って、過去に sudo したことのあるユーザーがスクリーンロックしないで離席中に他人がシステムの日付を変えることもできるけれど、それをしてもメリットはないでしょ。
ところでこれ、「/var/db/sudo/username ディレクトリーが未来の時刻になっていると sudo がパスワードを要求しない」というだけで、 1970 年 1 月 1 日が sudo にとって何か特別な意味を持っているわけじゃないと思うんだけど…。そうだとしたら、これを「the 01 January 1970 bug」と呼ぶのは本質を見逃していると思う。
システム全体に影響のある設定が root 権限なしでできるってのは、さすがにないだろうという気がする。
他のスレッドで言及されていますが、管理者グループに所属していなければならないものの、root権限なしでシステム時刻を変更することは可能ですよ。
説明ありがとうございます。 Mac では、 sudo できるユーザー (sudo で root 権限をいつでも使える) とただのユーザーの間に、管理者グループのユーザー (systemsetup コマンドを使える) というのがあるのですね。知りませんでした。
僕は勘違いしていましたが、「/var/db/sudo/username ディレクトリーが未来の時刻になっていると sudo がパスワードを要求しない」というわけではないみたいですね。 /var/db/sudo/username ディレクトリーの時刻に合わせてシステム時刻を変えて、あたかも /var/db/sudo/username ディレクトリーが過去 5 分以内に作られたかのような振りをしてやれば、パスワードを入力することなく sudo ができるということのようです。特に sudo -k が「次回はパスワードを要求するようにする」という意味だと思って使っていると、じつは前回入力を epoch として扱うだけなので、 sudo -k の後でもシステム時刻を epoch から 5 分以内に変えればパスワードの入力なしで sudo できてしまう。
実際のシナリオでは、 sudo できる人が、 sudo -k しておけば離席中に他の人に勝手に sudo を実行される心配はないと思っていたら、 sudo はできないけれどシステム時刻を変えることができるユーザーに対して安全でないということですね。もともと sudo -k しただけでロックしないで離席するという行動が僕には信じられないので、 sudo の挙動自体は騒ぐような問題ではないと思うのですが、 sudo -k の意味があまりないじゃん、とは言えそうです。
リンク先に書いてあるとおりだとすると、正規のユーザがsudoやsudo -kを行ったかどうかは関係無いのでは?
「If … the user has ever run the "sudo" command」と書いてあるので、過去に少なくとも 1 度 sudo を使ったことがあることは必要です。 sudo -k は既にある /var/db/sudo/username ディレクトリーの時刻を epoch に変えるだけで、ディレクトリーが存在しない場合に作るわけではないということだと思います。 Sophos のブログ記事にも、 sudo -K を使えば /var/db/sudo/username が削除されるので対策になると書いてあります。
僕は sudo できるユーザーが離席している間に、攻撃者 (root 権限を取りたい通りがかりの人) が離席中の人のアカウントからシステム時刻を設定すれば良い、という点を完全に見落としていました。 #2453590 でも全然駄目でした。
sudo -k を使わなくても、 /var/db/sudo/username ディレクトリーの時刻に合わせてシステム時刻を変えれば良いと思うので、 sudo -k は本質ではないと思います…が、まだ何か間違えているかも。
管理者権限のないユーザーで実行してみたところ
$ systemsetup -setdate 01:01:01You need administrator access to run this tool... exiting!
と怒られてしまいましたとさ。管理者権限を持ったユーザーでログインしているとき、他人に渡さなければ大丈夫そうです。
手元で試してみたら、管理者ユーザーなら root権限なしで実行できるみたい。非mac (linux)な人に説明すると、「管理者アカウント != rootアカウント(権限)」ってことね。
別ACだが、もう少し言うと、管理ユーザってのは Windows でいうところの Administrator グループに属している扱い。ようするに実質的には管理者権限を持っている人。unix 風に言うと、sudo ユーザ
systemsetup コマンドを使えるユーザーは、そもそもが管理ユーザーに属している(管理権限を持っている)ので、パスワードなしで実行でも良いだろ。とか、そういうセンスなんだと思う。systemsetup コマンドがパスワードなしで実行できて、日付を変更できて、sudo の脆弱性をつくことが出来る人ってのは、脆弱性を突く必要もなく、最初から sudo ユー
今試してみたら、管理者ユーザーはwheelじゃなくstaffでしたが。(Mountain Lion)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
そもそも (スコア:0)
この操作にroot権限が必要だったりしません?
Mac OSはどうなのか知りませんが。
Re:そもそも (スコア:2)
リンク先のITmediaの記事に書かれていますが、root権限がなくてもシステムの時刻を変更することができます。
$ systemsetup -setdate mm:dd:yy
$ systemsetup -settime hh:mm:ss
Re:そもそも (スコア:2)
実際の挙動は知らないけれど、 ITmedia の記事には「root 権限がなくてもシステムの時刻を変更することができる」なんて書いてないよ。それに、システム全体に影響のある設定が root 権限なしでできるってのは、さすがにないだろうという気がする。
そこに書いてあるのは、「システムの日付が 1970 年 1 月 1 日になっていれば、過去に sudo したことのあるユーザーが再度 sudo するのにパスワードを入力する必要がない」というだけ。もちろん、既にシステムの日付が 1970 年 1 月 1 日になっていれば、この挙動を使って、過去に sudo したことのあるユーザーがスクリーンロックしないで離席中に他人がシステムの日付を変えることもできるけれど、それをしてもメリットはないでしょ。
ところでこれ、「/var/db/sudo/username ディレクトリーが未来の時刻になっていると sudo がパスワードを要求しない」というだけで、 1970 年 1 月 1 日が sudo にとって何か特別な意味を持っているわけじゃないと思うんだけど…。そうだとしたら、これを「the 01 January 1970 bug」と呼ぶのは本質を見逃していると思う。
Re: (スコア:0)
他のスレッドで言及されていますが、管理者グループに所属していなければならないものの、
root権限なしでシステム時刻を変更することは可能ですよ。
Re:そもそも (スコア:2)
説明ありがとうございます。 Mac では、 sudo できるユーザー (sudo で root 権限をいつでも使える) とただのユーザーの間に、管理者グループのユーザー (systemsetup コマンドを使える) というのがあるのですね。知りませんでした。
Re: (スコア:0)
特別な意味を持ってるみたいです。
こんな大事な場所での素朴な実装が時代を感じさせます。
Re:そもそも (スコア:2)
僕は勘違いしていましたが、「/var/db/sudo/username ディレクトリーが未来の時刻になっていると sudo がパスワードを要求しない」というわけではないみたいですね。 /var/db/sudo/username ディレクトリーの時刻に合わせてシステム時刻を変えて、あたかも /var/db/sudo/username ディレクトリーが過去 5 分以内に作られたかのような振りをしてやれば、パスワードを入力することなく sudo ができるということのようです。特に sudo -k が「次回はパスワードを要求するようにする」という意味だと思って使っていると、じつは前回入力を epoch として扱うだけなので、 sudo -k の後でもシステム時刻を epoch から 5 分以内に変えればパスワードの入力なしで sudo できてしまう。
実際のシナリオでは、 sudo できる人が、 sudo -k しておけば離席中に他の人に勝手に sudo を実行される心配はないと思っていたら、 sudo はできないけれどシステム時刻を変えることができるユーザーに対して安全でないということですね。もともと sudo -k しただけでロックしないで離席するという行動が僕には信じられないので、 sudo の挙動自体は騒ぐような問題ではないと思うのですが、 sudo -k の意味があまりないじゃん、とは言えそうです。
Re: (スコア:0)
前提条件は、sudoが可能なユーザがログインした状態で放置されている端末で、
パスワードなどの入力無しにシステムクロックを変更可能、だけかと。
・そういう端末でsudo -kを実行
・sudo-kにより、sudoは、「前回1970/1/1 00:00に実行された」と、実行記録を書き換える
・システムクロックをその直後に設定すれば、sudoはそれを「制限時間内の再実行」と見なして通す
と。
sudoは、
(1) その端末上で、パスワードが入力されるなど、正しくsudoが実行された
(2)
Re:そもそも (スコア:2)
「If … the user has ever run the "sudo" command」と書いてあるので、過去に少なくとも 1 度 sudo を使ったことがあることは必要です。 sudo -k は既にある /var/db/sudo/username ディレクトリーの時刻を epoch に変えるだけで、ディレクトリーが存在しない場合に作るわけではないということだと思います。 Sophos のブログ記事にも、 sudo -K を使えば /var/db/sudo/username が削除されるので対策になると書いてあります。
僕は sudo できるユーザーが離席している間に、攻撃者 (root 権限を取りたい通りがかりの人) が離席中の人のアカウントからシステム時刻を設定すれば良い、という点を完全に見落としていました。 #2453590 でも全然駄目でした。
sudo -k を使わなくても、 /var/db/sudo/username ディレクトリーの時刻に合わせてシステム時刻を変えれば良いと思うので、 sudo -k は本質ではないと思います…が、まだ何か間違えているかも。
Re: (スコア:0)
管理者権限のないユーザーで実行してみたところ
$ systemsetup -setdate 01:01:01
You need administrator access to run this tool... exiting!
と怒られてしまいましたとさ。
管理者権限を持ったユーザーでログインしているとき、他人に渡さなければ大丈夫そうです。
Re: (スコア:0)
手元で試してみたら、管理者ユーザーなら root権限なしで実行できるみたい。
非mac (linux)な人に説明すると、「管理者アカウント != rootアカウント(権限)」ってことね。
Re: (スコア:0)
別ACだが、
もう少し言うと、管理ユーザってのは Windows でいうところの Administrator グループに属している扱い。
ようするに実質的には管理者権限を持っている人。unix 風に言うと、sudo ユーザ
systemsetup コマンドを使えるユーザーは、そもそもが管理ユーザーに属している(管理権限を持っている)ので、
パスワードなしで実行でも良いだろ。とか、そういうセンスなんだと思う。
systemsetup コマンドがパスワードなしで実行できて、日付を変更できて、sudo の脆弱性をつくことが出来る人ってのは、
脆弱性を突く必要もなく、最初から sudo ユー
Re: (スコア:0)
今試してみたら、管理者ユーザーはwheelじゃなくstaffでしたが。
(Mountain Lion)
Re: (スコア:0)
別ACだけど、もうちょっと細かく言うと、管理ユーザーに属したユーザーであればsystemsetupコマンドをパスワード無しでも無条件に実行できるというわけではないです。
具体的には、システム環境設定にて各設定を変更可能に設定してあれば(カギのアイコンがアンロックされている状態であれば)systemsetupコマンドもパスワード無しで実行できるというだけです。
ロック状態からアンロック状態にするにはパスワードが必用なので、結局パスワードは必用ってことになります。
まぁ、アンロック状態で放置できてしまうという事は問題かもしれませんが。