特定のIOS XEデバイスでは、ワイヤレスアクセスポイントのフラッシュメモリ内のログが1日5MBずつ増加し、スペースがなくなるまで増殖する。
Ciscoの管理者たちは、最近の欠陥のあるソフトウェアアップデートが原因で発生した、200以上のCisco Systems IOS XEベースのワイヤレスアクセスポイント（AP）モデルにおけるフラッシュメモリオーバーフロー脆弱性に対応するパッチを急ぎ適用している。
問題が迅速に修正されない場合、APのメモリは非常に満杯になり、新しいソフトウェアアップデートがブロックされ、APが不安定になるか、場合によっては完全に機能しなくなる可能性がある。
問題のあるライブラリアップデートにより、影響を受けたアクセスポイントのフラッシュメモリ内の特定のログファイルが1日約5MBずつ増加する。Ciscoは今週の勧告で、長期間にわたってこれが利用可能なメモリスペースの「大部分」を消費する可能性があると述べている。
「APが影響を受けたソフトウェアを実行し続けるほど、スペース不足のためにソフトウェアダウンロードが失敗する可能性が高くなります」とその勧告は述べている。
Enderle Group のアナリストRob Enderleは、「バグのあるログ」はネットワーキングにおける一般的なテーマであると述べた。しかし彼は、「このケースは特に危険です。なぜなら、一度ブリックしたり、ブートループに入ったりすると、アクセスが極めて困難なハードウェアのフラッシュメモリの物理的制限を対象としているからです。ネットワーキングの世界では、これは高い影響度と中程度のレアリティを持つイベントです」と付け加えた。
彼は説明した。「ユニークな点はこれが生み出す矛盾です。バグを修正するには、ソフトウェアをアップグレードする必要があります。しかし、バグそのものが修正をダウンロードするための十分なスペースをデバイスから奪っています。管理者が長く待ちすぎると、デバイスは手動による物理的介入が必要になるか、永続的にブートループに陥る可能性があります」
SANS Institute の研究部長Johannes Ullrichは、この特定の問題は珍しいと述べたが、アクセスポイントのようなIoTデバイスのフラッシュメモリスペースが制限されており、時々満杯になる可能性があることを認めている。
「しかし」と彼は付け加えた。「より大きな問題があります。有能なベンダーの脆弱性管理プログラムは、パッチが期待通りに実際に適用されたかどうかの検証を常に含める必要があります。パッチが正しく適用されない理由はたくさんあり、これはパッチが失敗する可能性のある一つの方法に過ぎません」
インシデント対応企業DeepCove Cybersecurity のCTOKellman Meghuは、バグによる固定デバイスのメモリオーバーフローについて、「このベンダーに非常に不満を持つでしょう。私の経験では非常に珍しいことであり、ストレージコストが重要な要素だった昔の問題です。ベンダーは固定デバイスのストレージをクリーニングし管理できることを期待します。このデバイスがサポートされている場合、これはRMA（返却許可）または修正問題であり、ベンダーアクションの期待は即座/プロアクティブであるべきです」と述べた。
【関連コンテンツ：Cisco Webex SSOの脆弱性】
影響を受けるのは、IOS XEバージョン17.12.4、17.12.5、17.12.6、および17.12.6aを実行しているアクセスポイントです。これには、Cisco Catalyst 9130AXシリーズのAP、ならびにスタジアムアンテナ搭載の9130AXモデル、Catalyst 91361、91621、9163E、91641、9166D1、IW9167シリーズのAPおよびWi-Fi 6 Outdoor APが含まれます。
管理者が問題を解決する方法は2つあります。WLANPollerというCiscoツールをダウンロードして複数のAP全体で修正の実行を自動化するか、各デバイスで手動でshow bootコマンドを使用してブートパーティションを調査し、アップグレード用に十分なスペースがあるかどうかを確認します。必要なアクション詳細についてはCisco勧告に記載されています。
Ciscoは、APのステータスの必須事前チェックを予定されたメンテナンスウィンドウにできるだけ近い時点で実行すべきだと述べています。しかし、影響を受けたログファイルが毎日増加するため、Enderleは「AP障害まで待つのは確実に避けたい」とは述べた。
手動修正はAPあたり5～10分のアクティブな作業に加え、AP にアップグレード用のスペースがある場合は修正が適用されたことを確認するために追加15～20分のソーク時間がかかる可能性があります、と彼は注意した。しかし、APにスペース問題がある場合は、デバイスあたりの時間は約20～45分に跳ね上がる可能性があります。
APが失敗した場合、修正に1～2時間かかり、デバイスへの物理的アクセスが必要になると彼は付け加えた。
WLANPollerを使用すればプロセスがより速くなると彼は付け加えた。
Enderleは、管理者がフラッシュメモリがすでにアップグレードするには満杯であるAPを見つけた場合、リブートはときに一時バッファをクリアするか、手動転送のための小さなウィンドウを許可する可能性があると述べた。しかし、この特定のログバグでは、ファイルが永続的な場合、リブートでは不十分な可能性があります。管理者は大規模なプッシュを試みる前に、緊急クリーンアップスクリプトについてCiscoに問い合わせるべきだと彼は述べた。
結果として、Enderleは、欠陥のあるアップデートのプッシュはサプライチェーン整合性の問題だと述べた。CSOは彼らのチームに「ハードウェアのヘルスメトリクス（CPU、RAM、Flash）の監視を実施していますか、それとも「Up/Down」ステータスのみの監視ですか？」と質問すべきだと述べた。アップしているが利用可能なフラッシュメモリが0MBのAPは負債だと彼は述べた。
CSOはこの脆弱性を「重大な可用性リスク」として見るべきだと彼は付け加えた。「これはデータ漏洩ではありませんが、（自動更新の失敗またはブートループによる）サイト全体のWi-Fi停止の可能性はビジネス運用を停止させる可能性があります」と述べ、CSOはまた、「軽微なライブラリアップデート」であっても依然として7～14日間のラボ環境でテストされるポリシーを実施すべきだと付け加えた。「この1日5MBのログ増加は、本番環境の5,000台のAP群に展開される前にラボでキャッチされた可能性が高い」とEnderleは述べた。
この記事は元々NetworkWorldに掲載されました。
