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 费用,有的时候会卡卡的,可能是资源被限速了…
危害 #
- CDN 资源浪费,资源费用增长
- 资源内容不受控制,因为本身会被当作 PNG 解析,不会审核视频内容(内容安全/严重)
其他 #
当然还有更花的…先不做公开了 给个 demo,curl https://chriskaliX.github.io/assets/imgs/test.jpg -o test.mpeg