Name: FluxBox Homepage: http://www.fluxbox.org Author: Quith <quith[at]linux-hell[dot]net> Date: Fri Nov 26 15:07:30 UTC 2004 ISSUE: FluxBox is a popular window manager for X, working under Linux/Unix operating systems. It's based on BlackBox and has 100% theme/style compability. (Xman is a manual page browser for the X Window Systems.) DESCRIPTION: FluxBox always freezes while executing XMAN or some other program with long value of '-title' parameter. Simple example with perl interpreter: $ xman -title `perl -e 'print "X" x 100000 '` It was tested on 0.9.10 version and some older ones. Probably all are somehow affected. ------------------------------ Quith <quith@linux-hell.net> http://www.quith.info Reproducible: Always Steps to Reproduce: 1. 2. 3.
http://www.securityfocus.com/archive/1/382398/2004-11-24/2004-11-30/2 Upstream are aware of the issue and are working on it. 0.9.11 is scheduled for release pretty soon, or we could apply the patch they make to 0.9.10 if necessary. According to upstream: * openbox, pekwm, pwm3 and others have the same issue * it's not just titles * disabling xft is a workaround * a quick fix if we don't want to wait for a full solution would be to limit the WM_NAME assignment in WinClient to 500 or less
Created attachment 44859 [details, diff] long_title_fix.patch upstream provided quick workaround. Security peeps -- do we go with this and do a new rev to 0.9.10 or do we stick around and wait for a real fix?
apply the patch in 0.9.11 version, it's not a critical bug.
This bug is not very critical, and hardly a vulnerability. As long as upstream is working on a fix, I personally don't think we need to patch it right away. I use openbox, and that command freezes it for like 5 seconds, then works fine again. Ciaran, if you can get a list of all effected packages, we can then contact their upstreams and make sure this gets taken care of.
hi, such long WM_NAME's are a problem for pekwm, openbox, pwm3, ion3, fluxbox, i deeply suspect blackbox too. kde works, xfce4 and metacity works too but both use a toolkit to do things "right" i guess. and i doubt that kdelibs or gnome render all 10000 chars of the string. i somehow suspect xft to be the issue here, but i am not sure.
Quith : Trying to determine if this can be considered a vulnerability... What would be the modus operandi ? User of the *box WM would run (or be tricked to run) a command that would freeze his own WM ? Or anything else I didn't think of ? If that's the only trigger, I can think of a dozen other commands that would eat up ressources as well. Unless a remote user (or a local user but not the one using the WM) can somehow trigger this, I don't think it should be considered a vulnerability... but just a bug that should be fixed. Please prove me wrong, I may miss the necessary info :)
I say we bump 0.9.10 with the patch, and move on. Ciaran/Security, your opinion?
This is not a security vulnerability. Re-assigning to commonbox.
0.9.11 in the tree.
