Re: Potentially insecure Perl scripts
On Thu, Jan 24, 2019 at 08:00:12PM +0000, Holger Levsen wrote:
> On Thu, Jan 24, 2019 at 03:18:40PM +0000, Ian Jackson wrote:
> > To the Debian Perl maintainers: [...]
> > To the Debian security team: [...]
>
> I've read the whole thread and am surprised "talking to upstream" (and
> fixing the issue there as well) hasn't really been on the table. :/ Did I
> miss that?
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. It's also far too big
a change of behaviour to be patching in Debian without involving upstream,
and would need to be staged in unstable first.
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.
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.
I have informally made a few upstream perl folks aware of this
thread, but I have not raised it formally as a bug until I have had a
chance to understand the various issues a bit better. But I think I
can safely say that this isn't something that's going to appear in
stable-security any time soon.
It does seem like the upstream plan from 2008 to introduce <<>> and
then get scripts updated to be safer didn't work, as many people writing
perl was not aware of this new operator. So there is definitely scope for
reconsidering upstream - but again, this won't happen overnight.
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. 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.
Thanks,
Dominic.
on behalf of the Debian perl maintainers
[1] <https://rt.perl.org/Ticket/Display.html?id=127834>
Reply to: