2週間前のlog4j2の問題の熱が冷めないうちに、今度は apache httpd の脆弱性発覚。
今回は、
CVE-2021-44224 CVSS v3=8.2 HIGH
CVE-2021-44790 CVSS v3=9.8 CRITICAL
の２件である。
これらは、12/20にはThe Apache Software Foundationから出ていた情報で、まあ関係ないかな？と思ってスルーしていたけれど、よく見たら２番目はちょっとだけ影響あった（いや、実質は影響ないのかも）ので対処することにした。
https://httpd.apache.org/security/vulnerabilities_24.html
改めて、今回の脆弱性、２点を見てみよう。
●CVE-2021-44224 CVSS=8.2 HIGH
フォワードプロキシ(ProxyRequests On)として設定されているhttpdに、細工されたURIを送ることによりHTTPDをクラッシュさせることが可能。
自分が関係しそうなのはRHEL7（CentOS7）なのだけれど、以下のRedhatのページを見ると「影響を受けません」とある。影響を受ける8用のパッチは、現時点ではなし、と。
でも自分の場合、そもそも、フォワードプロキシはつかってないから、セーフ。
https://access.redhat.com/security/cve/cve-2021-44224
こちらは、パッチが出たら、適用しよう。
●CVE-2021-44790 CVSS=9.8 CRITICAL
細工したマルチパートコンテキストのリクエストをmod_luaで処理する際に、バッファーオーバーフローを発生させることができる。
なので、実行可能な.luaファイルがサーバー上にある場合、そこへ向けて細工したリクエストを送信すると、バッファーオーバーフローを契機に、任意のプログラムの実行や、管理者権限の奪取ができてしまうということか。
Redhatのサイトを見ると、現時点ではパッチはなく、mod_luaを無効にせよとのこと。
https://access.redhat.com/security/cve/cve-2021-44790
っていうか、luaなんて知らない。
mod_luaは、phpやCGIのように、.luaで実行できる組み込み用のスクリプト言語らしい。
使っていないので、無効にしても問題なし。
それに、.luaファイルは、DocumentRoot下には、ないハズ。
ほかの脆弱性との組み合わせで.luaをアップできない限り、問題はないのだが、RHEL7では、パッケージでhttpdをインストールすると、mod_luaはデフォルトでONのようなので、対処しておくことにする。
パッチはまだないので、
/etc/httpd/conf.modules.d/00-lua.conf の
LoadModule lua_module modules/mod_lua.so
を
#LoadModule lua_module modules/mod_lua.so
に修正して、HTTPDを再起動。
以上で対処は終了。
編集後記。
この類の情報が出てくるたびに、これは自分に関係のあることなのか、関係ないことなのか、チェックしなくてはいけなくて、結構、たいへん。
それに、今回の情報の一次ソースは Apache Software Foundation からの「Fixed in Apache HTTP Server 2.4.52」なんだけれど、httpdをソースからは入れてないから、アップデートが出たからと言って、んーーという感じ。
自分がどんなサービスやプロダクト、ライブラリーを使っているかを押さえておくことはもちろん、提供される情報が何を言っているのかを理解して、自分への影響の有無をチェックすることは、結構しんどい作業です。
log4j2の時は、javaは使っていないから平気と思っていたら、UPSの管理ソフト（APC）が影響をうけるとか。そんなの知らんし。
でも、放置しておくと、後で大変なことになるかもしれないので、今後も、きちんと調べて対応しよう。
日々精進。
ぐっどらっこ。
いつもお世話になっている、さくらインターネット様より、以下のメールが来ました。
────────────────────────────────────
・システム管理者様以外がお受け取りになった際は転送いただけますと幸いです。
────────────────────────────────────
会員ID ：xxxxxx
ご契約者：●● ●● 様
サービス：●●.sakura.ne.jp
MySQL5.7へのアップデートについて
平素より弊社サービスをご利用いただきありがとうございます。
さくらインターネットカスタマーセンターです。
さくらのレンタルサーバでご利用中のMySQL5.5、5.1データベースのMySQL5.7へ
アップデートのお願いとなります。
ほー、そうですか。
本ブログのサーバーでは、MovableTypeにMySQL5.5のデータベースを使っていました。
さっそく、アップグレードを行ってみましたが、超簡単でした。
さくらさんが用意してくれたアップグレードツールを使ってアップグレードを行う手順は、次のとおりです。
DBのダンプを取って（エクスポート）、5.7にDBを作って、インポートするといった、手動操作でも移行は可能です。
１．さくらのコンパネにログインし、「Webサイト/データ」→「データベース」から「アップグレード設定」をクリックし、アップグレードを予約します。
予約時のポイントは以下です。
・さくらさんがアップグレードを行ってくれた直後に、以下のDB変更に伴う作業が行えるタイミングで予約する。（なるべく）
・複数DBがある場合は、全DBが変換対象になる。（これだけという選択はできない）
・アップグレート操作は1度だけしかできない。
・5.7内に、同じDB名がすでに存在しないこと。存在する場合は、DB名を変更して予約する。
・変換後のDBのパスワードは、以前のものが引き継がれる。
２．スケジュールした変換が完了すると、さくらさんから「データベースアップグレード 完了のお知らせ」というメールが来ます。
３．mt-config.cgiの
Database xxxx ← 予約時に変更した場合はそれに。
DBUser xxxx ← 変更不要。
DBPassword xxxx ← 変更不要。
DBHost xxxx ← 必ず変更する。
BDHostについては、「Webサイト/データ」→「データベース」の5.7のセクションに新しいDBサーバー名が表示されていますので、それを指定します。
mysql57.xxxxxxxxxxxx.sakura.ne.jp でも、mysqlxxxx.db.sakura.ne.jp、どちらでもOKです。
を修正してサーバーへアップ後、MTの管理画面にログインできるかどうか確認してください。
４．これが肝なのですが、旧データベースを残しておくと、さくらから「 【ご対応ください】 MySQL5.7 へのアップデートについて」という件名のメールが何度も来ます。
動作確認後、問題がなければ、旧データベースは削除しましょう。
ぐっどらっこ。
Windows10 21H2 のパソコンです。
ある日、突然、エクセル（だけじゃなく）へのキーボードのテンキーからの数字入力が全角の数字となってしまいました。
これまでは半角で入力できていたのに。
以下を確認・設定してみてください。
１．[スタート] → [設定] （歯車アイコン） → [時刻と言語] → [言語] を選択します。
２．[A字 日本語] をクリックし、表示される [オプション] を選択します。
３．下の方にある [Microsoft IME] をクリックし、表示される [オプション] を選択します。
４．[全般] をクリックし、「テンキー」で「常に半角」を選択します。
５．最後に、設定画面を右肩の☓をクリックでで閉じます
ぐっどらっこ。
zoomのウェビナーは、何人かのパネリストとたくさんの視聴者が参加するセミナーやカンファレンス、フォーラムには最適なソリューションです。
使うためには、有料の「ミーティング」と、「ビデオウェビナー」の両方のライセンスが必要です。
最も安い月契約のプランは、ミーティングプロ 2000円＋ビデオウェビナー 10700円で、最大500人のウェビナーが可能です。（2021年12月現在）
さて、そんな便利なウェビナーですが、パネリストがビデオを開始しようとビデオアイコンをクリックした時、「ホストがビデオを停止したため、ビデオを開始できません」と表示される場合があります。
このようになる理由の多くは、ウェビナー中に、ホストによりその参加者のビデオが停止された（ホストの画面の参加者リストから、その参加者の「...」をクリックし「ビデオをオフにする」が選択された）ことによります。
通常は、そのパネリストの「詳細」をクリックすると下図のようなメニューが表示されるので、「ビデオの開始を依頼」を選択すればよいです。
ところが、下図のように、その項目が表示されない場合があります。
原因はいくつか考えられるのですが、スケジュール作成時の設定によって発生する場合があります。
以下の図にある「ビデオ」セクションの「パネリスト」をオフにした場合です。
スケジュール作成時に、この部分を「オフ」にしてしまうと、スケジュール開始後は変更ができず、そのウェビナー開催中は、パネリストはビデオ配信ができません。パネリストがビデオ配信を行う可能性がある場合は、必ず「オン」にしましょう。
さて、解決策ですが、スケジュールを作りなおすという方法もありますが、その場合、事前に配布したウェビナーのURLが変わってしまい、URLを通知しなおす必要が出てきます。
実行中のウェビナーを継続したままの解決策としては、そのパネリストを「共同ホスト」にすることです。（共同ホストにするには、上から2番目の図の「共同ホストを作成」を選択する。共同ホスト数に上限なし。）
共同ホストにすることで、ホストだけが可能な操作もできてしまうようになってしまうので注意が必要ですが、どうしてもビデオ配信を行いたい場合は、この方法をとってください。
なお、パネリストを共同ホストにするためには、ZOOMのウェブサイトに、ホストで使用しているアカウントでログインして、「設定」→「共同ホスト」をONにしておく必要があります。設定後、パネリストに退室→再入室をしてもらうと、ホストがパネリストを「共同ホスト」に指定できるようになります。
ぐっどらっこ。