GNU bug report logs - #22856
"make check" can start a shell on binary data

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22856 in the body.
You can then email your comments to 22856 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: bug-automake <at> gnu.org
Subject: "make check" can start a shell on binary data
Date: Mon, 29 Feb 2016 19:59:47 +0100

When I cross-compile for Windows and run "make check" without
LOG_COMPILER=wine (by mistake), strange files appear.
For instance, as a simple example with MPFR:

cventin:...re/mpfr-3.1/tests> make tadd.log
FAIL: tadd.exe

The failure is expected, but I get:

-rw-r--r-- 1    491 2016-02-29 19:39:24 tadd.log
-rw-r--r-- 1     84 2016-02-29 19:39:24 tadd.trs
-rw-r--r-- 1      0 2016-02-29 19:39:24 \220\324V\366

Created files like "\220\324V\366" are very annoying. In particular,
they make svn unusable.

tadd.log contains:

./tadd.exe: 1: ./tadd.exe: MZ��¸@€º´: not found
./tadd.exe: 2: ./tadd.exe: : not found
./tadd.exe: 1: ./tadd.exe: @.bss €: not found
./tadd.exe: 1: ./tadd.exe: .textd*,: not found
./tadd.exe: 3: ./tadd.exe: JPL2@�.idata: not found
./tadd.exe: 3: ./tadd.exe: –u
                             : not found
./tadd.exe: 4: ./tadd.exe: ~@0�.CRT4�ˆ@0�.tls: not found
./tadd.exe: 5: ./tadd.exe: @B/81P: not found
./tadd.exe: 13: ./tadd.exe: Syntax error: Missing '}'
FAIL tadd.exe (exit status: 2)

So, it appears that tadd.exe (which is a binary[*]) was executed
by a shell!

[*]
$ file tadd.exe
tadd.exe: PE32 executable (console) Intel 80386, for MS Windows

This is confirmed by strace:

[...]
10517 execve("./tadd.exe", ["./tadd.exe"], [/* 116 vars */]) = -1 ENOEXEC (Exec format error)
10517 execve("/bin/sh", ["/bin/sh", "./tadd.exe"], [/* 116 vars */]) = 0
[...]

Concerning the Makefile in the tests:

# Makefile.in generated by automake 1.15 from Makefile.am.
# tests/Makefile.  Generated from Makefile.in by configure.

This is under Debian/unstable.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Message #10 received at 22856-done <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: 22856-done <at> debbugs.gnu.org
Subject: Re: "make check" can start a shell on binary data
Date: Mon, 29 Feb 2016 20:03:47 +0100

Sorry, forget this bug report. After wondering where the problem came
from exactly, I've eventually found that this is some incredible bug
in dash!

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Message #13 received at 22856 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: 22856 <at> debbugs.gnu.org, vincent <at> vinc17.net
Cc: 22856-done <at> debbugs.gnu.org
Subject: Re: bug#22856: "make check" can start a shell on binary data
Date: Mon, 29 Feb 2016 14:48:11 -0500

On 2016-02-29, Vincent Lefevre <vincent <at> vinc17.net> wrote:
> When I cross-compile for Windows and run "make check" without
> LOG_COMPILER=wine (by mistake), strange files appear.
[...]
> ./tadd.exe: 1: ./tadd.exe: MZ ��¸@€º´: not found
> ./tadd.exe: 2: ./tadd.exe: : not found
> ./tadd.exe: 1: ./tadd.exe: @.bss €: not found
> ./tadd.exe: 1: ./tadd.exe: .textd*,: not found
> ./tadd.exe: 3: ./tadd.exe: JPL2@�.idata: not found
[...]
> So, it appears that tadd.exe (which is a binary[*]) was executed
> by a shell!
[...]
> 10517 execve("./tadd.exe", ["./tadd.exe"], [/* 116 vars */]) = -1 ENOEXEC
> (Exec format error)
> 10517 execve("/bin/sh", ["/bin/sh", "./tadd.exe"], [/* 116 vars */]) = 0

Later on 2016-02-29, Vincent Lefevre <vincent <at> vinc17.net> wrote:
> Sorry, forget this bug report. After wondering where the problem came
> from exactly, I've eventually found that this is some incredible bug
> in dash!

This crazy behaviour is actually permitted by POSIX, and to a certain
extent is even mandatory.  When executing a command whose name contains
a slash:

  "If the execl() function fails due to an error equivalent to the
  [ENOEXEC] error, the shell shall execute a command equivalent to
  having a shell invoked with the command name as its first operand,
  with any remaining arguments passed to the new shell.  If the
  executable file is not a text file, the shell may bypass this
  command execution."

(The text for commands without a slash is similar).

In POSIX text files are permitted to contain bytes with any value other
than 0 (NUL), so all sorts of line noise counts and is required to be
executed as a shell script.  But since the check is optional dash might
just not bother doing it, or maybe does not look at the entire file.

Cheers,
  Nick

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.