develooper Front page | perl.perl5.porters | Postings from August 2021

Re: CVE-2021-36770: Encode.pm loads code from outside expected @INC

Thread Previous | Thread Next
From:
Dan Book
Date:
August 9, 2021 22:36
Subject:
Re: CVE-2021-36770: Encode.pm loads code from outside expected @INC
Message ID:
CABMkAVW7QAKD7YMSMe3nj5y1+6TdBt8VMd8JDk0iJQ_0UB0wwA@mail.gmail.com
On Mon, Aug 9, 2021 at 5:03 PM Achim Gratz <Stromeko@nexgo.de> wrote:

> "Ricardo Signes" writes:
> > diff --git a/Encode.pm b/Encode.pm
> > index a56a999..9691382 100644
> > --- a/Encode.pm
> > +++ b/Encode.pm
> > @@ -65,8 +65,8 @@ require Encode::Config;
> >  eval {
> >      local $SIG{__DIE__};
> >      local $SIG{__WARN__};
> > -    local @INC = @INC || ();
> > -    pop @INC if $INC[-1] eq '.';
> > +    local @INC = @INC;
> > +    pop @INC if @INC && $INC[-1] eq '.';
> >      require Encode::ConfigLocal;
> >  };
>
> Hmm, the original change in 3.05 looks… planted; and since Encode.pm is
> XS-ed it gets baked in pretty hard.  Since that change precludes any
> attempt to use Encode::ConfigLocal as intended, this also shows that the
> distribution is missing a test for this functionality and that
> practically nobody is using it or it should have been caught much
> earlier.  :-(
>
> Going back to CVE-2016-1238, why is "." in @INC only removed when it's
> at the end (which used to be where it was by default)?  Shouldn't it be
> sanitized regardless of position, or even more generally any
> world-writable components of @INC?
>

It's quite different to account for the default behavior of Perl up until
5.26, than to account for anyone's modification of @INC which may have a
good reason (and if you want to protect against that, you must remove any
relative path from @INC, not just '.').

-Dan

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About