Bash wrongly attaches subcommand stdin on syntax error

[Sam Liddicott]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4
-Wformat -Werror=format-security -Wall
uname output: Linux sojojojo 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22
21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.3
Patch Level: 11
Release Status: release

Description:
Shell wrongly attaches stdin piped to command sequence with syntax error

Repeat-By:
On a login shell or interactive shell, paste the following command:

for x in 1 ; do echo $( { echo } ) ; done < <( echo touch /tmp/x2 )

The handling of the syntax error will cause stdin of the command
to become attached to the login shell, which will then execute:
  touch /tmp/x2
and then logout.

This bogus behaviour does not occur if the for-loop is dropped from
the example.

This script demonstrates the problem in a shell script, where stdin
of the entire script is diverted, though not necessarily the
commands to be executed

#! /bin/bash
set -x
for x in 1 ; do echo $( { echo } ) ; done < <( echo touch /tmp/x2 )
cat

The text "touch /tmp/x2" is emitted to stdout

As this depends on a syntax error I haven't worked out how it might
be exploited as a security hole

Re: Sourcing a file ending in \ disables aliases for 1 command

[Chet Ramey]

On 4/3/15 3:55 PM, Eduardo A. Bustamante López wrote:

> Also, while looking at this, I found this:
> 
> dualbus@yaqui ~ % bash -c 'eval \\; echo y'
> y
> dualbus@yaqui ~ % bash -ic 'eval \\; echo y'
> exit
> 
> So, that eval is triggering a yacc_EOF, so that triggers the `exit' in the
> interactive shell.

Thanks for the report.  This one was a trickier fix, since there are two
problems here.  The fix will be in the next release of bash and will show
up on the devel branch soon.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

conflict between gcc and bash malloc lib with static link

[thibaut . charpentier]

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' 
-DSHELL -DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include -I../bash/lib 
 -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 
-Wformat -Werror=format-security -Wall
uname output: Linux Thinkpad 3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 
18:19:42 UTC 2013 i686 i686 i686 GNU/Linux

Machine Type: i686-pc-linux-gnu

Bash Version: 4.3.30
Release Status: release

Description:
at link step there is a conflict between gcc library in
lib/gcc/i686-linux-gnu/libc.a
and bash library
lib/malloc/libmalloc.a
for malloc and free functions

Repeat-By:
generation with --enable-static-link

Fix:
adding option --without-bash-malloc look a simple fix
but this generate another issue because in file
lib/sh/shmatch.c there is a reference to sh_xfree
The solution is to add
#include "xmalloc.h"
in file
lib/sh/shmatch.c

I hope I was clear (and my solution was really a good one)
as it's the first time I report a bug.
Of course you can ask me some details if necessary,
I will do my best to help you.
Thibaut