ちょうど昨日、Google Pixel フォンのバグについて書いたようです。 今パッチを適用、潜在的に危険な結果を伴います。

バグ発見者は、当然のことながら発見したことに興奮 (そして懸念) し、BWAIN 原則に最大限従うことを決定しました。 印象的な名前のバグ: アクロパリプス.

ご参考までに、アポカリプスという言葉は、文字通りあらゆる種類の啓示を意味しますが、通常、聖書のテキストとして知られる聖書のテキストを指すために使用されます 聖ヨハネの啓示、世界の終わりを描いています。

したがって、その比喩的な意味は、ニュ​​ー オックスフォード アメリカ辞典の言葉では、「驚異的または壊滅的な規模での破壊または損害を伴う出来事」です。

このバグがそのような終末論的な名前に値するとは確信していませんが、素晴らしいという言葉が「かなり良い」を意味する世界では、完全に例外的ではないにしても、おそらく受け入れられる名前であることは認めます.

「aCropalypse」の「Crop」

名前の「クロップ」の部分は、バグを引き起こす可能性が最も高いアクティビティに由来します。 CVE-2023-20136 Google の化身: 写真やスクリーンショットをトリミングして、共有する前に機密または不要な部分を削除します。

大まかに言えば、携帯電話の画面全体の 1080 x 1980 のスクリーンショットを撮った場合、画像全体をオンラインに投稿したり、友人にすべて送信したりしたくないと想像できます。

ほとんどの人は、少なくともスクリーンショットの上部を切り取り、モバイル プロバイダーの名前、日付、時刻などの詳細を削除することを好みます。

たとえば、メールやソーシャル メディアの投稿をリストの途中でスナップする場合、関心のある部分のすぐ上またはすぐ下に表示されるメールや投稿を隠したいと思うことはほぼ間違いありません。

画像をトリミングした後でも、送信者の名前、電子メール アドレス、電話番号などの上に黒いボックスをドロップするなどして、その一部を編集することもできます (ドキュメントの一部を覆い隠す、または検閲することを意味する専門用語)。 .

いずれにせよ、元の画像のチャンクを切り取り、無地のブロック (通常の画像データよりもはるかに簡単に圧縮できます) で詳細を覆い隠し、新しい画像を古い画像の上に保存したと仮定するかもしれません…

…新しい画像は元の画像よりもほぼ確実に小さくなり、おそらくはるかに小さくなります。

あなたが残したすべてのもののために！

しかし、少なくとも 2023 年 XNUMX 月の Android セキュリティ アップデートまでは、Google Pixel スマートフォンではそうはいきませんでした。

上書きされたが切り捨てられていない

新しい小さいイメージ ファイルは古いイメージ ファイルの先頭に上書きされますが、ファイル サイズは同じままで、元のファイルの末尾にある冗長で不要なデータは元の場所に残ります。

そのファイルを他の人に送信し、その人が従来の画像表示ツールまたは編集ツールで開いた場合、彼らのソフトウェアは、次のようなデータ チャンクに到達するまでファイルを読み取ります。 ここで停止して、ファイル内の末尾のデータを無視できます。」

言い換えれば、不要なデータがファイルの末尾に残される原因となったコーディングの欠陥は、通常、明らかなエラーを引き起こさないため、バグが最近まで発見されなかった理由を説明していると思われます。

しかし、受信者が XNUMX 進エディタや狡猾に変更された画像エディタなど、より好奇心旺盛なソフトウェア ツールでファイルを開いた場合、元の画像の数バイトから膨大な量まで、公式の終了を過ぎてもそこに残っています。探索され、露出されるのを待っている画像マーカー。

ほとんどのスクリーンショットは PNG ファイルとして保存されます。 ポータブルネットワークグラフィックスとして一般に知られている圧縮アルゴリズムを使用して内部的に圧縮されます。 デフレート.

したがって、残ったデータは明らかにピクセルの行と列のようには見えず、圧縮されたデータ ストリームが破損していると見なし、通常は拒否する従来の解凍ツールで直接解凍することはできません。まったく開梱してみてください。

だけど デフレート 圧縮は通常、アルゴリズムの実行に必要なメモリの量を削減するために、入力データをブロックのシーケンスとして圧縮し、繰り返されるテキスト (最大 32 キロバイト、最大 258 バイトの長さの一致) の入力のみをさかのぼります。 .

これらの制限は、そのフォーマットが 1990s、メモリスペースが今日よりもはるかに貴重だったとき.

コンプレッサーを定期的に「再同期」することで、最初の数バイトが破損した場合でも、圧縮ファイル内のすべてが完全に失われるリスクを軽減できます。

大幅な再建が可能かもしれません

これは、圧縮された PNG 形式で保存された画像ファイルは、元の画像のかなりの部分が上書きされたり、他の方法で破壊されたりしても、多くの場合、実質的に再構築できることを意味します。

また、トリミングまたは編集されたファイルから再構築できる画像の断片について話している場合は…

…切り落とされるはずだった最後に残ったデータに、回復可能な画像部分が含まれる可能性が明らかにあります 画像から完全に削除しようとしていた部分が明らかになります!

画像が行ごとに保存されている場合 (したがって、画像の上部のデータがファイルの先頭に近く、下部が最後にある場合)、切り抜くことができます。ファイルの「公式」部分にある古い画像の下半分と、残りのデータで繰り返される下半分で構成される新しい画像になる可能性があります。切り落とされましたが、そうではありませんでした。

しかし、画像の下部をトリミングすると、新しいファイルの古い上部が「公式に」再エンコードされて先頭に上書きされ、トリミングされた画像の下半分が作成されます。 前と同じ場所に置き去りにされた、新しいファイルの非公式の最後にあり、攻撃者によって抽出されるのを待っています。

Windows 11も影響を受ける

ファイルが新しいバージョンに置き換えられたときにファイルが切り捨てられないというこの問題は、Windows 11 にも当てはまります。 切り取るツールでは、Google Pixel Markup アプリと同様に、保存先のファイルを正しくトリミングせずに画像をトリミングできます。

たとえば、GIMP で作成し、最小限のヘッダー セットで圧縮せずに保存した PNG ファイルを次に示します。

このファイルは 320×200 ピクセルの 8 ビット RGB データ (320 ピクセルあたり 200 バイト) であるため、ファイルの長さは 3×192,000×192,590 バイト (XNUMX) であり、さらに数百バイトのヘッダーとその他の限られたメタデータが含まれ、合計サイズは XNUMX バイトになります。 .

以下の 0 進ダンプの例では、データの長さが 20x04F192,590E バイトであり、XNUMX 進数で XNUMX であることがわかります。

次に、Snipping Tool で可能な限り小さくトリミングし (48×48 ピクセルが最小のようです)、それ自体の上に保存しましたが、「新しい」ファイルは圧縮されていない 320×200 ファイルと同じサイズになりました。

以下の 0 進ダンプでは、上部のピンクで強調表示された部分が、トリミングされたファイルに含まれるはずの全体であり、長さは 189xBD バイト、または XNUMX 進数で XNUMX です。

新しいデータは、 IEND 新しいファイルが終了する場所であるデータブロックですが、以前の残りのデータが続き、最終的には重複しているが冗長になっていることがわかります IEND ほとんどすべての画像データとともに、古いファイルから引き継がれたブロック:

私たちが使用したとき Save ボタンをクリックして新しいファイル名で書き出すと、圧縮された 48×48 ファイルは、実際にはわずか 189 バイトの長さで出力されました。

ファイル内のデータが、前の画像でピンク色で強調表示されている 189 バイトとどのように一致するかに注目してください。

したがって、バグは、ファイルを既存のファイル名に上書きして保存すると、最初に古いファイルが切り捨てられず、予想されるサイズの新しいファイルが作成されないことです。

簡単に言えば、トリミングされたファイルは 部分的に上書き、実際ではなく 置き換え.

前述のように、画像表示および編集プログラムは最初の XNUMX つ目まで読み込まれるため、これまで誰もこの欠陥に気付いていなかったと推測しています。 IEND タグ (上のスクリーンショットの右下隅に表示されます) を削除し、異常やエラーを報告することなく、最後に余分なものをすべて黙って無視します。

何をするか？

• Windows 11 ユーザーの場合。 Snipping Tool で作成されたトリミングされたファイルは常に新しいファイル名で保存してください。これにより、元のコンテンツが取り残されることはありません。
• あなたがプログラマーなら。 古いファイルを上書きして「新しい」ファイルを作成したすべての場所を見直して、書き換えのためにファイルを開いたときに、元のファイルを実際に切り捨てていることを確認します。 または、最初に真に新しいファイルに保存し (安全に生成された一意のファイル名を使用)、元のファイルを明示的に削除して新しいファイルの名前を変更することによってのみ、新しいファイルを作成します。

ところで、Microsoft ペイントをテストしましたが、私たちが見る限り、そのプログラムは以前のデータが残っていないトリミングされたファイルを作成します。 Save (既存のファイルを置き換える) または 名前を付けて保存 （新しいものを作成するため）。

自分でファイルを開くモードについて学ぶ

このコードをコンパイルして実行します。

Windows では、次を使用できます。 ミニマリストC、 私たち自身の 厳選されたビルド 無料の Tiny Cコンパイラ、開発システムがインストールされていない場合。

Visual Studio または Clang for Windows のサイズがそれぞれギガバイトであるのに比べて、完全なソース コードを含めて、サイズは 500 キロバイト (!) 未満です。

＃含む＃含むint main(void) { char* az = "ABCDEFGHIJLKMNOPQRSTUVWXYZ"; int fd; // AZ を含むファイルを作成します // Octal 0666 は「全員の読み取り/書き込み」を意味します // O_CREAT は必要に応じて作成することを意味します fd = open("blah1.txt",O_WRONLY+O_CREAT,0666); 書き込み (fd、az、26); 閉じる (fd); // AZ を含む別のファイルを作成します fd = open("blah2.txt",O_WRONLY+O_CREAT,0666); 書き込み (fd、az、26); 閉じる (fd); // O_TRUNC を設定せずに 10 バイトを書き込みます // 残りの 16 バイトはそのままにしておく必要があります fd = open("blah1.txt",O_WRONLY); 書き込み (fd、"----------",10); 閉じる (fd); // O_TRUNC を設定して *10 バイトを書き込みます // 残った古いデータは切り捨てます fd = open("blah2.txt",O_WRONLY+O_TRUNC); 書き込み (fd、"==========",10); 閉じる (fd); 0 を返します。 }

書き込み用に既存のファイルを開く場合の違いに注意してください (O_WRONLY) を設定した場合としない場合 O_TRUNC フラグ。

の内容を印刷します。 blah1.txt & blah2.txt テスト プログラムを実行した後:

C:UsersduckCROP> petcc64 -stdinc -stdlib test.c Tiny C Compiler - Copyright (C) 2001-2023 Fabrice Bellard 学習ツールとして使用するために Paul Ducklin が削除 バージョン petcc64-0.9.27 [0006] - 64 ビットを生成PE のみ -> t1.c -> c:/users/duck/tcc/petccinc/fcntl.h 。 . . . -> C:/Windows/system32/msvcrt.dll -> C:/Windows/system32/kernel32.dll -------------------------- ----- virt ファイルサイズセクション 1000 200 2a0 .text 2000 600 1cc .data 3000 800 18 .pdata -------------------------- ----- <- t1.exe (2560 バイト) C:UsersduckCROP> t1.exe C:UsersduckCROP>dir blah*.txt ドライブ C のボリュームにはラベルがありません。 ボリューム シリアル番号は C001-D00D です C:UsersduckCROP のディレクトリ 22/03/2023 07:20 pm 26 blah1.txt 22/03/2023 07:20 pm 10 blah2.txt 2 ファイル 36 バイト C:UsersduckCROP> タイプblah1.txt ----------KLMNOPQRSTUVWXYZ C:UsersduckCROP> タイプ blah2.txt ==========

• SEO を活用したコンテンツと PR 配信。 今日増幅されます。
• Platoblockchain。 Web3メタバースインテリジェンス。 知識の増幅。 こちらからアクセスしてください。
• 情報源： https://nakedsecurity.sophos.com/2023/03/22/windows-11-also-vulnerable-to-acropalypse-image-data-leakage/