Description of problem: $ df /tmp Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 3056896 3844 3053052 1% /tmp $ convert *tif ENW.pdf Bus error (core dumped) $ df /tmp Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 3056896 3056896 0 100% /tmp Version-Release number of selected component (if applicable): ImageMagick-6.7.8.9-5.fc19.x86_64 How reproducible: Always. Steps to Reproduce: 1. Take a large number of big *.tifs and try the convert command above. Actual results: Segfault Expected results: Function. Additional info: * AFAIS, the culprit is TmpOnTmpfs. convert seems to allocate temporary files underneath of /tmp for each input file. At some point, this will fail due to the comparatively small amount of disk-space under /tmp. Also note, convert does not clean up these files, but lets them stay on disk! * I for one, am classifying this bug as critical, because this bug allows arbitrary users to trigger DenialOfServices on a system.
*** Bug 1006660 has been marked as a duplicate of this bug. ***
Thank you for your bugreport and willing make free software better! You could try use different path via TMPDIR variable (http://imagemagick.sourceforge.net/http/www/FAQ.html#C1). I think there nothing to do with ImageMagick itself. Please reopen if you have some suggestions.
(In reply to Pavel Alexeev (aka Pahan-Hubbitus) from comment #2) > Thank you for your bugreport and willing make free software better! > > You could try use different path via TMPDIR variable > (http://imagemagick.sourceforge.net/http/www/FAQ.html#C1). > I think there nothing to do with ImageMagick itself. I guess, you haven't understood the scope of this breakdown? So, more verbose: * Running convert may kill a systems * Thanks to TmpOnTmpfs, the probablility for this to happen has risen significantly. > Please reopen if you have some suggestions. What I am I suppossed to think of this reaction? Face it, YOU are supposed to have suggestions!!! By closing this BZ, you are reacting grossly negligant. This BUG is a SERIOUS SECURITY RISK !!!
What are you suppose to do with it in ImageMagick?
Hi Ralf, A user being able to fill up /tmp doesn't need ImageMagick to be able to cause problems on the system. There is no security risk from ImageMagick doing this because fundamentally the user had permission to do this anyhow. This is not a bug either. One can argue that resetting a default to write to ~/.cache instead of /tmp might be appropriate - but as ImageMagick is often invoked from a webserver where there is no homedir, it still boils down to a system administration issue with no 'one size fits all' solution.
I really want fix it, but space in our disks is really thing is not related to ImageMagick. You may fulfill /tmp which is fixed size (tmpfs there really have less sense, more space also may be filled). I really do not see single "proper way" to fix such issue. If you have any reasonable suggestions - please say.
(In reply to Norm Murray from comment #5) > A user being able to fill up /tmp doesn't need ImageMagick to be able to > cause problems on the system. Correct, he can do so without ImageMagick. > There is no security risk from ImageMagick > doing this because fundamentally the user had permission to do this anyhow. Well, I had killed my system by simply invoking "convert". > This is not a bug either. A program being able to kill system as side-effect is not a bug? I agree, the problem is wider than just ImageMagick. IMO, TmpOnTmps is a critical general security risk and RH management mistake, but I guess RH needs to learn this the hard way. > One can argue that resetting a default to write to ~/.cache instead of /tmp > might be appropriate - but as ImageMagick is often invoked from a webserver Exactly - There, using /tmp is a massive security risk. Pedantically speaking, /tmp has always been as security risk, but TmpOnTmpfs has dramatically worsened the situation. It makes a difference whether to have "1/2 RAM" or "the remaining free diskspace" available. > where there is no homedir, it still boils down to a system administration > issue with no 'one size fits all' solution. ~/<somewhere> at least would be a "safer" default for non-web-server cases. Other alternatives would be using /var/tmp or /var/{cache|lib}/<somewhere> instead of /tmp.
(In reply to Ralf Corsepius from comment #7) > (In reply to Norm Murray from comment #5) > Other alternatives would be using /var/tmp or /var/{cache|lib}/<somewhere> > instead of /tmp. Rather it can't be filled? Will not it be then security holl also?
(In reply to Pavel Alexeev (aka Pahan-Hubbitus) from comment #8) > (In reply to Ralf Corsepius from comment #7) > > (In reply to Norm Murray from comment #5) > > Other alternatives would be using /var/tmp or /var/{cache|lib}/<somewhere> > > instead of /tmp. > Rather it can't be filled? Surely, it also can be filled. However, with TmpOnTmpFs, /tmp usually is just a very few GBs large (Fedora default is 1/2 of RAM), while /var/tmp, in a standard Fedora configuration is "All of remaining diskspace" (Typically several 10s/100s of GB). > Will not it be then security holl also? Well, any "/tmp" diskspace - independently of where it physically is - can be filled up. However, it matters what actually flows over (a user's quota, a partition, ...) and how likely it is to flow over. My point here is, the diskspace provided by TmpOnTmpfs usually is tiny in comparison to "real disks" which makes it much more likely to flow over than any "real diskspace". Eg. in my case of convert, it was sufficent to invoke "convert" to convert a series of ca. 10 tifs to pdf to trigger a "Denial of Service" incident on my local machine (6GB RAM/3 GB TmpFs, 1TB HD).
Ralf, Again, this is an administration choice. Anywhere you put /tmp it's a limited resource and is designed for transient files. TmponTmpFS gives you performance at the cost of space - this works best for a large number of people, but not all. Don't like it, change it. https://ask.fedoraproject.org/question/25383/how-turn-off-tmpfs-on-fedora-18/ At this point, this is not a bug, but a choice in the way you, a local user, use the system. There is absolutely not a "Denial of Service" here - you USED the service of your own system, to it's full capacity and ran out. You hit a limit of the system based on the way you have it configured and the way that you are using it. That does not make it a bug. You have the keys to your own car, and the ability to drive in first gear or fourth. If you load your car with all your friends, and try to start moving while you're in fourth gear going uphill and the engine stalls, that doesn't mean there's a problem with the brand of gas that you're using. Take responsibility - understand how you use the system, and administrate it for your own usage. That's a great thing about Linux and Fedora - ultimately the choices are yours.
(In reply to Norm Murray from comment #10) > Ralf, > > Again, this is an administration choice. Not quite. Fedora's default is /tmp on TmpFS, ie. users by default (without having been presented a choice) are using a tiny /tmp, which opens up a lot of opportunities for *arbitrary* users running convert to kill a system. > Anywhere you put /tmp it's a > limited resource and is designed for transient files. TmponTmpFS gives you > performance at the cost of space - this works best for a large number of > people, but not all. In other words, it lacks generality! And ... as the "convert" case demonstrates, it's very easy to reproduce without major effort for everybody. > Don't like it, change it. That's not my point. I am saying Red Hat is forcing unsafe defaults into installation, which opens up plenty of opportunities for vulnerabilities. > https://ask.fedoraproject.org/question/25383/how-turn-off-tmpfs-on-fedora-18/ > > At this point, this is not a bug, but a choice in the way you, a local user, > use the system. Wrong. The casual installer is NOT AWARE about the VULNERABILITIES TmpOnTmpfs has attached - He uses the *unsafe defaults*! *Nothing* Fedora's installer offers the installer a choice to this stuff off nor does anything in Fedora warn him about the instabilities of TmpOnTmpfs. > There is absolutely not a "Denial of Service" here - you > USED the service of your own system, to it's full capacity and ran out. Do yourself a favor and try the convert case. You will find plenty of programs will start misbehaving/to fail, after "convert" has crashed and hasn't cleaned up /tmp afterwards.
This is NOT a 'critical' bug in ImageMagick /tmp has a cleaning policy - no matter where it's mounted. There are no vulnerabilities here: No unprivledged user has access to the system. No user is getting escalated privledges. No unintended code is being run. No user is granted access to more resources than you allow in local administration. With those statements, this is not in any way a security concern. There is no safety issue with the system. Your convert example is a corner case in extreme system usage - an example of extreme use of a system resource more limited than you expected based on your past use. A large change in a default behaviour is always going to catch people by surprise when they relied on the old behaviour. Not everyone agrees with every decision on a change. That's ok. That doesn't make it wrong for the majority either. There is not a one size fits all here. For myself, I ensure that systems fit my needs based on how I use them. I have systems where Tmpfs won't be appropriate based on usage pattern or desire - others where it's not likely to make any difference. Should convert crash if there isn't sufficient space in /tmp for it's operation (no matter where /tmp is actually mounted?) - No. That's a bug. convert should detect a lack of space and fail gracefully - cleaning up any files that had been created along the way. Is it a bug with security concerns? No. Is it a critical bug? No Is it a bug specific to Fedora packaging or environment? No Does the bug leave the integrity of the system unsafe? No Does filling the filesystem that /tmp is mounted on cause other things on the system to fail - yeah, but that's /tmp for you - whether Tmpfs or / and any user who can create a file on /tmp can do that (cat /dev/random > /tmp/foo ) and that has never been a security concern.
(In reply to Norm Murray from comment #12) > This is NOT a 'critical' bug in ImageMagick I disagree. It can be used to create DOS-malfunctions on arbitrary installation by arbitrary users logged into a system rsp. by arbitrary SW (web servers) running on a system. > /tmp has a cleaning policy - no matter where it's mounted. Irrelevant wrt. this topic. > There are no vulnerabilities here: > No unprivledged user has access to the system. Irrelevant. Any arbitrary user, who has access to a system can shift a system into malfunction. > No user is getting escalated privledges. True. > No unintended code is being run. True. > No user is granted access to more resources than you allow in local > administration. True, but irrelevant. > With those statements, this is not in any way a security concern. There is > no safety issue with the system. I disagree again: "By using ImageMagick provided tools any arbitrary user, who has normal access to a system is able to cause a system to malfunction. > Your convert example is a corner case in extreme system usage - an example > of extreme use of a system resource more limited than you expected based on > your past use. IMO, this is a very narrow view. To me, this qualifies as a regression. A regression which is caused by the amount of diskspace available on /tmp having shrunk by magnitudes, thanks to TmpOnTmpfs. > A large change in a default behaviour is always going to catch people by > surprise when they relied on the old behaviour. Well, it's not me who "relied on old behaviour". It's me as an ordinary user, who is facing functional regressions in an ordinary user program. > Not everyone agrees with > every decision on a change. That's ok. Correct. My opinion on TmpOnTmpfs is widely known: A short-sighted approach, which lacks genererality and therefore MUST NOT be default. Offering users TmpOnTmpfs as an widely visible opt-in option during installation would be OK with me. > That doesn't make it wrong for the > majority either. Irrelevant. The majority of users (comprising me) normally doesn't often run "convert". > There is not a one size fits all here. TmpOnFile is magnitudes safer than TmpOnTmpfs - What to chose? > For myself, I ensure that systems fit my needs based on how I use them. Well, my use-case here is an ordinary Desktop, here using it for office purposes. Nothing extraordinary - I am facing TmpOnTmpfs is causing malfunctionals on it. > I > have systems where Tmpfs won't be appropriate based on usage pattern or > desire - others where it's not likely to make any difference. I also have them: * Machines with very small amounts of RAM. There, TmpOnTmpfs just unsuiteable for almost everything. * Servers. > Should convert crash if there isn't sufficient space in /tmp for it's > operation (no matter where /tmp is actually mounted?) - No. That's a bug. > convert should detect a lack of space and fail gracefully - cleaning up any > files that had been created along the way. No disagreement. > Is it a bug with security concerns? No. A filled up /tmp causes Denial of Services. > Is it a critical bug? No Define critical. > Is it a bug specific to Fedora packaging or environment? No Yes. Fedora's TmpOnTmpfs is the trigger of this breakdown. > Does the bug leave the integrity of the system unsafe? No Yes. With a filled up /tmp many programs fail. As rebooting cleans up /tmp, the state of failure is not persistent through reboots. But ... do you really consider this Microsoftish strategy to be appropriate? I don't. > Does filling the filesystem that /tmp is mounted on cause other things on > the system to fail - yeah, but that's /tmp for you - whether Tmpfs or / and > any user who can create a file on /tmp can do that (cat /dev/random > > /tmp/foo ) and that has never been a security concern. Again, with TmpOnFile, one had plenty of diskspace available => The likelihood to accidentically trigger filled up /tmp was small. With TmpOnTmpfs the likelihood to trigger this is magnitudes higher.
Ralf, Set aside your bias here. You found and reported a bug against convert. That bug is that convert will crash when /tmp runs out of space as it's writing out temp files. That particular bug has no security implications. Everything else that you complain about with TmpOnTmpfs has nothing to do with convert or the above bug. So from a standpoint of ImageMagick, it's irrelevant. The problem you incorrectly believe to be a Denial of Service attack can be caused by any user with cat - or any other application which writes data to a location that the user has access to (and per policy, all have access to /tmp). Please open a new bug against TmpOnTmpfs if you feel strongly that this behavior is incorrect, but please stop blaming that behaviour on convert / ImageMagick
Thanks for the comments and willing make free software better. Upstream bug about unclean way crash filled - http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=24319 . Ralf, I really do not known what I can do more with ImageMagick itself. If you want you could change ImageMagick TMP path also.