
Linux向けのHDD暗号化機構に脆弱性、Enterキーを押し続けるだけでroot権限を取得 28
この状況に当てはまるシステムは少なく無さそう 部門より
多くのLinuxディストリビューションで採用されている、ソフトウェアによるディスク暗号化機構を利用するためのcryptsetupというツールに脆弱性が確認された(ZDNet Japan)。
この脆弱性は暗号化パーティションをマウントするために必要なブート時のパスワード入力に連続で失敗することで、rootパスワードを入力せずにroot権限で起動されたシェルを操作できるようになってしまうというもの。暗号化されたパーティションにはアクセスできないが、それ以外のパーティションにはアクセスが可能になってしまう。
脆弱性の発生原理はCVE-2016-4484: Cryptsetup Initrd root Shellというドキュメントで公開されているが、実装の不備によるもののようだ。
Linuxのブートスクリプトでは初期化に時間がかかるデバイスなどに対処するため、マウントできなかったデバイスについてマウント処理を繰り返すコードが含まれている。暗号化パーティションのマウントは、通常は間違ったパスワードを3回入力すると失敗となり、その状態でブート作業が継続されるようになっているのだが、このコードのためにパスワードを4回以上繰り返し入力できる状態になっているという。さらにマウント処理を一定回数(x86システムの場合30回)失敗するとroot権限でシェルが起動するようになっているそうだ。つまり、x86システムの場合合計93回パスワードの入力に失敗するとrootパスワードの入力なしにroot権限でシェルを操作できてしまうようになるという。
解決方法としては、3回パスワード入力に失敗したら再起動を要求するようコードを修正する、というものが提示されている。
これを思い出した (スコア:2)
Xbox Oneにてスペースバー連打でログインできる不具合が発見される [security.srad.jp]
Re: (スコア:0)
タイトルで真っ先にこれが浮かんだ
Re: (スコア:0)
ゲームにありがちな、テストプレイ用の無敵モードみたいな隠しコマンドなんじゃないかと思った。
SUNのrootこじ開け方(昔ね) (スコア:1)
むかーし大学研究室のrootのパスが判らなくなったと泣きつかれてやったこと
1.モニタに落とす(L1+Aだったかな)
2.CDからブート(solarisだったかな)
3.メンテ用のシングルユーザシェルからsdaをマウント
4./etc/passwdを書き換える(rootを空pwにする)
5.リブート
いまでもこんな方法は使えるのでしょうか
Re: (スコア:0)
CDからブートが有りなら、大抵の場合
rootやAdministratorくらいは取れるでしょ。
Windowsなら、utilman.exeを書き換える方法が有名ですよね。
http://www.atmarkit.co.jp/ait/articles/1312/06/news055.html [atmarkit.co.jp]
パーティション自体が暗号化されていれば
Windows、Linuxに限らず中のデータを取り出すことはできないし。
中のデータ取り出さなくてもいいから
Root/Administrator権限がほしいなら
いっその事、再インストールしてしまえばいいのではw
Re: (スコア:0)
一応ファームウェアにパスワードかけて機動デバイスを変更できないようにすることもできる。まあバックアップバッテリー外して電源オフにすれば再インストールはできる。
Re: (スコア:0)
いにしえのSUNは電池モールドRTC付属のRAMにMACアドレスも入っていたものだから
電池消耗でMACアドレス蒸発がセットでしたね
モールド剥がして無理やり電池繋いで復活させたものです
(MACアドレスはテケトにでっち上げ)
この状況に当てはまるシステムは少なく無さそう 部門 (スコア:0)
猫がキー踏んでた、とか
Re:この状況に当てはまるシステムは少なく無さそう 部門 (スコア:1)
『再起動中』に『攻撃者がパスワード入力可能』な
状況でなければ攻撃は成立しないようなので、
この脆弱性が存在するシステムは多くても、
実際に攻撃される場面はそんなに無いかも。
Re:この状況に当てはまるシステムは少なく無さそう 部門 (スコア:1)
確かに修正すべき脆弱性だと思うけど、影響範囲を見ているとLinux搭載ライフルスコープの「付近に攻撃者が想定される
場合は、通常の銃火器で対応してください」という緩和策に近いものを感じる。
Re: (スコア:0)
猫にroot取られるとかw
でもこれディスクは暗号化されてるし、rootで起動できてもやれることは少なそうですね。
Re: (スコア:0)
色々試してみたけど、一般ユーザじゃ普通は
・パーティションやループバックデバイス作れないし、
・アクセス権限もないからluksOpenできない
のでダイジョブそうだね。
#で、あってるよね?
Re: (スコア:0)
通常 /boot と initramfs は暗号化されていないので、そこに罠を埋め込まれる危険はあるけど。
「リカバリCD-ROMとかで起動するとパスワード無しでルートになることができる」という脆弱性wより少し安全ですね。
Re: (スコア:0)
掃除のおばちゃんがハード再起動させたとか
コンソールに起動時に触れるなら (スコア:0)
いくらでも方法あるような。
Re:コンソールに起動時に触れるなら (スコア:1)
とはいえ、パスワードで制限かかってる状態を突破されるのは、さすがにちょっと不味いでしょう。
# カジュアル、の範疇で
M-FalconSky (暑いか寒い)
認証無しでシェルを起動しちゃダメ (スコア:0)
> さらにマウント処理を一定回数(x86システムの場合30回)失敗するとroot権限でシェルが起動するようになっているそうだ。
タイトルオンリー
Re: (スコア:0)
むかーしは、linux singleってつけてシングルユーザでブートすると、すんなりrootになれちゃうものだったよね。今はパスワード必須になっているけど。同じようにしたらいいんじゃない?
Re: (スコア:0)
init=/bin/sh で同じような事いまでも出来るし…
久しぶりに (スコア:0)
ハードの不調があったので
数年ぶりにUbuntuクリーンインストールしたら
HDD暗号化の選択肢があったので試しに使ってみたのだが
影響なさそうだな
Re: (スコア:0)
たしか、LVMでディスクまるごと暗号化したうえで分割するほうが
パーティションごと(ファイルシステムごと)に暗号化するよりも
パフォーマンスが高いような実験記事を見た記憶もありますよ…
まぁ、暗号化使っていないんですけどね…
LVMは理解するコストに見合う利益を感じない。
個人の趣味PCでのことだし…
何の脆弱性だって? (スコア:0)
> cryptsetupというツールに脆弱性が確認された
cryptsetupを使う側がおかしいという話じゃないかと思うんだけど。
クソみたいなダサい脆弱性を (スコア:0)
必死でたいしたことない風に振舞おうとする信者たち。
Re: (スコア:0)
確かに、ダサい脆弱性ではあると思うけど
実際に影響を受けるようなシーンが思いつかない。
サーバだと起動中のコンソールにアクセスされる状況自体が
いまいち理解できないし、クライアントなら物理的にアクセスできている時点で
インストールディスク入れたほうが早い
この脆弱性が「大した事」である根拠は何?
Re: (スコア:0)
起動中のコンピュータへの物理アクセス、はそもそも思いっきり弱点だからな。
トムクルーズなんかも、毎度、物理アクセスを得るところを凄く頑張ってるだろ。
うーん (スコア:0)
ちと酷いバグだと思うが、他にも気になるとこ。
>マウントできなかったデバイスについてマウント処理を繰り返す
デバイスの完了通知来てからやれば?っていう発想自体無いのか。
デバイス開発系の人(無論unix系)居たけど「ポーリングみたいなムダ処理大嫌い」だったけどなあ。
Re: (スコア:0)
linusがムダだと…
Re: (スコア:0)
みんなそう思ってるがデバイスを信用できねえのが事の全てなんだよ