xz-utils のバックドア問題
XZ形式の圧縮ファイル生成/解凍の xz-utils にバックドアが仕掛けられるというトラブルが報告されている。オープンソースで開発されているソフトで、誰かがソースコード中に悪意のあるコードを仕込んだらしい。このため、ソースでビルドされたパッケージにも影響する。xz-utils の 5.6.0, 5.6.1 が該当し、Debian でも testing / trixie などでインストールされる。
xz-utilsの確認とダウングレード Debian/trixie
確認すると、しっかりインストールされていた。
$ dpkg -l | grep xz-utils ii xz-utils 5.6.1+really5.4.5-1 amd64 XZ-format compression utilities
さすがに怖いので、安全なバージョンが出るまでダウングレードだな。
$ sudo apt install xz-utils/stable $ sudo aptitude hold xz-utils
Ubuntu 2.2 LTSは大丈夫
dpkg -l | grep xz-utils ii xz-utils 5.2.5-2ubuntu1 amd64 XZ-format compression utilities $ cat /etc/os-release PRETTY_NAME="Ubuntu 22.04.4 LTS" :
具体的な情報を探すと 「vulnerableなxzがインストールされている状態で xz –version を実行するとバックドアが開いてしまうので実行するなという話だそう。」という情報があるし、インストールされているとはいえ自分自身で活用していないので “xz –version” は実行していない。というか、この記事を遡ると Debian の 5.6.1+really5.4.5-1 は、5.4.5 に戻されていて大丈夫みたいだな。ということで改めて、apt install xz-utils で、5.6.1+really5.4.5-1 が入った。5.6.1 の様に見えるけど、実は 5.4.5 。
wordpressでWP_SITEURL,WP_HOMEでプロトコル指定を省略できないか?
ケーブルテレビのSTBのブラウザで、自宅サーバに接続させようとすると接続が拒否られる。letsencryptのroot証明を受け付けてくれないのが原因。一部の動作確認ページをブラウザから接続させたいと思うけど、自宅サーバはWordPressなのでhttpsで WP_HOME, WP_SITEURL がしてあるために、強制的に https になってしまう。
試しに、wp-config.php で “https://hostname” でなく、”//hostname” とか “/” を指定してみた。
“/” だと、ページが上手く表示されない。(cssなどがうまく読み込めていない様子)
“//hostname” だと、ページは表示できるけど、wp-login.php でのログインが上手くいかない。(多要素認証のプラグインが影響しているのかもしれない)
TZ-HT3500 で radiko が使えない
丹南ケーブル(こしの都ネットワーク)の STB で TZ-HT3500 録る蔵くん を使ってるけど、FMラジオのネット版 radiko が使えない状態になっている。(私は使ってないけど…)
https://t-catv.co.jp/inq/tech/ にて:
「STB で TZ-HT3500 録る蔵くん を使っていますが、radiko に接続できない状態となっています。STB で radiko 対応のサポート終了など発生していますでしょうか?」の質問を投げておいた
以前も 一時的に Prime Video が使えないというトラブルがあったけど、サーバ側の対応や設備対応で復旧したけど。ひとまず連絡だけ入れておくか。
(追記)
早々に丹南ケーブルさんから電話連絡がありました。特に全体的にトラブルは発生していないとのことで、ネットワークの設定を見直してくれとの返事だった。うーむ、ネットワークの設定といっても、普通に Netflix とかは使えてるしなぁ….。
でも改めて考えると、うちの家だけのトラブルというのであれば….
あ、もしかして Proxy サーバのせい?
自宅サーバで Web Proxy を動かしていて、そこに接続させていたけど、その設定を外したら、無事につながった。丹南ケーブルさんごめんなさい。
Proxyを試した理由
自宅Webサーバ(https)に、STB のブラウザ機能でつなごうとすると、letsencrypt の root 証明を受け付けていないので、ページが見れないのよね。あとで、httpsを強制httpに変換させようかとproxy設定したのが敗因だった。(WPでhttpsにリダイレクトされるし…)