GNOME Bugzilla – Bug 85103
GIMP should warn user if extremely large fonts are requested
Last modified: 2011-10-27 19:56:50 UTC
The Register posted a message today about an X-Windows bug that allows somebody to DoS a desktop Linux box by presenting a user with unusually large type in a Mozilla instance using stylesheets. (See <http://www.theregister.co.uk/content/55/25689.html>.) According to the article, "The behavior can be duplicated with applications like the Gimp, we're told, but these aren't remotely exploitable." I don't know if this is true, and if it is, if it has been reported before. keywords: big font size X-Windows exploit
The corresponding Mozilla bug is documented here: http://bugzilla.mozilla.org/show_bug.cgi?id=150339 The bug was caused by a CSS style sheet requesting a ridiculously large font (166666 pixels), which causes some X servers or xfs font servers to allocate enormous amounts of memory and then freeze or crash the machine. This is actually a bug in the X server, but the fact that it can be easily triggered remotely by Mozilla makes it very annoying, that's why the Mozilla team decided to include a safeguard in the Mozilla code (until all X servers are fixed). Their solution is to clamp the size of the font to twice the height of the display. The GIMP is also affected by this X server bug, but this is a minor problem because it would require the user to request a very large font from the text tool. Most users will not do that. On the other hand, I don't think that we should try to silently limit the size of the fonts that can be used in the GIMP, because some artists working on huge posters are likely to request fonts that are much larger than the size of the screen. So it is probably better to add a warning in the text tools when the user requests a very large font (similar to the warning displayed if the user tries to create a very large image that would consume a lot of memory). I have changed the title of the bug report accordingly. I have also set the OS field to "All" even if Windows is not affected, because several UNIX systems (including Linux and Solaris) are affected.
GIMP can be used as a remote imaging tool. Would the bug not be more serious in those cases?
It depends on how the GIMP is used as a remote imaging tool. If it is used to create logos and other images from a web interface (such as the one on www.cooltext.com), then it would be up to the authors of these web pages to include some safeguards in their code. I tried to test this on www.cooltext.com and it seems that they silently limit the size of the font to 255. I also tried with www.flamingtext.com and they generate an error if the font size is larger than 100. I do not know if there are other sites allowing a remote user to specify the size of the font that will be used by a GIMP process. But it looks like the most popular ones are already safe. So the only thing that we should care about is to warn the user if she specifies a very large size in the text tool or in the gdyntext plug-in. This could also affect Script-Fu, but most scripts already include some range limits in their entry fields so this should not be a problem.
As reported some time ago in bug #69076, it is unfortunately easy to request extremely large fonts by accident in the gdyntext plug-in, and this can crash the font server or X server. It would be nice to get a warning message in this case.
*** Bug 114808 has been marked as a duplicate of this bug. ***
As seen in bug #114808, we have the same problem with the new text tool as well. About time to do something about it...
Changes at the request of Dave Neary on the developer mailing list. I am changing many of the bugzilla reports that have not specified a target milestone to Future milestone. Hope that is acceptable.
Changing milestone to 2.0, since this may be an issue with the new text tool. We should look at this again before releasing. To be honest though, I'm not sure I see the problem. Cheers, Dave.
Quoting Dave: "I'm not sure I see the problem". It is unfortunately easy to see the problem. Just pretend for a second that you did a mistake and enter 8000 in the font size field of the text tool or in some plug-in or script (this could happen because the focus was not in the right widget or for many other reasons). Now let the GIMP render the text. You are lucky if your machine is still responsive after that. Depending on how the rendering is done (X server, font server or freetype library) and how long it takes for your machine to run out of disk space or swap space, you will crash the GIMP or the whole X session.
Fortunately the solution is also easy. You will see that the problem will go away as soon as the text tool GUI is finished. There will be a text box and nothing will be rendered outside this box.
Is this the right solution? From time to time, I want to render fonts that are larger than the image itself (not much larger, but sometimes twice as large). I use this to have a single glyph that is partially clipped by the edges of the image and do some pseudo-artistic stuff with the curves of this glyph. Well, maybe limiting the font size to the size of the text box is a good idea. To achieve the effect that I want, I would simply have to create a larger image, a larger text box and then crop the results later. I guess I could live with that. Just thinking aloud. Sorry for the noise.
You misunderstood me. I didn't say that I would limit the font size to the size of the box. We just wouldn't allocate the memory needed to draw the text completely but only what's needed to render to the text box. Layouting the text in gigantic font sizes is not a problem. We just need to clip when rendering.
Ah, that's fine, then. This would solve the problem for the text tool. There could still be some problems with any script or plug-in calling gimp-text or gimp-text-fontname. Should there be some limits in the PDB calls? Or can we trigger a warning from there and return an error if the user aborts the operation?
There is a limit already, although of course arbitrary and it should probably e removed.
My X crashed yesterday because I changed the font-size by accident to a high value (namely, changed the font units from pt to in with a mouse wheel flip). IMO, this _is_ a issue. Even if the GIMP won't render fonts larger than the image, it apperars that the simple fact that a big font size is selected causes the failure. I suggest that a warning box pops up when great font-size values are selected before any font-selecting be performed. A "cancel" would restore previous values, a "ok" would proceed anyway. This will avoid systems hanging by accident.
This is completely bogus. X11 isn't even involved when fonts are rendered in GIMP-1.3. As soon as the remaining text tool changes are done (bugs #122707 and #118356), you will be able to use any font size without causing an unreasonable amount of memory to be allocated. Changing the milestone to 1.2 and proposing to resolve as WONTFIX.
This won't be fixed in 1.2 and still needs to be addressed in 2.0. Setting milestone to 2.0.1
Hmm, since the text tool box mode didn't make it into 2.0, I should probably add this warning. This is not going to be trivial though...
Bumping to milestone 2.0.2.
Bumping to milestone 2.2.
Bumping the milestone for this bug to Future. About time we go finally enter string freeze.
I'd have to agree that this is still a problem even with 2.2.8. Twice I have typed in >3000 sized fonts accidentally and Gimp just sits and spins (probably trying dutifuly to render a 3000+ pixel font). Eventually, you simply have to kill Gimp and you lose your work unless you want to wait for your system to crash after it runs out of swap. The solution is simple. Just put up a requester in Gimp to ask the user if this is really what they had intended (Yes or No). Otherwise, if this is a problem, then simply let the user press escape to stop the current operation in progress. Either way, this problem should really have gone away considering the above discussion.
It would help if you could come up with a patch that implements this - in this case, you'd also be able to make sure that it works like you want it to.
*** Bug 376433 has been marked as a duplicate of this bug. ***
*** Bug 390046 has been marked as a duplicate of this bug. ***
*** Bug 472324 has been marked as a duplicate of this bug. ***
As mentioned in the duplicates, it is unfortunately easy to trigger this bug and lose all your work: - typing a font size without erasing the previous number results in 4-digits font sizes. - typing a font size with the wrong unit selected (in instead of pt) gives a font that is 72 times larger than expected. - and the worst case: a single right-click on the up arrow of the font size spinner will immediately set it to 8192 (I just tested this and the results are not funny - beware!)
Darn. I searched for the bugzilla database, but I couldn't find this. Why, exactly, would a search for 8192 not turn up bug 114808 ? I remembered to select closed and resolved bugs, too.
Probably because you search for 8192 in the Summary field, and not for comments.
This doesn't need to block the release. Moving it from the milestone.
*** Bug 597617 has been marked as a duplicate of this bug. ***
*** Bug 603415 has been marked as a duplicate of this bug. ***
Resolving as duplicate of a much younger bug because it has a reasonable patch attached. *** This bug has been marked as a duplicate of bug 662787 ***