Re: Files-Excluded field and security implications of uscan and debian/copyright.
Hi Charles,
On Mon, Sep 10, 2012 at 08:20:43AM +0900, Charles Plessy wrote:
> > I would love to get a pointer to the actual line[1] which executes
> > content from debian/copyright. TTBOMK, all expressions are part of the
> > seeking string of a find statement, nothing more.
>
> the find commands are executed via backsticks, which potentially can execute
> any arbitrary command. I personally have not found a way to exploit this (*),
> but given my lack of training in the field, I do not consider this significant,
> so I asked for others opinions.
But these are totally different things: I understood your initial mail
that using debian/copyright is insecure. Now you come up with the
argument that using backsticks might be insecure. So either backsticks
are insecure for *any* file we are using (IMHO the current
implementation is not - but Perl experts might have another look at[1])
or not.
> My main question anyway is whether it would be useful to make a distinction
> between fields that have a content that is more likely to be passed to shell
> commands, and fields where the content is less likely to be so.
I try to give a short history of the proposal to get a reasonably option
of removing files from upstream source in an easy manner: My first
implementation suggestion[2] was to use a file uscan.remove which was
enhanced by the IMHO very sane recommendation of Jonas[3] to use
debian/copyright. We had some opinion raised against this (none of them
contained a security argument and IMHO this argument is void) but from
my perspective there is some kind of consensus that using
debian/copyright is a good idea - at least this is my personal reading
of the threads.
We now could either try to get a proof of this consensus by some kind of
voting or we could follow an implementation (Do-O-Cracy). For the sake
of simplicity I would prefer the later way to step forewars and I'm
perfectly fine for accepting patches to[1] which solves any issue
anybody might have to the current implementation suggestion.
> (*) Yes I looked, and maybe the most straightforward way would be to make a
> fake file name containing backsticks, in order to execute a helper script in the
> debian directory.
Huh what? A Debian developer who tries to delete an upstream file that
contains backsticks in the file name and contains vulnerable code by
injecting it into debian/copryight? Are you honest that this could be a
reasonable way of attacking a Debian system? Any get-orig-source target
might be way more dangerous than this - and it is the Debian developers
duty anyway to check the result of the tarball creation process. If any
upstream (and we are talking about files in an upstream tarball, right)
wants to attack a Debian system - why should he put the code in this
very crude way into the tarball and not straight into the code???
Kind regards
Andreas.
[1] http://anonscm.debian.org/gitweb/?p=users/tille/devscripts.git;a=blob;f=scripts/uscan.pl;hb=HEAD
[2] http://lists.debian.org/debian-devel/2012/08/msg00397.html
[3] http://lists.debian.org/debian-devel/2012/08/msg00406.html
--
http://fam-tille.de
Reply to: