On Sun, 2008-08-24 at 13:30 -0700, Steve Langasek wrote: > On Sun, Aug 24, 2008 at 08:28:32PM +0100, Neil Williams wrote: > > =head1 > > A more complex example using 'zenity' - a Gnome dialog generator. > > > $ pilot-qof -x data.xml --invoice-city -t 2006-11-08 | dfxml-invoice - > > > /tmp/zenity > > zenity --text-info --title="2006-11-08" --filename=/tmp/zenity > > --width=500 --height=300 > > =cut > The example *is* wrong - the example given is never safe to run, because the > only way to verify beforehand that /tmp/zenity is not a symlink to something > more important is by first explicitly *creating* your file funder /tmp > (non-destructively), then check that it's not a symlink, and *then* run > pilot-qof. Otherwise, there is always a race condition here between > checking for non-existence, and outputting to the file, tha is exploitable > for some ill purpose.
By whom and how? What kind of attacker is going to assume that a particular user not only has the package installed but has also chosen to use this specific one of a couple of dozen examples available in the doc package that goes alongside this one package, to create a particular file which is itself part of a process that even the most regular user operates once a month at most *and* that the user has not implemented the example in some other script that does various other checks? The number of users who need this particularly specialised example is very small (which is why it is not implemented directly within dfxml-invoice). An attacker would be insane to select this example as a vehicle. The whole point of the package is to support the use of the data in a wider variety of scripts, written by users for themselves. The example exists to show what can be done, not what every user is expected to do. Next release could drop the temporary file from the example completely - zenity does support '-', just like dfxml-invoice: $ pilot-qof -x data.xml --invoice-city -t 2006-11-08 | dfxml-invoice - \ | zenity --text-info --title="2006-11-08" - However, this is sub-optimal for two reasons: 1. It is wasteful - the display of the data via zenity may need to be repeated so re-calculating the data is a waste 2. Unnecessarily complicated for documentation (the need for '\' is, IMHO, an indication that the command is too long). I'm still not sure that this is an actual problem. Yes, a race condition could happen and yes, there could be all sorts of complicated ways of handling temp files and passing back the name of the file but examples have to be simple and clear, not obfuscated by problems unrelated to the nature of the example itself. This is just a simple redirect and is not even part of the program, any number of non-packaged scripts use redirects all over the OS and users really do need to take some accountability for what might happen if they copy examples literally. How many users have '> /tmp/foo' in their own scripts? (or > /home/user/foo which can be just as problematic and is completely pointless in documentation). /tmp is the natural place for temporary data - files that the user might need a few times over a finite period of time but which do not need to be kept around indefinitely. Constantly renaming files that the user may want to use a few times makes it pointless using the temporary file and causes unnecessary recalculation of the data. Do we want to sanitize every example and piece of documentation? Is it reasonable to obfuscate every example of a redirect with dire security warnings? Before I tested 'zenity --foo bar -', I was just considering replacing '/tmp/zenity' with '/path/to/tmp/file' but do we really want to go to such lengths? Where should the lines be drawn between clear documentation, overly cautious security and user-written scripts? -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
