Tag: imagemagick

在 command line 下生出全灰的圖片

因為需要一張 1920x1080 全灰色的圖片，翻了一下 DuckDuckGo 找到這篇：「Linux create Image pixel by pixel in command line」。

裡面抓重點，主要的想法是 PPM 格式 (可以參考「Netpbm」這個條目)，然後找到「PPM Format Specification」這份文件。

主要就是用 P3 模式下去產生檔案：

repeat 2073600 echo '127 127 127' >> grey.ppm

然後開頭的地方修一下，加上 P3、長寬資訊以及最大的值：

P3
1920 1080
255

接著就用 ImageMagick 轉檔：

convert grey.ppm grey.png

然後用 viewer 看一下，確認沒問題就收工了...

又是 ImageMagick 出包...

ImageMagick 的 information leaking，然後 Yahoo! 很無奈的中獎，所以被稱為 Yahoobleed：「Yahoo! retires! bleeding! ImageMagick! to! kill! 0-day! vulnerability!」。發現問題的作者把問題寫在「*bleed continues: 18 byte file, $14k bounty, for leaking private Yahoo! Mail images」這邊。

作者利用 ImageMagick 的不當處理，取得 uninitialized memory 的資訊，藉以取得可能是上次轉檔的記憶體內容。而這個 jpeg 只有 18bytes (所以作者戲稱每個 byte 價值 USD$778)：

A robust bounty of $14,000 was issued (for this combined with a similar issue, to be documented separately). $778 per byte -- lol!

目前的 workaround 也很簡單 (官方採用了)，呼叫 ResetMagickMemory 避免 leaking (咦，這方法好像哪邊怪怪的)：「Reset memory for RLE decoder (patch provided by scarybeasts)」。

最近的兩個安全性漏洞：OpenSSL、ImageMagick

OpenSSL 的安全性漏洞公告：「OpenSSL Security Advisory [3rd May 2016]」。ImageMagick 的安全性漏洞說明頁：「ImageTragick」。

CVE-2016-2107 是修 Lucky 13 問題時沒修好造成的：

This issue was introduced as part of the fix for Lucky 13 padding attack (CVE-2013-0169). The padding check was rewritten to be in constant time by making sure that always the same bytes are read and compared against either the MAC or padding bytes. But it no longer checked that there was enough data to have both the MAC and padding bytes.

而 CVE-2016-2108 是組合技，從兩個「看似無害」的安全性問題開始：

This vulnerability is a combination of two bugs, neither of which individually has security impact.

The first bug (mishandling of negative zero integers) was reported to OpenSSL by Huzaifa Sidhpurwala (Red Hat) and independently by Hanno Böck in April 2015. The second issue (mishandling of large universal tags) was found using libFuzzer, and reported on the public issue tracker on March 1st 2016.

然後 Google 的人找出來可以打穿：

The fact that these two issues combined present a security vulnerability was reported by David Benjamin (Google) on March 31st 2016.

另外隔壁棚的 ImageMagick 安全性問題是個慘劇，是個 RCE 等級的，而且 exploit 已經在外面跑了：

One of the vulnerabilities can lead to remote code execution (RCE) if you process user submitted images. The exploit for this vulnerability is being used in the wild.

Heroku 上跑 PHP 的心得與感想...

Heroku 不愧是 PaaS 中的領先品牌，deploy 的操作及穩定性都相當好，加上 Heroku 每個 project 都有 1 free dyno 可以使用，對於 prototyping 其實相當棒...

關於要怎麼在 Heroku 上跑 PHP，可以參考 xdite 寫的「Create PHP application on Heroku without Facebook account」這篇文章。

有幾個要抱怨的：

  • PHP 是用 Apache HTTP Server 跑的，所以可以用 .htaccess 寫 rewrite rule，不過 Options -Indexes 居然會 500 (因為 AllowOverride 沒開給使用者用)，這個設定看起來沒有什麼 issue，應該是 Heroku 還在摸索這塊...
  • 沒有 ImageMagick，只有 GD，而 GD 居然沒支援 JPEG，這是要讓人怎麼用...
  • 在 phpinfo() 看到支援的 module 有點少...

這些問題其實還蠻大的，不過，應該有機會改善... 應該... 應該...