OSS related Incident

简介 #

最近 OSS 桶相关发现了一个很有意思的小问题，简单做个记录，怕忘记了

影响 #

本身，这个可以算作一个没有什么危害的 “漏洞”，如果你提交到 SRC 的话，大概率会获得到一个低危甚至忽略。本身来说，这个问题确实也算不上什么安全问题，但是实际上会带来更广的影响

问题描述 #

每家都会有提供或者使用类似 OSS 服务的情况，使用方式非常简单，通常用户上传图片，平台侧前置了 CDN 给供用户访问图片。但是我们发现了一些，很有意思的现象，PNG图片可以当视频播放

但是往往，这种问题不会直接暴露出现，因为图片的上传会有压缩、水印等处理，在图片受到影响或者破坏的情况下，该问题默认不存在

那么他们是如何做到的呢？

了解 PNG #

PNG，全称为 Portable Network Graphics，是一种支持无损压缩的位图图形格式，支持索引、灰度、RGB三种颜色方案以及以及Alpha通道等特性。

另外这个适用于不止 PNG，未压缩的 JPG 这些同理

大部分的格式等，都可以从 wikipedia 中发现问题的答案，以及我随手翻阅的 博客，有以下四个数据块

• 文件头数据块IHDR（header chunk）：包含有图像基本信息，作为第一个数据块出现并只出现一次。
• 调色板数据块PLTE（palette chunk）：必须放在图像数据块之前。
• 图像数据块IDAT（image data chunk）：存储实际图像数据。PNG数据允许包含多个连续的图像数据块。
• 图像结束数据IEND（image trailer chunk）：放在文件尾部，表示PNG数据流结束。

简单来说，PNG 由文件署名和数据块两部分组成。常见的以 8950 4e47 0d0a 1a0a 开头，00 00 00 00 49 45 4E 44 AE 42 60 82 结尾的 IEND 数据块。通常情况下，解析图片只会解析到 IEND，而在 IEND 之后的数据是不会被图片解析的。如上面博客提到的，可以做数据隐藏，那么这有什么意义吗？

在实际场景中还真有利用的

视频流 #

在图片后面，添加一个兼容性很强的数据（数据格式），不会因为开头的一些”脏数据” 而影响使用，存在吗？答：视频流

因为这当中涉及到一些视频流相关的，作者不是这方面的专家，所以不做过多原理的解释。详见 wikipedia

直接在PNG图后拼接 0x47(G) + 188byte 数据，每次会从同步字节开始解析。在 PNG 开头的情况下，直接拼接视频流。甚至可以这么操作：

curl http://xxxx/test.png -o test.mpeg

直接播放就完了

实际利用 #

那么实际场景下，直接拼接一个大的视频，那不是太明显了吗？是的，所以有另外的办法，拼接一下放到 m3u8 即可。m3u8 相当于就是一个播放 list，每一个图片放几秒，拼接 小时级别的 电影，根本没啥问题。也就是一些自建视频站，能够开下去的原因，因为能够在线播放，还不用出 CDN 费用，有的时候会卡卡的，可能是资源被限速了…

危害 #

1. CDN 资源浪费，资源费用增长
2. 资源内容不受控制，因为本身会被当作 PNG 解析，不会审核视频内容（内容安全/严重）

其他 #

当然还有更花的…先不做公开了 给个 demo，curl https://chriskaliX.github.io/assets/imgs/test.jpg -o test.mpeg