Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAN1fySViLgrLAHHfTHMef-Bkh73kUHKP-ava6TbgALeSE4LfFw@mail.gmail.com>
 <CAFLxGvwpuxKF4UWdsULwQWo7kgVLMNHC=77dN+w-A0a6avrAXA@mail.gmail.com>
 <CAN1fySXjLUYFw2JGQQ5xxqjX+6kygzqgUc6Oj-sbtq=ZjgfLTA@mail.gmail.com>
 <CAGXu5jJoqnX54JnHZDVxO4NRCsT6sLH4+-TPk8GqCSVp0mFNLw@mail.gmail.com> <CAN1fySW2mTaHmj7_uon_xZBVgPeEuYCD8e+JGOSKNwokmgZ7yg@mail.gmail.com>
In-Reply-To: <CAN1fySW2mTaHmj7_uon_xZBVgPeEuYCD8e+JGOSKNwokmgZ7yg@mail.gmail.com>
From:   Kees Cook <keescook@chromium.org>
Date:   Wed, 13 Feb 2019 17:35:17 -0800
Message-ID: <CAGXu5jKXUhYB9xBLMWTvJiJEVPyRd=RsZTOCSvbNv7i6pEhtmg@mail.gmail.com>
Subject: Re: Userspace regression in LTS and stable kernels
To:     Samuel Dionne-Riel <samuel@dionne-riel.com>
Cc:     Richard Weinberger <richard.weinberger@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Graham Christensen <graham@grahamc.com>,
        Oleg Nesterov <oleg@redhat.com>,
        Michal Hocko <mhocko@suse.com>,
        Andrew Morton <akpm@linux-foundation.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Feb 13, 2019 at 5:27 PM Samuel Dionne-Riel
<samuel@dionne-riel.com> wrote:
> If I understand right, you're asking whether it should return NOEXEC
> if, of the first 128 bytes of the shebang, there are no spaces, but a
> too long shebang? I wouldn't know for sure. The behaviour would
> change. Instead failing due to trying to execute a shortened path, it
> would fall back to the shell interpreter interpreting the file, which,
> due to the inclusion of a specific shebang, might be a wrong
> assumption still. Here I believe it's still in the "undefined
> behaviour" territory, but one where it fails early for the userspace.

The original problem that was trying to be fixed here was to disallow
execution of a truncated interpreter path. It was assumed argument
truncate was just as bad, but it's not, since the interpreter can (and
does!) re-read the script to get the right arguments.

So, I've sent a fix-up patch that should disallow the path truncation,
but pass through the argument truncation as before. This passes all
the tests I built:

$ ls -l /AAA*/perl
-rwxr-xr-x 1 root root 129 Feb 13 17:17
/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/perl
-rwxr-xr-x 1 root root 129 Feb 13 17:17
/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/perl
-rwxr-xr-x 1 root root 129 Feb 13 17:17
/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/perl
-rwxr-xr-x 1 root root 129 Feb 13 17:17
/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/perl
-rwxr-xr-x 1 root root 129 Feb 13 17:17
/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/perl

$ ./test.pl
Arg # 0 : /nix/store/mbwav8kz8b3y471wjsybgzw84mrh4js9-perl-5.28.1/bin/perl
Arg # 1 : -I/nix/store/x6yyav38jgr924nkna62q3pkp0dgmzlx-perl5.28.1-Fi
Arg # 2 : ./test.pl
$ ./AAAA.pl
Error: no such file "I should fail to run huge interp\n"
$ ./A128.pl
Error: no such file "I should fail to run 128 byte buf interp\n"
$ ./A127.pl
Error: no such file "I should fail to run 127 byte buf interp\n"
$ ./A126.pl
Arg # 0 : '/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/perl'
Arg # 1 : './A126.pl'
$ ./A125space.pl
Arg # 0 : '/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/perl'
Arg # 1 : './A125space.pl'

Are you able to test the patch and report back?

Thanks again for bringing this to our attention!

-- 
Kees Cook