パレット データ ブロック PLTE (パレット チャンク) には、インデックス カラー イメージ (インデックス カラー イメージ) に関連する色変換データが含まれています。インデックス カラー イメージにのみ関連しており、イメージ内に配置する必要があります。データブロック(画像データチャンク)の前。
Color byte 意味 Red 1 で構成されます。バイト 0 = 黒、255 = 赤 緑 1 バイト 0 = 黒、255 = 緑 青 1 バイト 0 = 黒、255 = 青 因此,调色板的长度应该是3的倍数,否则,这将是一个非法的调色板。 颜色数 = length/3
对于索引图像,调色板信息是必须的,调色板的颜色索引从0开始编号,然后是1、2……,调色板的颜色数不能超过色深中规定的颜色数(如图像色深为4的时候,调色板中的颜色数不可以超过2^4=16),否则,这将导致PNG图像不合法。
图像数据块IDAT(image data chunk):它存储实际的数据,在数据流中可包含多个连续顺序的图像数据块。IDAT存放着图像真正的数据信息
图像结束数据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 数据块如下,修改数据为
计算 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 ファイル形式の分析
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
著者別の最新記事
2024-10-22 09:46:29
2024-10-13 13:53:41
2024-10-12 12:15:51
2024-10-11 22:47:31
2024-10-11 19:36:51
2024-10-11 15:50:41
2024-10-11 15:07:41
2024-10-11 14:21:21
2024-10-11 12:59:11
2024-10-11 12:17:31