php imagecreatefrom* 一連の関数 png

0x00 はじめに

この記事では主に、GD ライブラリの imagecreatefrompng() 関数を使用して PNG イメージを再構築する PHP によって引き起こされる可能性のあるローカル ファイル インクルードの脆弱性を分析します。

システムにファイル インクルード ポイントがある場合、画像ファイルを含めることができます。さらに、システムには画像のアップロード機能があり、アップロードされた画像は imagecreatefrompng() 関数を使用して画像を再構築し、ローカルに保存すると、ファイル インクルードの脆弱性が発生します。が発生する可能性があります。

通常、システムが画像アップロード機能を実装する場合、ユーザーが悪意のある PHP コードを含む画像をアップロードするのを防ぐために、gd ライブラリを使用して画像を再構築します。gd ライブラリは一連の関数 imagecreatefrom* を使用して画像を再構築します。これは、イメージの仕様をチェックし、イメージの正当性を検証して、イメージに悪意のある php コードを含む攻撃に対抗します。

では、imagecreatefrom* 一連の関数は、画像に PHP コードを挿入する攻撃に完全に抵抗できるでしょうか? この記事では、imagecreatefrompng() 関数を研究対象として使用し、悪意のある PHP コードを含む PNG 形式の画像を再構築する可能性を調査します。必要な条件は満たされています。

png ファイル形式、imagecreatefrompng 関数の分析、画像の変更、アップロード、ファイルに含まれるもの...

0x01 png 画像形式

再構築された png 画像に依然として悪意のある php コードが含まれていることを理解するには、まず png 画像を理解する必要があります形式 基本的な理解。 png は、インデックス カラー イメージ、グレースケール イメージ、トゥルー カラー イメージの 3 つのイメージ タイプをサポートします。インデックス カラー イメージはパレット ベースのイメージ (パレット ベースのイメージ) とも呼ばれます。

標準の PNG ファイル構造は、次のような複数の PNG データ ブロックを接続する PNG 識別子で構成されます。ヘッダーは次のような固定 8 バイトです。

89 50 4E 47 OD 0A 1A 0A

png データ ブロック

png は 2 種類のデータ ブロックを定義します。1 つはクリティカル チャンクと呼ばれる標準データ ブロックで、もう 1 つは補助データ チャンク (補助チャンク) と呼ばれるオプションのデータです。塊。キー データ ブロックは、すべての PNG ファイルに含める必要がある 3 つの標準データ ブロックを定義します。 3 つの標準データ ブロックは次のとおりです: IHDR、IDAT、IEND

以下に 4 つのデータ ブロックがあります: IHDR、PLTE、IDAT、IEND

png データ ブロックの構造

png ファイルでは、各データ ブロックは 4 つの部分の長さ | で構成されます。 type(name) | data | CRC、次のように説明されます

length: 4 bytes， just length of the data, not include type and CRC  type: 4 bytes, ASCII letters([A-Z,a-z])CRC: 4bytes

CRC (巡回冗長検査) フィールドの値は、Chunk Type Code フィールドと Chunk Data フィールドのデータから計算されます。特定の CRC アルゴリズムは ISO 3309 および ITU-T V.42 で定義されており、その値は次の CRC コード生成多項式に従って計算されます: x 32 +x 26 +x 23 +x 22 +x 16 +x 12 +x 11。 +x 10 +x 8 +x 7 +x 5 +x 4 +x 2 +x+1

IHDR

ファイルヘッダーデータブロック IHDR (header chunk): に格納されている画像データの基本情報が含まれますPNG ファイル 。PNG データ ストリームの最初のデータ ブロックとして出現する必要があり、PNG データ ストリーム内に存在できるファイル ヘッダー データ ブロックは 1 つだけです。
ファイルヘッダーデータブロックは13バイトで構成されており、次のとおりです

フィールドの名前

バイト数4バイト高さ4バイトピクセル単位の画像の高さビット深さ1バイト画像の深さ インデックス付きカラー画像: 1、2、4、または8 グレースケール画像: 1、2、4、8、または16トゥルー カラー イメージ: 8 または 16 ColorType1 バイト ColorType.0: グレースケール イメージ、1、2、4、8 または 162: トゥルー カラー イメージ、8 または 163: インデックス付きカラー イメージ、1、2 、4 または 84: アルファ チャネル データを含むグレースケール画像、8 または 166: アルファ チャネル データを含むトゥルー カラー画像、8 または 16 Filter 方式1 byteFilter 方式Interlace 方式1 byteInterlace 方式.0: ノンインターレース 1: Adam7 M. Costello によって開発された Adam 7 パス インターレース方式)

• PLTE

パレット データ ブロック PLTE (パレット チャンク) には、インデックス カラー イメージ (インデックス カラー イメージ) に関連する色変換データが含まれています。インデックス カラー イメージにのみ関連しており、イメージ内に配置する必要があります。データブロック（画像データチャンク）の前。

PLTE データ ブロックは、画像を定義するパレット情報であり、1 ～ 256 のパレット情報を含めることができます。各パレット情報は、

説明		幅
画像の幅（ピクセル単位）

Color byte 意味Red1 で構成されます。バイト0 = 黒、255 = 赤緑1 バイト0 = 黒、255 = 緑青1 バイト0 = 黒、255 = 青

因此，调色板的长度应该是3的倍数，否则，这将是一个非法的调色板。 颜色数 = length/3

对于索引图像，调色板信息是必须的，调色板的颜色索引从0开始编号，然后是1、2……，调色板的颜色数不能超过色深中规定的颜色数（如图像色深为4的时候，调色板中的颜色数不可以超过2^4=16），否则，这将导致PNG图像不合法。

• IDAT

图像数据块IDAT(image data chunk)：它存储实际的数据，在数据流中可包含多个连续顺序的图像数据块。IDAT存放着图像真正的数据信息

• IEND

图像结束数据IEND(image trailer chunk)：它用来标记PNG文件或者数据流已经结束，并且必须要放在文件的尾部。

正常情况下， png 文件的结尾为如下12个字符：

00 00 00 00 49 45 4E 44 AE 42 60 82

由于数据块结构的定义，IEND数据块的长度总是0（00 00 00 00，除非人为加入信息），数据标识总是IEND（49 45 4E 44），因此，CRC码也总是AE 42 60 82

0x02 php imagecreatefrompng() 函数

有了对 png 图片格式的基本了解，可以帮助我们更好的理解 imagecreatefrompng() 函数的底层实现。分析 php 源码(php 5.6.20)可知， php imagecreatefrompng() 函数实现重建图片，核心是 gd 库的 gdImageCreateFromPngCtx() 函数。

分析 gd 库中的 gdImageCreateFromPngCtx() 函数可知，函数首先会检测 png signature, 不合法则返回NULL。然后会读原始的 png 图片文件给 png_ptr, 再从 png_ptr 中读图片信息到 info_ptr，再之后就是获取 IHDR 信息，读 IDAT 数据等，这里不一一讨论。这里仅讨论 png_read_info() 函数中对读 PLTE 数据库的验证处理。

#!cgd_png.c/gdImageCreateFromPngCtx{...if (png_sig_cmp(sig, 0, 8) != 0) { /* bad signature */        return NULL;        /* bad signature */}   ... png_set_read_fn (png_ptr, (void *) infile, gdPngReadData);png_read_info (png_ptr, info_ptr);  /* read all PNG info up to image data */...}

要了解 png_read_info() 的内部实现，可以通过读 libpng 的源码(libpng 1.6.21)进行了解。当图片类型是索引图像时，png_read_info() 读到 PLTE chunk 时会调用 png_handle_PLTE 函数进行 CRC 校验

#!cpngread.c/png_read_info{...else if (chunk_name == png_PLTE)         png_handle_PLTE(png_ptr, info_ptr, length);...}   pngrutil.c/png_handle_PLTE {...#ifndef PNG_READ_OPT_PLTE_SUPPORTED   if (png_ptr->color_type == PNG_COLOR_TYPE_PALETTE)#endif   {      png_crc_finish(png_ptr, (int) length - num * 3);   }...}

分析底层源码可知， png signature 是不可能插入 php 代码的； IHDR 存储的是 png 的图片信息，有固定的长度和格式，程序会提取图片信息数据进行验证，很难插入 php 代码；而 PLTE 主要进行了 CRC 校验和颜色数合法性校验等简单的校验，那么很可能在 data 域插入 php 代码。

从对 PLTE chunk 验证的分析可知， 当原始图片格式给索引图片时，PLTE 数据块在满足 png 格式规范的情况下，程序还会进行 CRC 校验。因此，要将 PHP 代码写入 PLTE 数据块，不仅要修改 data 域的内容为php代码，然后修改 CRC 为正确的 CRC 校验值，当要填充的代码过长时，可以改变 length 域的数值，满足 length 为3的倍数， 且颜色数不超过色深中规定的颜色数。例如: IHDR 数据块中 Bit depth 为 08, 则最大的颜色数为 2^8=256, 那么 PLTE 数据块 data 的长度不超过 3*256=0x300。 这个长度对写入 php 一句话木马或者创建后门文件足够了。

那么是不是所有 png 图片都可以在 PLTE 数据块插入 php 代码呢？下面通过实验予以说明。

0x03 实验验证

png 支持索引彩色图像(index-color images)，灰度图像(grayscale images)，真彩色图像(true-color images)三种类型的图片，而 PLTE 数据块是索引图像所必须的，因此索引图像极有可能在 PLTE 数据块插入 php 代码。

下面摘录 gd 库中 gdImageCreateFromPng() 函数的一段说明

If the PNG image being loaded is a truecolor image, the resultinggdImagePtr will refer to a truecolor image. If the PNG image beingloaded is a palette or grayscale image, the resulting gdImagePtrwill refer to a palette image.

函数将索引彩色图像和灰度图像转换为索引彩色图像， 将真彩色图像转换为真彩色图像。下面分别转换这三种类型的图片，测试图片地址: 图片 . php代码如下

#!php<?php$pngfile = 'test.png';$newpngfile = 'new.png';$im = imagecreatefrompng($pngfile);imagepng($im,$newpngfile);?>

• 索引图像

读 IHDR 数据块信息，色深为8bits, color type=0x03, 为索引图像类型，改变其 PLTE 数据块如下，修改数据为 1c54a2ccadef45a7573e3649bdfd6f57

计算 CRC 过程如下

imagecreatefrompng() 重建的图片如下

可以看出重建的图片中 PLTE 数据块保留了 php 代码，重建也增加了 pHYs 数据块，对我们所关心的结果并没有影响。说明插入 php 代码成功。

• 灰度图像

原始图像， 不含 PLTE 数据块， 如下所示

插入 PLTE 数据块，并写入 php 代码

重建后的图片如下

可以看出重建的图片转换为 索引图像类型，并且重写了 PLTE 数据块，写入 php 代码失败

• 真彩色图像

原始图像， 不含 PLTE 数据块， 如下所示

PLTEデータブロックを挿入し、phpコードを記述します

再構成された画像は次のとおりです

トゥルーカラータイプ画像の再構成画像には、PLTEデータブロックと書き込みが含まれていないことがわかりますphp コードが失敗しました

0x04 概要

上記の分析と実験を通じて、画像タイプがインデックス画像である場合、imagecreatefrompng() 関数は画像への php コードの挿入を完全に防ぐことができないことがわかります。コードは PLTE チャンクに正常に挿入できますが、他のタイプのイメージは PLTE コードをチャンクに挿入できません。最後に、私の研究に協力していただいた以下の参考文献に感謝いたします。

添付のインデックス画像を変更して、php コード アドレス github を挿入します

添付のコードは、ペイロードの長さが PLTE データ長よりも大きい場合、PLTE データ ブロックが書き換えられることを認識しています。ただし、実験中に、imagecreatepng() 関数によって再構成された画像 PLTE データ ブロックの長さは依然として元の長さである、つまり、PLTE データ ブロックの長さを自由に拡張できないことが判明しました。ソース コードの詳細な分析が必要です。つまり、ロードされるペイロードの長さは、PLTE データ ブロックで指定された長さを超えることはできません。

通常、PLTE データ ブロックで指定される長さは、基本的な PHP バックドア コードを挿入するのに十分です。このような時点で、地球を動かすことは可能でしょうか?

もちろん、この記事にはまだ多くの欠点があります。皆さん 批判と修正

0x05 リファレンス

1. github libgd

2. gd2.0.33 マニュアル

3. libgd home

4. png book

5. png chunk

6 .png ファイル形式の分析