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/

Attachment:
signature.ascDescription: This is a digitally signed message part