bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Dangerous problem triggered by broken bash's stdin


From: Eduard Vopicka
Subject: Dangerous problem triggered by broken bash's stdin
Date: Tue, 6 Apr 2004 15:49:06 +0200 (CEST)


Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: freebsd4.9
Compiler: cc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='free
bsd4.9' -DCONF_MACHTYPE='i386-portbld-freebsd4.9' -DCONF_VENDOR='portbld' -DSHEL
L  -DHAVE_CONFIG_H  -I.  -I. -I./include -I./lib  -O -pipe
uname output: FreeBSD vidle.i.cz 4.9-RELEASE-p3 FreeBSD 4.9-RELEASE-p3 #0: Fri M
ar 12 19:09:48 CET 2004     root@vidle.i.cz:/usr/src/sys/compile/VIDLE  i386
Machine Type: i386-portbld-freebsd4.9

Bash Version: 2.05b
Patch Level: 0
Release Status: release


Description:

Imagine the following situation: I was logged in via ssh into machine C
from machine A through intermediate machine B, e.g.

        A -ssh-> B -ssh-> C (bash here)

While I was in the middle of typing "rm -f *.tmp", the intermediate machine
B has been reset by HW switch by someone, just at the point when "rm -f *"
has been typed. At this time, nothing happened, but when some OS component
(TCP/IP stack, sshd?) at the target machine has realized that the TCP
connection is broken and decided to terminate bash, possibly with SIGPIPE,
or possibly by closing the pipe to bash's stdin.

At this point, the incomplete "rm -f *" has been executed with fatal result,
e.g. great file loss. Note: The target "C" machine runs FreeBSD 4.9-p3 with
bash-2.05b.007 from FreeBSD's ports collection.

Repeat-By:

Log in to unix account with bash shell. Create files named "a" and "b". Then
type "rm a b" to the target bash and do not press enter. From another terminal
window on the targed machine, kill bash with "kill -PIPE ..."

Or:
        echo -n "rm -f zzz" | bash
and it appears that bash treats end-of-file as the line terminator.

I am not saying anything about that this behavior is or is not posixly
correct, but as shown, in the above networking context, it appears to be
extremely dangerous.

Fix:

Bash should not execute the incomplete command line.

Thanks in advance for your answer,

Eduard Vopicka

--
Eduard Vopicka                         Tel: +420 (2) 81002248
ICZ a.s.                                    +420 (2) 81002222
                                       Fax: +420 (2) 81002244




reply via email to

[Prev in Thread] Current Thread [Next in Thread]