Hacker News Reader

Comment by geofft | Hacker News Reader

Also node is memory-safe and Imagemagick isn't. Somewhat surprisingly to me, the two dependencies (get-pixels for reading and gif-encoder for writing) are both written in pure JS, meaning that using this solution is vastly more responsible than using Imagemagick, if you're handing it untrusted input images.

View on HN

How is ImageMagick not memory-safe? An attacker could only do damage if they discovered a very bad bug in ImageMagick, but such a bug could also be discovered in Node.

Not to mention the fact that npm is inherently insecure.

https://ponyfoo.com/articles/npm-meltdown-security-concerns

https://www.bleepingcomputer.com/news/security/52-percent-of...

https://github.com/joaojeronimo/rimrafall

https://github.com/npm/npm/issues/10999

https://twitter.com/o_cee/status/892306836199800836

There have been ImageMagick security bugs in the past, but it is an active project/community and they do get patched.

I'd prefer using ImageMagick for something like this, but it's all about tradeoffs and what you're looking to do. There could be memory/security bugs in the future. There are also performance trade-offs if you created a microservice for this function in rmagic/ruby vs node (and you should do both and test them, because you might be surprised which one is actually faster).

I agree it's best to use the right tool for the task, and there are valid reasons for using both in this case. I'd personally probably take the ruby/rmagick/ImageMagick approach myself in a container, but that's not to say that's the best approach.

https://www.cvedetails.com/vulnerability-list/vendor_id-1749...

Such very bad bugs get discovered regularly in Imagemagick. The most recent one is from earlier this month: https://github.com/ImageMagick/ImageMagick/issues/927 and over 200 were found in 2017: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=imagemagick (Of those, a bit under 100 were memory leaks, but the rest are things like buffer overflows.)

Meanwhile, bugs that allow malformed input to trustworthy code in JavaScript to subvert or escape the JavaScript interpreter - or the equivalent bugs in Python, Ruby, Perl, etc. - are extremely rare. Of the bugs in 2017 in V8, Node's JavaScript interpreter, every single one of them requires specific malicious Javascript: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=v8

It is very easy for a good programmer to accidentally write honest C code that has memory safety bugs that allow an attacker to take over your computer by sending it specially-crafted input. It is very hard for a good programmer to even intentionally write underhanded JS/Python/Ruby/Perl/etc. code that introduces one of these bugs without looking like it's trying to introduce one of them, let alone do so by accident.

Of the security bugs in V8 from 2017 http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=v8, it looks like exactly one of them could be (and was) tripped by honest code, instead of code trying to subvert the interpreter: https://crbug.com/744584 and if I'm reading it right, it's not even data-dependent. Either the code has the bug or it's not.

Reply on news.ycombinator.com