`exec` should not invoke a shell when execve(2) fails with ENOEXEC

[zackw]

The exec built-in is documented not to invoke a shell when passed an indirect object and a list, even if the list has only one argument. However, if the underlying execve(2) system call fails with errno code ENOEXEC, exec will still invoke a shell. (The argument list is not interpreted as a shell command, but the program is passed to /bin/sh as if it were a shell script to be executed. This is just as undesirable.)

Demonstration:

$ cat > test.x <<\EOF
echo "A shell should not have been invoked." >&2
exit 0
EOF
$ perl -e 'exec {$ARGV[0]} @ARGV or die "$ARGV[0]: $!\n"' ./test.x; echo $?
./test.x: Permission denied
13
$ strace -e trace=execve perl -e 'exec {$ARGV[0]} @ARGV or die "$ARGV[0]: $!\n"' ./test.x; echo $?
execve("/usr/bin/perl", ["perl", "-e", "exec {$ARGV[0]} @ARGV or die \"$A"..., "./test.x"], 0xfffff07192d8 /* 53 vars */) = 0
execve("./test.x", ["./test.x"], 0xaaaac4de11f0 /* 53 vars */) = -1 EACCES (Permission denied)
./test.x: Permission denied
+++ exited with 13 +++
13
$ chmod +x ./test.x
$ perl -e 'exec {$ARGV[0]} @ARGV or die "$ARGV[0]: $!\n"' ./test.x; echo $?
A shell should not have been invoked.
0
$ strace -e trace=execve perl -e 'exec {$ARGV[0]} @ARGV or die "$ARGV[0]: $!\n"' ./test.x; echo $?
execve("/usr/bin/perl", ["perl", "-e", "exec {$ARGV[0]} @ARGV or die \"$A"..., "./test.x"], 0xfffff07192d8 /* 53 vars */) = 0
execve("./test.x", ["./test.x"], 0xaaaac4de11f0 /* 53 vars */) = -1 ENOEXEC (Exec format error)
execve("/bin/sh", ["/bin/sh", "./test.x"], 0xaaaac4de11f0 /* 53 vars */) = 0
A shell should not have been invoked.
+++ exited with 0 +++
0

The behavior when execve fails with ENOEXEC should match the behavior when it fails with any other error code.

This bug consistently happens with all the perl versions I can conveniently test:

5.00503 5.6.1 5.8.8 5.10.1 5.14.1 5.14.2 5.14.4 5.20.0 5.20.2 5.20.3 5.22.1 5.22.2 5.22.3 5.22.4 5.24.1 5.24.3 5.32.0

(I happen to have a shell account on a machine with a frankly quite silly number of perl versions installed.)

(If there is something I can do in my code to make this not happen, please tell me; I was specifically trying to use perl to wrap invocation of binary executables that might have been compiled for the wrong CPU.)

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
    category=core
    severity=low
---
Site configuration information for perl 5.32.0:

Configured by builduser at Thu Sep 24 22:57:00 UTC 2020.

Summary of my perl5 (revision 5 version 32 subversion 0) configuration:

  Platform:
    osname=linux
    osvers=4.9.210-1-arch
    archname=aarch64-linux-thread-multi
    uname='archlinux'
    config_args='-des -Dusethreads -Duseshrplib -Doptimize=-march=armv8-a -O2 -pipe -fno-plt -Dprefix=/usr -Dvendorprefix=/usr -Dprivlib=/usr/share/perl5/core_perl -Darchlib=/usr/lib/perl5/5.32/core_perl -Dsitelib=/usr/share/perl5/site_perl -Dsitearch=/usr/lib/perl5/5.32/site_perl -Dvendorlib=/usr/share/perl5/vendor_perl -Dvendorarch=/usr/lib/perl5/5.32/vendor_perl -Dscriptdir=/usr/bin/core_perl -Dsitescript=/usr/bin/site_perl -Dvendorscript=/usr/bin/vendor_perl -Dinc_version_list=none -Dman1ext=1perl -Dman3ext=3perl -Dlddlflags=-shared -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Dldflags=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Dmyuname=archlinux -Dmyhostname=archlinux -Dcf_time=Thu Sep 24 10:56:52 PM UTC 2020'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=define
    usemultiplicity=define
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
    bincompat5005=undef
  Compiler:
    cc='cc'
    ccflags ='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2'
    optimize='-march=armv8-a -O2 -pipe -fno-plt'
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
    ccversion=''
    gccversion='10.2.0'
    gccosandvers=''
    intsize=4
    longsize=8
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=1
    ivtype='long'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='off_t'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='cc'
    ldflags ='-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/include-fixed /usr/lib /lib/../lib /usr/lib/../lib /lib
    libs=-lpthread -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
    perllibs=-lpthread -ldl -lm -lcrypt -lutil -lc
    libc=libc-2.32.so
    so=so
    useshrplib=true
    libperl=libperl.so
    gnulibc_version='2.32'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs
    dlext=so
    d_dlsymun=undef
    ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.32/core_perl/CORE'
    cccdlflags='-fPIC'
    lddlflags='-shared -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -L/usr/local/lib -fstack-protector-strong'

---
@INC for perl 5.32.0:
    /usr/lib/perl5/5.32/site_perl
    /usr/share/perl5/site_perl
    /usr/lib/perl5/5.32/vendor_perl
    /usr/share/perl5/vendor_perl
    /usr/lib/perl5/5.32/core_perl
    /usr/share/perl5/core_perl

---
Environment for perl 5.32.0:
    HOME=/home/zack
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LC_COLLATE=C
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/zack/.local/bin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
    PERL_BADLANG (unset)
    SHELL=/bin/bash

[zackw]

Update: after further investigation I have determined that Perl's exec is simply calling the C library function execvp (via Perl_do_aexec5, on Unixy platforms) and that the POSIX spec for execvp actually requires it to invoke a shell when direct execution fails with ENOEXEC. I consider this to be a defect in POSIX, and have reported it to the Austin Group.

Please consider this bug report to be a request to rewrite Perl_do_aexec5, and all other functions that may call execvp, so that they do not call execvp anymore, but instead implement PATH-walking themselves and call execv or execve, which do not have this design defect.

[tonycoz]

I'm inclined to wait on the Austin group ticket here.

As one poster there mentioned, this may break existing code that expects a non #! shell script to run.

I don't really see this as a security issue, and it's not perl itself invoking the shell, but the underlying implementation.