4 ms·

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 i

by franga2000 9y ago

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.

fao_ 9y ago
Not to mention the fact that npm is inherently insecure. https://ponyfoo.com/articles/npm-meltdown-security-concerns https://ponyfoo.com/articles/npm-meltdown-security-concerns https://www.bleepingcomputer.com/news/security/52-percent-of-all-javascript-npm-packages-could-have-been-hacked-via-weak-credentials/ https://www.bleepingcomputer.com/news/security/52-percent-of... https://github.com/joaojeronimo/rimrafall https://github.com/joaojeronimo/rimrafall https://github.com/npm/npm/issues/10999 https://github.com/npm/npm/issues/10999 https://twitter.com/o_cee/status/892306836199800836 https://twitter.com/o_cee/status/892306836199800836
djsumdog 9y ago
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.
__s 9y ago
https://www.cvedetails.com/vulnerability-list/vendor_id-1749/Imagemagick.html https://www.cvedetails.com/vulnerability-list/vendor_id-1749...
geofft 9y ago
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 https://github.com/ImageMagick/ImageMagick/issues/927 and over 200 were found in 2017: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=imagemagick 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 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 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 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.

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.

fao_ 9y ago

Not to mention the fact that npm is inherently insecure. https://ponyfoo.com/articles/npm-meltdown-security-concerns https://ponyfoo.com/articles/npm-meltdown-security-concerns https://www.bleepingcomputer.com/news/security/52-percent-of-all-javascript-npm-packages-could-have-been-hacked-via-weak-credentials/ https://www.bleepingcomputer.com/news/security/52-percent-of... https://github.com/joaojeronimo/rimrafall https://github.com/joaojeronimo/rimrafall https://github.com/npm/npm/issues/10999 https://github.com/npm/npm/issues/10999 https://twitter.com/o_cee/status/892306836199800836 https://twitter.com/o_cee/status/892306836199800836

djsumdog 9y ago

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.

__s 9y ago

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

geofft 9y ago

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 https://github.com/ImageMagick/ImageMagick/issues/927 and over 200 were found in 2017: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=imagemagick 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 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 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 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.