It seems wehave a new security bug see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674718
Could you review please.
If it is a true secuirty bug, could you made a release ? We are near a debian freeze and it will allow to have a version in the next stable without a patch queue.
Bastien
PS: BTW could you give me the process to report security bug, private message on this forum ? Mail ?
[user error] Security bug DOS ?
-
broucaries
- Posts: 467
- Joined: 2008-12-21T11:51:10-07:00
[user error] Security bug DOS ?
Last edited by broucaries on 2012-07-23T09:55:21-07:00, edited 1 time in total.
Re: Security bug DOS ?
Thank you for the problem report. Feel free to post future security flaws in this forum.
The problem you reported is not a security flaw or bug. ImageMagick is designed to handle giga-pixel images. The command the user posted @ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674718 attempts to create an image whose size is 47089x6320 pixels which is perfectly reasonable. We have processed images that exceed 250000 by 2500000 pixels. Its true that a large image could exceed the amount of resources available on the system. If there is not enough memory, ImageMagick attempts to allocate the pixel cache on disk and memory map it. Linux returns a SIGBUS signal if the memory map exceeds the system limits (e.g. the temporary partition fills up). If there is not enough memory map resources available, ImageMagick caches the image to disk. If disk is exceeded on the temporary partition, it returns a IO exception.
To mitigate a possible DOS, the user or the system maintainer can control the amount of resources the ImageMagick pixel cache can consume. The user can do this with resource limits with the command line (-limit) or with the API. The system maintainer can enforce limits by configuring the policy.xml file, typically /usr/etc/ImageMagick/policy.xml. The system policy cannot be overridden by the user. Here we limit the pixel cache memory to 2GiB, the memory map to 4GiB, and the disk to 4Gib. Any image area that exceeds 1GB is automatically cached to disk rather than memory / memory mapped. In addition, to prevent run-away jobs, we limit the maximum wall clock time for any one process to 60 seconds. And why not limit each user to just 2 of the 8 cores available on our system. And we notice our temporary disk partition is rather small so we move the pixel cache to a larger partition with plenty of free space. Finally, we don't want ImageMagick hogging the CPU so we add a small throttle:
If a very large image exceeds the 4GB disk list, ImageMagick returns an exception: cache resources exhausted.
For further discussion, see the Cache Storage and Resource Requirements section in http://www.imagemagick.org/script/archi ... .php#cache. We utilize these methods for ImageMagick Studio @ http://www.imagemagick.org/MagickStudio ... Studio.cgi. We ping each image (get image metadata without allocating the pixel cache), and if the image area exceeds the 3096x3096 limit, an exception is returned.
The problem you reported is not a security flaw or bug. ImageMagick is designed to handle giga-pixel images. The command the user posted @ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674718 attempts to create an image whose size is 47089x6320 pixels which is perfectly reasonable. We have processed images that exceed 250000 by 2500000 pixels. Its true that a large image could exceed the amount of resources available on the system. If there is not enough memory, ImageMagick attempts to allocate the pixel cache on disk and memory map it. Linux returns a SIGBUS signal if the memory map exceeds the system limits (e.g. the temporary partition fills up). If there is not enough memory map resources available, ImageMagick caches the image to disk. If disk is exceeded on the temporary partition, it returns a IO exception.
To mitigate a possible DOS, the user or the system maintainer can control the amount of resources the ImageMagick pixel cache can consume. The user can do this with resource limits with the command line (-limit) or with the API. The system maintainer can enforce limits by configuring the policy.xml file, typically /usr/etc/ImageMagick/policy.xml. The system policy cannot be overridden by the user. Here we limit the pixel cache memory to 2GiB, the memory map to 4GiB, and the disk to 4Gib. Any image area that exceeds 1GB is automatically cached to disk rather than memory / memory mapped. In addition, to prevent run-away jobs, we limit the maximum wall clock time for any one process to 60 seconds. And why not limit each user to just 2 of the 8 cores available on our system. And we notice our temporary disk partition is rather small so we move the pixel cache to a larger partition with plenty of free space. Finally, we don't want ImageMagick hogging the CPU so we add a small throttle:
Code: Select all
<policymap>
<!-- <policy domain="system" name="precision" value="6"/> -->
<policy domain="resource" name="temporary-path" value="/data/tmp"/>
<policy domain="resource" name="memory" value="2GiB"/>
<policy domain="resource" name="map" value="4GiB"/>
<policy domain="resource" name="area" value="1GB"/>
<policy domain="resource" name="disk" value="4GB"/>
<!-- <policy domain="resource" name="file" value="768"/> -->
<policy domain="resource" name="thread" value="2"/>
<policy domain="resource" name="throttle" value="1"/>
<policy domain="resource" name="time" value="60"/>
</policymap>For further discussion, see the Cache Storage and Resource Requirements section in http://www.imagemagick.org/script/archi ... .php#cache. We utilize these methods for ImageMagick Studio @ http://www.imagemagick.org/MagickStudio ... Studio.cgi. We ping each image (get image metadata without allocating the pixel cache), and if the image area exceeds the 3096x3096 limit, an exception is returned.