[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#496429: The possibility of attack with the help of symlinks in some Debian packages

On Sun, 2008-08-24 at 22:05 +0400, Dmitry E. Oboukhov wrote:
> Package: datafreedom-perl
> Severity: grave

No, that is just plain wrong, sorry.

> Hi, maintainer!

(and I do so hate unnecessary exclamation marks)

> This message about the error concerns a few packages  at  once.   I've
> tested all the packages (for Lenny) on my Debian mirror.  All  scripts
> of packages (marked as executable) were tested.
> In some packages I've discovered scripts with errors which may be used
> by a user for damaging important system files or user's files.

Dmitry - the discussion on -devel did note the risks of false positives
and I would have expected that you would have taken more care before
starting to file bugs.

> For example if a script uses in its work a temp file which is  created
> in /tmp directory, then every user can create symlink  with  the  same
> name in this directory in order to  destroy  or  rewrite  some  system
> or user file.  Symlink attack may also  lead  not  only  to  the  data
> desctruction but to denial of service as well.

Not when the use of /tmp is a *suggestion in a manpage* which just
happens to be generated from POD content that is commonly embedded
within perl scripts.

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

The program does not create this file, it does not rely on this file, it
does not require any specific filename in /tmp and it does not write any
data to /tmp unless the USER specifically pipes the STDOUT to a file and
happens to use /tmp for that file.

If the user is dumb enough to pipe the output to a file that is a
symlink to something more important *AND* which has sufficient
permissions to be a problem, then that is not the fault of the package.
It is an example, nothing more.

If you have filed *grave* bugs against every package that includes
embedded documentation or manpage content outlining the possibility of
piping STDOUT to a file that might happen to be somewhere in /tmp then
you have made a huge mis-calculation.

The manpage example is deliberately simplified for clarity - yes, it
could have been made a lot longer by exporting a generated filename to a
variable and reading that variable into the command line to zenity but
there really was no point. /tmp was used because files in /tmp will be
cleared out at reboot so that I didn't have to remove the file later
(when it might be useful to run the zenity process a few times). Why
make the example unnecessarily complicated? All it needed to show was
that the redirect needs to create a file which zenity can then read.

> This list is created with the help of script.  This list is sorted  by
> hand. Howewer in some cases mistake is possible.

You're not kidding.

> Please, Be understanding to possible mistakes. :)

Knowing that mistakes were likely makes it all the more annoying that
you didn't file a LIST of possible bugs to -devel, you just went ahead.
It really wasn't a good idea, that one.

> I set Severity into grave for this bug. The table of discovered
> problems is below.

That is just the WRONG way to do a mass bug filing, IMHO. With a release
pending and all these bugs supposedly *grave*, the right way to do it
would have been to use the mass bug filing support in devscripts to send
a list of affected packages and maintainers to -devel BEFORE filing any
bugs such as to allow maintainers to identify more false positives and
prevent needless churn in the BTS.

> Discussion of this bug you can see in debian-devel@:
>     http://lists.debian.org/debian-devel/2008/08/msg00271.html

Thanks for the entirely needless hassle of having to close #496429
immediately after it was filed instead of the simple courtesy of posting
your intention along with the complete list of packages and maintainers.


Neil Williams

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: