Package: feh Version: 1.3.4.dfsg.1-1 Severity: grave Justification: user security hole Tags: security
This bug is related to bug #397125 which was asking to change the way ~/.fehbg is created. Bug #397125 had a priority of normal; however its priority should have been grave as this report, because the same security issues applied. In fact the patch supplied with the report of bug #397125 (which is not the one that has been applied to close it) did not solve the security problem either, which root cause is the recommendation of the feh manual page: add the line "eval ‘cat $HOME/.fehbg‘" to your X startup script, whereas the filename is put in it unescaped. The situation described next is the one in version 1.3.4.dfsg.1-1 with a new patch applied. Using the eval construct will make code execute that is part of the filename like this example shows: $ ls img.jpg $ ln -s img.jpg '`rm *`.jpg' $ feh --bg-scale '`rm *`.jpg' $ cat ~/.fehbg feh --bg-scale "`rm *`.jpg" $ eval `cat ~/.fehbg` rm: remove regular file `img.jpg'? n rm: remove symbolic link ``rm *`.jpg'? n feh WARNING: .jpg - File does not exist feh ERROR: Couldn't load image in order to set bg I see 2 options to solve this: * option1: change the manual page and recommend `cat $HOME/.fehbg` in the X startup script (and make users aware of the issue). This is sufficient to solve the secutity issue, but in addition, to allow spaces (or other characters in $IFS except newlines) in filenames, also apply the patch supplied with the report of bug #397125 (not the one actually applied at present). * option2: apply a patch that escapes the filenames correctly in ~/.fehbg (similar to the one applied at present). This implies that the filename be processed and its special characters escaped, even if the filename is enclosed in quotation marks. It is easier to use simple quotes to enclose the filename than double quotes because I _think_ only simple quotes in the filename have to be escaped then. With option1 filenames cannot contain newlines and the users have to change their configurations. With option2 the shell interprets the command which means that not "any" shell can be used. I do not know enough to say if it is a grave problem (Are all the shells compatible in regard to quotations?). I like option1 much better because it is much simpler, thus less prone to fail (in some years or in some exotic environment) and if it fails there are no security consequences as for option2. PS. As the situation is now and as it would be with option2, it is better to change the recommendation of the manual page to: add the line ". $HOME/.fehbg" to your X startup script, because it does, AFAICT, the same as the one given at present but is simpler to understand. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
