Re: Potentially insecure Perl scripts

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Sorry for not reading the whole thread first, so my last mail didn't
take account of this one...

Dominic Hargreaves writes ("Re: Potentially insecure Perl scripts"):
> No, I don't think you did; thank you for putting it so succinctly.
> As is obvious from the discussion, this is clearly not something which
> can "just" be fixed in a security upload, since any meaningful change
> will break a lot of scripts which rely on it.

I don't think that changing this will break any appreciable number of
scripts.

> By comparison, the work preparing patches and then analysing the
> fallout for the '.' in @INC removal (which mostly happened under
> embargo), took about a year between the more serious apt related
> security impact being understood by the perl5 security team and
> public disclosure[1]. And that was with a lot of effort from
> different quarters.

I think the @INC problem was clearly much harder than this.  That much
stuff broke was unsurprising.

> Some have postulated that the breakage caused here is likely to be
> at least as bad. I don't have a clear assessment of that yet but
> this discussion is ongoing.

AFAIAA so far no-one has presented even one example of an actual
published program which would stop working if we made this change.

> Also, I think it's worth trying to identify what the worst extent
> of the issue is. Whilst I don't agree with some who say that this isn't
> a security issue at all, I don't know of any real-world cases where
> it would be exploitable for remote code execution. If someone would
> like to contradict me, please feel free to mail off-list.

Example of how this could be used for remote code execution:

1. Someone sends you a tarball of some files.
2. You extract the tarball.
3. You do
      program ./*
   for any program which uses while(<>).

There are probably programs that do the equivalent of this
programmetically, but finding them will be almost impossible, because
the <> bug means that, for example, /usr/bin/fixcvsdiff, has a
security hole if run on untrusted filenames.

So to find whether there are easy exploits it will be necessary to
search for programs which run fixcvsdiff.  And then inspect them all
to see if they always use trustworthy filenames.  And do that for all
hundreds or thousands of values of fixcvsdiff.

> Either way,
> the fact remains that if untrusted/unsanitised input is being passed
> into your @ARGV, then something is already wrong. It is worth
> noting that it took a real (embarged) RCE exploit to get the wheels in
> motion to eventually fix '.' in @INC.

Maybe we should not wait for that this time ?

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.