Dellのファームウェア更新プログラムに同梱されていたドライバーに脆弱性、500以上のモデルに影響 23
対策はお早めに 部門より
Dellは4日、ファームウェア(BIOS/Thunderbolt/TPM/ドッキングステーション)更新プログラムに同梱されていたドライバーに不十分なアクセス制御の脆弱性(CVE-2021-21551)が存在することを公表した(DSA-2021-088、 FAQ、 SentinelLabsの記事)。
問題のドライバー「dbutil_2_3.sys」はファームウェア更新プログラムまたはDellのアップデートツールにより、一時フォルダー(%temp%または%windir%\temp)に展開されるもので、権限を確認せずにIOCTLリクエストを受け付けてしまうという。この脆弱性を悪用することで、ローカルでの権限昇格やサービス拒否、意図しない情報開示が行われる可能性がある。
このドライバーは遅くとも2009年からPCやドッキングステーションのファームウェア更新プログラムで使われており、影響を受けるモデルは現在もサービスが行われている381モデルに加え、既にサービスが終了している195モデルと幅広い。SentinelLabsによれば、影響を受けるPCは数億台に上るという。381モデルの最新ファームウェア更新プログラムでは脆弱性が修正されているが、dbutil_2_3.sys自体は削除されないようだ。なお、ドライバーサービス「DBUtil_2_3」のレジストリ設定は最初のWindows再起動時に削除されるため、実際にどの程度影響があるのかは不明だ。
対処方法としては「Dell Security Advisory Update - DSA-2021-088」を実行または手作業でdbutil_2_3.sysを削除し、現在もサービスが行われているモデルでは再導入を防ぐために最新のファームウェアをインストールする。サービスの終了しているモデルではファームウェア更新プログラムを実行するたびにdbutil_2_3.sysの削除が必要になる。
この先も同様の報告が増えそう (スコア:3, 興味深い)
一時ファイルを共有ディレクトリに作成しない [jpcert.or.jp]という基本的な話ですね。
複数のバックアップソフトウェアの脆弱性について
https://www.jpcert.or.jp/newsflash/2020122501.html [jpcert.or.jp]
JVNVU#92838794: Atlassian 製 Bitbucket にインストールディレクトリの ACL 設定不備による権限昇格の脆弱性
https://jvn.jp/vu/JVNVU92838794/index.html [jvn.jp]
昨年秋頃からこの手の脆弱性報告が増えてるので、重点的に報告してるリサーチャーがいるんだと思う。
脆弱性が増えたのではなく、昔からある脆弱性に着目する「眼」の方が増えたパターン。
探そうと思えば無限に見つかる。
Re: (スコア:0)
/tmpで始まる名前をPOSIX Local IPCソケット(いわゆるUNIXドメインソケット)では安全に使えるけど実体が存在する一時ファイルでは安全に使えないのはどうして?
Re: (スコア:0)
例えば、ブラウザでcontent-disposition:attachmentがついてるファイルをブラウザで表示しようとすると、%TEMP%行きになると思うんだけど、これはダメってこと？
Firefoxとかだと、同じ名前のファイル(aaa.bbb)があれば、添え字(aaa-1.bbb)をつけて一意性は確保してるみたいだけど。
Re: (スコア:0)
権限昇格の脆弱性になる場合はダメってこと
Re: (スコア:0)
いまだに%TEMP%を使うブラウザーはIEとFirefoxくらいじゃね? macOSではだいぶ前から(Firefoxも)ダウンロードフォルダー直行だしChromeもダウンロードフォルダー直行
Re: (スコア:0)
究極的にはサンドボックス化が必要なんですよね。利便性とトレードオフですけど。
Re: (スコア:0)
「サンドボックス内のBIOSを更新するだけで実環境のBIOSには影響与えません!」 意味ねーじゃん。なんでもサンドボックス言って思考停止してればいいってもんじゃねーぞ。
OS上からファームウェア更新できるのが悪い (スコア:0)
BIOS画面から、MBに接続されたキーボード・マウスで対話的にファームウェア更新ならわかるが、
OS上からファームウェア更新とか、ちょっと怖いな
OS上からのファームウェア更新は、BIOS設定とかで無効にできるようにしてほしいわ
Re:OS上からファームウェア更新できるのが悪い (スコア:2)
OS上からのファームウェア更新はMSが推し進めてるからなぁ。
今はまだ(OEMに)強制されてないけど。
ファームウェア更新は関係ない (スコア:0)
勘違いしてますよ。ファーム更新は関係ありません。
ドライバーに脆弱性があって、ドライバーがインストールされるだけで影響を受けます。
そのドライバーがファームウェア更新プログラムやその他のツールに同梱されていただけです。
ですから
> OS上からのファームウェア更新は、BIOS設定とかで無効にできるようにしてほしいわ
こんなことしても何の対策にもなりません。
手元にDellマシンが無いので確認できませんが
DellのBIOS設定には無効・有効のオプションがあったような気がします。
でも仮に無効にできたとしても、今回の脆弱性の対策にはなりません。
Re: (スコア:0)
OS上からできるというかOSが勝手にやるようにしないとファームウェアの脆弱性がいつまでも残り続けるのだが。
Re: (スコア:0)
MS-DOSの時代から、BIOSの更新ってのはOSの上からやるものですよ。
BIOSの中から、更新する機能が出てきたのって、BIOSのメニューが高度化したあと、かなり最近の話だよ。(いつからか最近かは年齢によるけど)
Re: (スコア:0)
> (いつからか最近かは年齢によるけど)
前段でMS-DOSの知識を前提にしてるのにそんな予防線張らなくても
Re: (スコア:0)
実際問題、pflash.exe叩くのは一応MS-DOS上からだけど、MSDOS.SYSとIO.SYSだけの最小環境だからBIOS上と大差ないよねえ。
config.sysにゴチャゴチャ書いた運用環境でフラッシュするわけではない。
Re: (スコア:0)
DOSと違ってやってる事が多い今どきのOS上って不安ですね…
BIOS更新と同時になんかのソフトウェアインストール&再起動、アンチウイルスフルスキャンとかやったらどうなるんでしょうね？
Re: (スコア:0)
MS-DOSの時代にBIOSの更新はEPROM焼きなおして差し替えていたことがある。いや、メーカー製PCじゃないけどさ。
Re: (スコア:0)
そもそもMS-DOS時代のBIOSはマスクROMで、物理的に書き換え不可能だったような。 パソコン創世記によるとPC-9801の初期モデルはあえてEPROMを採用したようだがそれでもソフトウェアから消去できるようにはなってなかったと思うし。MS-DOSの時代にOSからBIOS更新してたって本当? 記憶を捏造してない?
Re: (スコア:0)
今みたいにコマンドで消去できるROMはなかったんじゃないかね
Re: (スコア:0)
DOS/V機時代のマザーを単品買いできる頃には更新できた記憶がある
Re: (スコア:0)
検索するといわゆるDOS/V機だと486時代にはEEPROMによるBIOS更新が行われていたようですね。
その辺の機種でAMDやCyrixの互換CPU対応BIOS更新アップデートやったような記憶もあります。
その辺国産機はずっと遅かったようですが（というか使ってた頃にBIOS更新した記憶がない）
Windows時代になってもBIOS更新はFDDでDOS起動してから、ってのが定番でしたし。
今使ってるのがDellのPCでBIOS更新したことあるけど (スコア:0)
dbutil_2_3.sysは見当たらないな。どういう条件で残るんだろう
Re: (スコア:0)
同じく、dutil_2_3.sysは見当たらんかった。
Re: (スコア:0)
うちの親のにはあったよ。Windows\Tempに。
手で削除して念の為おすすめというDSA云々を当てたら単にdbutil_2.3.sysを削除するだけのツールだった。